On Mon, 16 Jun 2025 at 03:41, Eric Biggers <ebiggers@kernel.org> wrote:
>
> This series applies to v6.16-rc1 and is targeting the libcrypto-next
> tree. It is also available at:
>
> git fetch https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux.git sha512-lib-v2
>
> This series adds support for SHA-384, SHA-512, HMAC-SHA384, and
> HMAC-SHA512 to lib/crypto/. The new functions take advantage of the
> kernel's existing architecture-optimized implementations of the SHA-512
> compression function. The new functions are fully tested using KUnit.
>
> To avoid duplicating all arch-optimized implementations of the SHA-512
> compression function (~3000 lines of code total), they are moved into
> lib/crypto/ rather than copied. To make the "sha384", "sha512",
> "hmac(sha384)", and "hmac(sha512)" crypto_shash algorithms in the
> old-school crypto API continue to be properly optimized after that, they
> are reimplemented on top of lib/crypto/, which is straightforward.
>
> The following lists some of the design choices and conventions that I've
> followed in more detail. Where these differ from the code or APIs for
> other algorithms (e.g., SHA-256 in some cases), I'd like to do it this
> way going forward and plan to fix up the other algorithms accordingly:
>
> - APIs are fully documented with kerneldoc comments.
>
> - APIs cannot fail, and return void.
>
> - APIs work in all contexts. This doesn't mean that they *should* be
> called in all contexts, but rather they always just work as expected.
>
> - Tests are KUnit tests, and they are fairly thorough (more thorough
> than crypto/testmgr.c) and also optionally include benchmarks.
>
> - Architecture-optimized code is integrated the same way I'm doing it
> for lib/crc/: it's in subdirectories lib/crypto/$(SRCARCH), it's
> enabled by default, and it's inlined into the same module as the
> generic code. This solves a number of problems; for more details, see
> https://lore.kernel.org/r/20250607200454.73587-1-ebiggers@kernel.org
>
> - HMAC support is a first-class citizen.
>
> - APIs handle zeroization, when applicable.
>
> - Message contexts are *_ctx instead of *_state. It's shorter, avoids
> ambiguity with the compression function state, and matches OpenSSL.
>
> - Length arguments are size_t, are in bytes, are named len or *_len, and
> immediately follow the corresponding buffer. "Object" being operated
> on is first argument; outputs otherwise follow inputs.
>
> - The structures for different algorithms use different types, which
> prevents usage errors where functions are mixed up between algorithms.
>
> - The compression function state is strongly typed, not a plain array.
>
> Changed in v2:
> - Added "crypto: sha512 - use same state format as legacy drivers"
> - Fixed build on user-mode Linux
> - Fixed W=1 build warning by adding <linux/export.h>
> - Optimized __sha512_final() and __hmac_sha512_final() slightly
>
> Eric Biggers (17):
> crypto: sha512 - rename conflicting symbols
> lib/crypto/sha512: add support for SHA-384 and SHA-512
> lib/crypto/sha512: add HMAC-SHA384 and HMAC-SHA512 support
> lib/crypto/sha512: add KUnit tests for SHA-384 and SHA-512
> lib/crypto/sha256: add KUnit tests for SHA-224 and SHA-256
> crypto: riscv/sha512 - stop depending on sha512_generic_block_fn
> crypto: sha512 - replace sha512_generic with wrapper around SHA-512
> library
> crypto: sha512 - use same state format as legacy drivers
> lib/crypto/sha512: migrate arm-optimized SHA-512 code to library
> lib/crypto/sha512: migrate arm64-optimized SHA-512 code to library
> mips: cavium-octeon: move octeon-crypto.h into asm directory
> lib/crypto/sha512: migrate mips-optimized SHA-512 code to library
> lib/crypto/sha512: migrate riscv-optimized SHA-512 code to library
> lib/crypto/sha512: migrate s390-optimized SHA-512 code to library
> lib/crypto/sha512: migrate sparc-optimized SHA-512 code to library
> lib/crypto/sha512: migrate x86-optimized SHA-512 code to library
> crypto: sha512 - remove sha512_base.h
>
For the series,
Acked-by: Ard Biesheuvel <ardb@kernel.org>