kernel/linux.git/lib/crypto/md5.c, branch v7.2-rc1

lib/crypto: powerpc/md5: Drop powerpc optimized MD5 code

2026-05-09T18:41:01+00:00

MD5 is obsolete, is vulnerable to collision attacks, and is being replaced by SHA-256 in new systems. It doesn't make sense to continue to maintain architecture-optimized implementations of MD5. Effort should be spent on modern algorithms. Indeed, architecture-optimized MD5 code remains only for powerpc. It was already removed from mips and sparc, and it never existed for any other architecture (e.g. x86, arm, or arm64) in the first place. Earlier the decision was made to keep the powerpc MD5 code for a while anyway because of someone using it via AF_ALG via libkcapi-hasher (https://lore.kernel.org/r/f0d771d5-ed70-444c-957a-ad4c16f6c115@csgroup.eu/) However, with AF_ALG itself now being on its way out due to its continuous stream of security vulnerabilities (https://lore.kernel.org/r/20260430011544.31823-1-ebiggers@kernel.org/), it's also time to be a bit more forceful with nudging people towards userspace crypto code. It's always been the better solution anyway, and it's much more efficient if properly optimized code is used. Note that the md5-asm.S file contains no privileged instructions and could be run in userspace just fine. Thus, we now have two factors going against keeping the powerpc MD5 code. Different people might weigh these two factors differently, but I think the two of them together make the removal the clear choice. Let's remove it. Acked-by: Christophe Leroy (CS GROUP) Acked-by: Ard Biesheuvel Link: https://patch.msgid.link/20260506030005.9698-1-ebiggers@kernel.org Signed-off-by: Eric Biggers

lib/crypto: md5: Use rol32() instead of open-coding it

2026-01-12T19:07:50+00:00

For the bitwise left rotation in MD5STEP, use rol32() from instead of open-coding it. Signed-off-by: Rusydi H. Makarim Link: https://lore.kernel.org/r/20251214-rol32_in_md5-v1-1-20f5f11a92b2@kriptograf.id Signed-off-by: Eric Biggers

lib/crypto: md5: Add MD5 and HMAC-MD5 library functions

2025-08-26T16:52:27+00:00

Add library functions for MD5, including HMAC support. The MD5 implementation is derived from crypto/md5.c. This closely mirrors the corresponding SHA-1 and SHA-2 changes. Like SHA-1 and SHA-2, support for architecture-optimized MD5 implementations is included. I originally proposed dropping those, but unfortunately there is an AF_ALG user of the PowerPC MD5 code (https://lore.kernel.org/r/c4191597-341d-4fd7-bc3d-13daf7666c41@csgroup.eu/), and dropping that code would be viewed as a performance regression. We don't add new software algorithm implementations purely for AF_ALG, as escalating to kernel mode merely to do calculations that could be done in userspace is inefficient and is completely the wrong design. But since this one already existed, it gets grandfathered in for now. An objection was also raised to dropping the SPARC64 MD5 code because it utilizes the CPU's direct support for MD5, although it remains unclear that anyone is using that. Regardless, we'll keep these around for now. Note that while MD5 is a legacy algorithm that is vulnerable to practical collision attacks, it still has various in-kernel users that implement legacy protocols. Switching to a simple library API, which is the way the code should have been organized originally, will greatly simplify their code. For example: MD5: drivers/md/dm-crypt.c (for lmk IV generation) fs/nfsd/nfs4recover.c fs/ecryptfs/ fs/smb/client/ net/{ipv4,ipv6}/ (for TCP-MD5 signatures) HMAC-MD5: fs/smb/client/ fs/smb/server/ (Also net/sctp/ if it continues using HMAC-MD5 for cookie generation. However, that use case has the flexibility to upgrade to a more modern algorithm, which I'll be proposing instead.) As usual, the "md5" and "hmac(md5)" crypto_shash algorithms will also be reimplemented on top of these library functions. For "hmac(md5)" this will provide a faster, more streamlined implementation. Link: https://lore.kernel.org/r/20250805222855.10362-2-ebiggers@kernel.org Signed-off-by: Eric Biggers