linux/lib/crypto/Kconfig, branch master

lib/crypto: sparc: Drop optimized MD5 code

2026-03-30T19:35:16Z

MD5 is obsolete. Continuing to maintain architecture-optimized implementations of MD5 is unnecessary and risky. It diverts resources from the modern algorithms that are actually important. While there was demand for continuing to maintain the PowerPC optimized MD5 code to accommodate userspace programs that are misusing AF_ALG (https://lore.kernel.org/linux-crypto/c4191597-341d-4fd7-bc3d-13daf7666c41@csgroup.eu/), no such demand has been seen for the SPARC optimized MD5 code. Thus, let's drop it and focus effort on the more modern SHA algorithms, which already have optimized code for SPARC. Acked-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20260326203341.60393-1-ebiggers@kernel.org Signed-off-by: Eric Biggers

lib/crypto: mips: Drop optimized MD5 code

2026-03-30T19:35:05Z

MD5 is obsolete. Continuing to maintain architecture-optimized implementations of MD5 is unnecessary and risky. It diverts resources from the modern algorithms that are actually important. While there was demand for continuing to maintain the PowerPC optimized MD5 code to accommodate userspace programs that are misusing AF_ALG (https://lore.kernel.org/linux-crypto/c4191597-341d-4fd7-bc3d-13daf7666c41@csgroup.eu/), no such demand has been seen for the MIPS Cavium Octeon optimized MD5 code. Note that this code runs on only one particular line of SoCs. Thus, let's drop it and focus effort on the more modern SHA algorithms, which already have optimized code for the same SoCs. Acked-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20260326204824.62010-1-ebiggers@kernel.org Signed-off-by: Eric Biggers

lib: Move crypto library tests to Runtime Testing menu

2026-03-24T00:50:59Z

Currently the kconfig options for the crypto library KUnit tests appear in the menu: -> Library routines -> Crypto library routines However, this is the only content of "Crypto library routines". I.e., it is empty when CONFIG_KUNIT=n. This is because the crypto library routines themselves don't have (or need to have) prompts. Since this usually ends up as an unnecessary empty menu, let's remove this menu and instead source the lib/crypto/tests/Kconfig file from lib/Kconfig.debug inside the "Runtime Testing" menu: -> Kernel hacking -> Kernel Testing and Coverage -> Runtime Testing This puts the prompts alongside the ones for most of the other lib/ KUnit tests. This seems to be a much better match to how the kconfig menus are organized. Acked-by: Randy Dunlap Tested-by: Randy Dunlap Link: https://lore.kernel.org/r/20260322032438.286296-1-ebiggers@kernel.org Signed-off-by: Eric Biggers

lib/crypto: x86/sm3: Migrate optimized code into library

2026-03-24T00:50:59Z

Instead of exposing the x86-optimized SM3 code via an x86-specific crypto_shash algorithm, instead just implement the sm3_blocks() library function. This is much simpler, it makes the SM3 library functions be x86-optimized, and it fixes the longstanding issue where the x86-optimized SM3 code was disabled by default. SM3 still remains available through crypto_shash, but individual architectures no longer need to handle it. Tweak the prototype of sm3_transform_avx() to match what the library expects, including changing the block count to size_t. Note that the assembly code actually already treated this argument as size_t. Acked-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20260321040935.410034-10-ebiggers@kernel.org Signed-off-by: Eric Biggers

lib/crypto: riscv/sm3: Migrate optimized code into library

2026-03-24T00:50:59Z

Instead of exposing the riscv-optimized SM3 code via a riscv-specific crypto_shash algorithm, instead just implement the sm3_blocks() library function. This is much simpler, it makes the SM3 library functions be riscv-optimized, and it fixes the longstanding issue where the riscv-optimized SM3 code was disabled by default. SM3 still remains available through crypto_shash, but individual architectures no longer need to handle it. Tweak the prototype of sm3_transform_zvksh_zvkb() to match what the library expects, including changing the block count to size_t. Note that the assembly code already treated it as size_t. Note: to see the diff from arch/riscv/crypto/sm3-riscv64-glue.c to lib/crypto/riscv/sm3.h, view this commit with 'git show -M10'. Acked-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20260321040935.410034-9-ebiggers@kernel.org Signed-off-by: Eric Biggers

lib/crypto: arm64/sm3: Migrate optimized code into library

2026-03-24T00:50:59Z

Instead of exposing the arm64-optimized SM3 code via arm64-specific crypto_shash algorithms, instead just implement the sm3_blocks() library function. This is much simpler, it makes the SM3 library functions be arm64-optimized, and it fixes the longstanding issue where the arm64-optimized SM3 code was disabled by default. SM3 still remains available through crypto_shash, but individual architectures no longer need to handle it. Tweak the SM3 assembly function prototypes to match what the library expects, including changing the block count from 'int' to 'size_t'. sm3_ce_transform() had to be updated to access 'x2' instead of 'w2', while sm3_neon_transform() already used 'x2'. Remove the CFI stubs which are no longer needed because the SM3 assembly functions are no longer ever indirectly called. Remove the dependency on KERNEL_MODE_NEON. It was unnecessary, because KERNEL_MODE_NEON is always enabled on arm64. Acked-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20260321040935.410034-8-ebiggers@kernel.org Signed-off-by: Eric Biggers

lib/crypto: sm3: Add SM3 library API

2026-03-24T00:50:59Z

Add a straightforward library API for SM3, mirroring the ones for the other hash algorithms. It uses the existing generic implementation of SM3's compression function in lib/crypto/sm3.c. Hooks are added for architecture-optimized implementations, which later commits will wire up to the existing optimized SM3 code for arm64, riscv, and x86. Note that the rationale for this is *not* that SM3 should be used, or that any kernel subsystem currently seems like a candidate for switching from the sm3 crypto_shash to SM3 library. (SM3, in fact, shouldn't be used. Likewise you shouldn't use MD5, SHA-1, RC4, etc...) Rather, it's just that this will simplify how the kernel's existing SM3 code is integrated and make it much easier to maintain and test. SM3 is one of the only hash algorithms with arch-optimized code that is still integrated in the old way. By converting it to the new lib/crypto/ code organization, we'll only have to keep track of one way of doing things. The library will also get a KUnit test suite (as usual for lib/crypto/), so it will become more easily and comprehensively tested as well. Skip adding functions for HMAC-SM3 for now, though. There's not as much point in adding those right now. Note: similar to the other hash algorithms, the library API uses 'struct sm3_ctx', not 'struct sm3_state'. The existing 'struct sm3_state' and the sm3_block_generic() function which uses it are temporarily kept around until their users are updated by later commits. Acked-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20260321040935.410034-5-ebiggers@kernel.org Signed-off-by: Eric Biggers

lib/crypto: aesgcm: Use GHASH library API

2026-03-23T23:44:30Z

Make the AES-GCM library use the GHASH library instead of directly calling gf128mul_lle(). This allows the architecture-optimized GHASH implementations to be used, or the improved generic implementation if no architecture-optimized implementation is usable. Note: this means that no longer needs to include . Remove that inclusion, and include explicitly from arch/x86/crypto/aesni-intel_glue.c which previously was relying on the transitive inclusion. Acked-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20260319061723.1140720-20-ebiggers@kernel.org Signed-off-by: Eric Biggers

lib/crypto: s390/ghash: Migrate optimized code into library

2026-03-23T23:44:29Z

Remove the "ghash-s390" crypto_shash algorithm, and replace it with an implementation of ghash_blocks_arch() for the GHASH library. This makes the GHASH library be optimized with CPACF. It also greatly reduces the amount of s390-specific glue code that is needed, and it fixes the issue where this GHASH optimization was disabled by default. Acked-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20260319061723.1140720-14-ebiggers@kernel.org Signed-off-by: Eric Biggers

lib/crypto: riscv/ghash: Migrate optimized code into library

2026-03-23T23:44:29Z

Remove the "ghash-riscv64-zvkg" crypto_shash algorithm. Move the corresponding assembly code into lib/crypto/, modify it to take the length in blocks instead of bytes, and wire it up to the GHASH library. This makes the GHASH library be optimized with the RISC-V Vector Cryptography Extension. It also greatly reduces the amount of riscv-specific glue code that is needed, and it fixes the issue where this optimized GHASH code was disabled by default. Note that this RISC-V code has multiple opportunities for improvement, such as adding more parallelism, providing an optimized multiplication function, and directly supporting POLYVAL. But for now, this commit simply tweaks ghash_zvkg() slightly to make it compatible with the library, then wires it up to ghash_blocks_arch(). ghash_preparekey_arch() is also implemented to store the copy of the raw key needed by the vghsh.vv instruction. Acked-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20260319061723.1140720-13-ebiggers@kernel.org Signed-off-by: Eric Biggers