crypto: sm3 - Remove 'struct sm3_state'

Update one driver that used sizeof(struct sm3_state) to use
sizeof(struct sm3_ctx) instead. Then, remove struct sm3_state and
SM3_STATE_SIZE.

This completes

crypto: sm3 - Remove 'struct sm3_state'

Update one driver that used sizeof(struct sm3_state) to use
sizeof(struct sm3_ctx) instead. Then, remove struct sm3_state and
SM3_STATE_SIZE.

This completes the replacement of struct sm3_state with struct sm3_ctx.

Acked-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://lore.kernel.org/r/20260321040935.410034-13-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>

show more ...

crypto: sm3 - Replace with wrapper around library

Reimplement the "sm3" crypto_shash on top of the SM3 library, closely
mirroring the other hash algorithms (e.g. SHA-*).

The result, after later com

crypto: sm3 - Replace with wrapper around library

Reimplement the "sm3" crypto_shash on top of the SM3 library, closely
mirroring the other hash algorithms (e.g. SHA-*).

The result, after later commits migrate the architecture-optimized SM3
code into the library as well, is that crypto/sm3.c will be the single
point of integration between crypto_shash and the actual SM3
implementations, simplifying the code.

Note: to see the diff from crypto/sm3_generic.c to crypto/sm3.c, view
this commit with 'git show -M10'.

Acked-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://lore.kernel.org/r/20260321040935.410034-7-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>

show more ...

crypto: sm3 - Rename CRYPTO_SM3_GENERIC to CRYPTO_SM3

The kconfig options for generic crypto API modules have traditionally
*not* had a "_GENERIC" suffix. Also, the "_GENERIC" suffix will make
even

crypto: sm3 - Rename CRYPTO_SM3_GENERIC to CRYPTO_SM3

The kconfig options for generic crypto API modules have traditionally
*not* had a "_GENERIC" suffix. Also, the "_GENERIC" suffix will make
even less sense once the architecture-optimized SM3 code is moved into
lib/crypto/ and the "sm3" crypto_shash is reimplemented on top of that.

Thus, rename CRYPTO_SM3_GENERIC to CRYPTO_SM3.

Acked-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://lore.kernel.org/r/20260321040935.410034-4-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>

show more ...

crypto: gcm - Use GHASH library instead of crypto_ahash

Make the "gcm" template access GHASH using the library API instead of
crypto_ahash. This is much simpler and more efficient, especially given

crypto: gcm - Use GHASH library instead of crypto_ahash

Make the "gcm" template access GHASH using the library API instead of
crypto_ahash. This is much simpler and more efficient, especially given
that all GHASH implementations are synchronous and CPU-based anyway.

Note that this allows "ghash" to be removed from the crypto_ahash (and
crypto_shash) API, which a later commit will do.

This mirrors the similar cleanup that was done with POLYVAL.

Acked-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://lore.kernel.org/r/20260319061723.1140720-16-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>

show more ...

crypto: aes - Add cmac, xcbc, and cbcmac algorithms using library

Update the "aes" module to implement "cmac(aes)", "xcbc(aes)", and
"cbcmac(aes)" algorithms using the corresponding library function

crypto: aes - Add cmac, xcbc, and cbcmac algorithms using library

Update the "aes" module to implement "cmac(aes)", "xcbc(aes)", and
"cbcmac(aes)" algorithms using the corresponding library functions, and
register these with the crypto_shash API. Each algorithm is included
only if the corresponding existing kconfig option is enabled.

This allows the architecture-optimized implementations of these
algorithms to continue to be accessible via the crypto_shash API once
they are migrated into the library.

For "xcbc(aes)", I also fixed the bug where AES key lengths other than
128 bits were allowed, so that this bug didn't have to be implemented in
the library. The AES-XCBC-MAC specification (RFC 3566) is clear that
key lengths other than 128 bits MUST NOT be supported. AES-XCBC-MAC
derives a 128-bit subkey internally, so the nonstandard support for
longer AES keys didn't really work: AES-128 was still used internally.

In the unlikely event that someone is actually relying on the broken and
nonstandard support for longer AES-XCBC-MAC keys, we can fairly easily
reintroduce it. But it seems unnecessary: the only user of "xcbc(aes)"
seems to be IPsec, which uses 128-bit keys with it.

Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://lore.kernel.org/r/20260218213501.136844-3-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>

show more ...