Re: [PATCH] ecryptfs: Use MD5 library instead of crypto_shash

On Sat, Oct 11, 2025 at 01:00:10PM -0700, Eric Biggers wrote:
> eCryptfs uses MD5 for a couple unusual purposes: to "mix" the key into
> the IVs for file contents encryption (similar to ESSIV), and to prepend
> some key-dependent bytes to the plaintext when encrypting filenames
> (which is useless since eCryptfs encrypts the filenames with ECB).
> 
> Currently, eCryptfs computes these MD5 hashes using the crypto_shash
> API.  Update it to instead use the MD5 library API.  This is simpler and
> faster: the library doesn't require memory allocations, can't fail, and
> provides direct access to MD5 without overhead such as indirect calls.
> 
> To preserve the existing behavior of eCryptfs support being disabled
> when the kernel is booted with "fips=1", make ecryptfs_get_tree() check
> fips_enabled itself.  Previously it relied on crypto_alloc_shash("md5")
> failing.  I don't know for sure that this is actually needed; e.g., it
> could be argued that eCryptfs's use of MD5 isn't for a security purpose
> as far as FIPS is concerned.  But this preserves the existing behavior.
> 
> Tested by verifying that an existing eCryptfs can still be mounted with
> a kernel that has this commit, with all the files matching.  Also tested
> creating a filesystem with this commit and mounting+reading it without.
> 
> Signed-off-by: Eric Biggers <[email protected]>
> ---
> 
> I can take this through the libcrypto tree if no one else volunteers.
> (It looks like eCryptfs doesn't have an active git tree anymore.)

Thanks, but not need, fixes for orphaned fses (that have valid acks) are
taken through a VFS tree.