C doesn't guarantee at the language level that an enum actually has one
of the declared values.
For robustness, make mldsa_verify() handle invalid values of 'alg'.
No effect on current callers, who always pass a valid value for 'alg'.
(Except for the KUnit test case that this commit adds.)
Fixes: 64edccea594c ("lib/crypto: Add ML-DSA verification support")
Cc: stable@vger.kernel.org
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://patch.msgid.link/20261029054534.68481-3-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
Pull crypto library updates from Eric Biggers: - Migrate the x86 and riscv optimized implementations of various AES modes (ECB, CBC, CBC-CTS, CTR, XCTR, XTS) into lib/crypto/. This makes the library APIs be properly accelerated on these architectures, while still accelerating crypto_skcipher as well. It removes a lot of redundant glue code, since the crypto API boilerplate no longer needs to be duplicated for these architectures. It also fixes the longstanding issue where optimizations for these AES modes were disabled by default on these architectures. - Optimize AES-XTS on SPARC64 using the SPARC crypto opcodes - Move the SipHash code into lib/crypto/ - Update the ChaCha and Poly1305 functions to take size_t lengths, resolving issues where lengths over INT_MAX were mishandled - Make frame pointer unwinding work properly in some of the x86 assembly functions, by following the standard %rbp convention - Add helper functions for zeroizing structs - Make a few documentation improvements * tag 'libcrypto-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux: (49 commits) lib/crypto: md5: remove unused header lib/crypto: mips/chacha: Handle lengths of 2 GiB or more lib/crypto: arm/chacha: Handle lengths of 2 GiB or more in scalar code lib/crypto: chacha: Use size_t length lib/crypto: poly1305: Use size_t length lib/crypto: x86/sha512: Follow the normal %rbp convention lib/crypto: x86/sha256: Follow the normal %rbp convention lib/crypto: x86/sha1: Follow the normal %rbp convention lib/crypto: chacha20poly1305: zeroize state in __chacha20poly1305_decrypt lib/crypto: sparc/aes-xts: Add optimization using the AES opcodes lib: Move SipHash into lib/crypto/ lib/crypto: x86/aes-ctr: Remove some unreachable code crypto: x86/aesni-intel - Add transitional selections crypto: aes - Boost priority of encryption modes further lib/crypto: x86/aes: Set RNDKEY in aes_cbc_encrypt_aesni() lib/crypto: riscv/aes-xts: Migrate optimized code into library lib/crypto: riscv/aes-ctr: Migrate optimized code into library lib/crypto: riscv/aes-cbc: Migrate optimized code into library lib/crypto: riscv/aes-ecb: Migrate optimized code into library lib/crypto: riscv/aes: Pass key struct to assembly code ...
Add a test case which reproduces the bug fixed by commit 24f07e8c07a0
("lib/crypto: arm64: Fix lost Poly1305 carry when resuming NEON state").
It is written in a fairly general way, such that it should also be able
to reproduce similar bugs in other implementations.
Update the comment on test_poly1305_allones_keys_and_message() to more
accurately describe what it does and differentiate it from the new test.
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
Link: https://patch.msgid.link/20261009125354.315476-3-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
The addition of SipHash to lib/ predated the existence of the lib/crypto/ directory. Since SipHash is a cryptographic algorithm, move it from the top-level lib/ directory to lib/crypto/. (This does mean HalfSipHash comes with it too, as it's in the same files. But lib/crypto/ still seems like the proper place for both.) Specifically: - Move both siphash.c and siphash_kunit.c. Keep the header <linux/siphash.h> as-is for now. - Drop the dedicated MAINTAINERS entry for SipHash, as per the suggestion from Jason (https://lore.kernel.org/r/asB7QVFMlgKgbje2@zx2c4.com/). The C files now just fold up to the "CRYPTO LIBRARY" entry. Add the header explicitly, as it otherwise would be left unmaintained. - Move the kconfig option that controls the KUnit test. Put "CRYPTO_LIB" in its name and update the prompt and help text to make it consistent with the other crypto library test options. - Enable the KUnit test in lib/crypto/.kunitconfig. - Link to siphash.rst from the appropriate place in libcrypto-hash.rst. - Use obj-y instead of lib-y, for consistency with the fact that currently lib/crypto/ doesn't use kbuild's support for library file goals. We could keep it as lib-y, but virtually every kernel needs SipHash support anyway (with vsprintf, printk, IPv4, IPv6, etc. depending on it) so there is no practical difference in this case. Acked-by: Ard Biesheuvel <ardb@kernel.org> Acked-by: Jason A. Donenfeld <Jason@zx2c4.com> Link: https://patch.msgid.link/20261003162827.155527-1-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
Add a KUnit test suite for the AES-GCM library API. It consists of: - All the shared test cases from aead-test-template.h. These include extensive consistency tests, a "Monte-Carlo test", and a benchmark. - Tests against hardcoded AES-GCM test vectors from external sources. Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Link: https://patch.msgid.link/20260802233005.161467-6-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
Add a KUnit test suite for the AES-CCM library API. It consists of: - All the shared test cases from aead-test-template.h. These include extensive consistency tests, a "Monte-Carlo test", and a benchmark. - Tests against hardcoded AES-CCM test vectors from external sources. - Tests for CCM-specific message length validation. To generate the expected aes_ccm_monte_carlo_checksum[] value, add a script gen-aead-testvecs.py which computes it using python-cryptography. Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Link: https://patch.msgid.link/20260802233005.161467-5-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
Add aead-test-template.h which contains shared test logic for AEAD algorithms. It's similar to the existing hash-test-template.h, which contains shared test logic for hash algorithms. The initial use cases for this will be AES-CCM and AES-GCM. It may be used by the existing ChaCha20Poly1305 test suite in the future as well, though the ChaCha20Poly1305 API currently lacks some of the functionality that the "template" expects to be present. Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Link: https://patch.msgid.link/20260802233005.161467-4-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
Make the test cases more self-contained by replacing the test suite
scoped guarded buffer ('test_buf') with buffers allocated by each test
case using the helper functions in test-utils.h.
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://patch.msgid.link/20260802233005.161467-3-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
Move hash-test-template's test RNG code and the buffer allocation code from various test suites into a header test-utils.h. This allows them to be shared by other test suites. Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Link: https://patch.msgid.link/20260802233005.161467-2-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
Add support for AES-CCM to the crypto library. This will be used to provide a streamlined implementation of the "ccm(aes)" crypto_aead algorithm. Most users of "ccm(aes)" will also be able to switch to the library, which as usual will be faster and simpler, e.g.: - fs/smb/client/ - fs/smb/server/ - net/mac80211/ - net/mac802154/ (I've already written proof-of-concept patches for all the above, and they helped inform the API design.) As in the AES-GCM API, incremental operation is supported. It has to be used carefully, especially when decrypting, but it makes the API general enough to work well for all users. The AES-CCM library code calls aes_cbcmac_blocks() directly, bypassing the higher-level aes_cbcmac_init(), aes_cbcmac_update(), and aes_cbcmac_final(). The latter set of functions is useful only for AES-CCM, so they don't make sense to keep around and will be removed once the "ccm(aes)" crypto_aead starts using the AES-CCM library. Initial test coverage is provided by the crypto_aead support added in a later commit. I'm planning a KUnit test suite as well. Link: https://patch.msgid.link/20260715221153.246410-8-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>