user/sven/linux.git/lib/crypto/sm3.c, branch next/master

crypto: sm3 - Remove the original "sm3_block_generic()"

2026-03-24T00:50:59Z

Since the architecture-optimized SM3 code was migrated into lib/crypto/, sm3_block_generic() is no longer called. Remove it. Then, since this frees up the name, rename sm3_transform() to sm3_block_generic() (matching the naming convention used in other hash algorithms). Acked-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20260321040935.410034-12-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: Explicitly include

2025-06-30T16:26:19Z

Fix build warnings with W=1 that started appearing after commit a934a57a42f6 ("scripts/misc-check: check missing #include when W=1"). While at it, also sort the include lists alphabetically. (Keep asm/irqflags.h last, as otherwise it doesn't build on alpha.) This handles all of lib/crypto/, but not arch/*/lib/crypto/. The exports in arch/*/lib/crypto/ will go away when the code is properly integrated into lib/crypto/ as planned. Link: https://lore.kernel.org/r/20250613184814.50173-1-ebiggers@kernel.org Signed-off-by: Eric Biggers

crypto: lib/sm3 - Remove partial block helpers

2025-04-23T07:52:47Z

Now that all sm3_base users have been converted to use the API partial block handling, remove the partial block helpers as well as the lib/crypto functions. Signed-off-by: Herbert Xu

crypto: lib/sm3 - Export generic block function

2025-04-16T07:36:24Z

Export the generic block function so that it can be used by the Crypto API. Signed-off-by: Herbert Xu

crypto: lib/sm3 - Move sm3 library into lib/crypto

2025-04-16T07:36:24Z

Move the sm3 library code into lib/crypto. Signed-off-by: Herbert Xu

crypto: sm3,sm4 - move into crypto directory

2022-04-08T08:11:48Z

The lib/crypto libraries live in lib because they are used by various drivers of the kernel. In contrast, the various helper functions in crypto are there because they're used exclusively by the crypto API. The SM3 and SM4 helper functions were erroniously moved into lib/crypto/ instead of crypto/, even though there are no in-kernel users outside of the crypto API of those functions. This commit moves them into crypto/. Cc: Herbert Xu Cc: Tianjia Zhang Cc: Eric Biggers Signed-off-by: Jason A. Donenfeld Signed-off-by: Herbert Xu

crypto: sm3 - create SM3 stand-alone library

2022-01-28T05:51:10Z

Stand-alone implementation of the SM3 algorithm. It is designed to have as little dependencies as possible. In other cases you should generally use the hash APIs from include/crypto/hash.h. Especially when hashing large amounts of data as those APIs may be hw-accelerated. In the new SM3 stand-alone library, sm3_transform() has also been optimized, instead of simply using the code in sm3_generic. Signed-off-by: Tianjia Zhang Reviewed-by: Gilad Ben-Yossef Signed-off-by: Herbert Xu