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

On Tue, Oct 21, 2025 at 02:27:47PM +0200, Christian Brauner wrote:
> 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.

Sounds good, thanks!

- Eric