kernel/git/stable/linux.git/lib/crypto/tests/Kconfig, branch master

lib/crypto: tests: Add KUnit test suite for AES-GCM

2026-08-11T03:17:56+00:00

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 Link: https://patch.msgid.link/20260802233005.161467-6-ebiggers@kernel.org Signed-off-by: Eric Biggers

lib/crypto: tests: Add KUnit test suite for AES-CCM

2026-08-11T03:17:56+00:00

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 Link: https://patch.msgid.link/20260802233005.161467-5-ebiggers@kernel.org Signed-off-by: Eric Biggers

lib/crypto: aes: Add CCM support

2026-07-22T19:01:20+00:00

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

lib/crypto: aes: Add GCM support

2026-07-22T19:01:11+00:00

Add support for AES-GCM to the crypto library. This will be used to provide streamlined implementations of the "gcm(aes)" and "rfc4106(gcm(aes))" crypto_aead algorithms. Most users of these will also be able to switch to the library, which as usual will be faster and simpler, e.g.: - drivers/net/macsec.c - fs/smb/client/ - fs/smb/server/ - net/ceph/messenger_v2.c - net/mac80211/ (for both GMAC and GCMP) - net/tipc/crypto.c - security/keys/trusted-keys/trusted_dcp.c (I've already written proof-of-concept patches for all the above, and they helped inform the API design.) As usual, the architecture-optimized AES-GCM code will be migrated into the library as well (using the hooks provided in this commit as well as the GHASH ones), eliminating lots of repetitive boilerplate code. Incremental en/decryption is supported. Incremental operation is a bit controversial in AEAD APIs because users have to be careful not to consume any decrypted data that hasn't been authenticated yet. But I do think it's the right choice here. It's not fundamentally different from the existing incremental MAC APIs, and it's the only approach that's general enough to work well for all users in the kernel: - An array of virtually-addressed buffers (like that used by BoringSSL's EVP_AEAD_CTX_sealv() and EVP_AEAD_CTX_openv()) doesn't work in the kernel in general, since in some cases the data for a single AES-GCM message is contained in a large number of highmem pages that each need to be mapped into memory individually. That can be done efficiently only by using CPU-local mappings, but there is a limited number of those. Ceph messenger v2 is a great example, as it can send or receive up to 32 MiB in a single AES-GCM message. And it needs the en/decrypted data to go into a (potentially large) number of bvecs provided by a custom iterator, as well as into four virtually-addressed buffers, two of which can be large buffers in the vmalloc region. Even just allocating an array big enough to store all the pointers can be problematic in the kernel. There are cases in which decryption runs in GFP_NOIO context or even in softirq context, where memory allocations are not as reliable as they normally are. - Meanwhile, 'struct scatterlist' (the choice of crypto_aead) has turned out to be really inconvenient for anyone who *does* just have virtually-addressed buffers. This is especially true if they can be in the vmalloc region, including the stack, as in that case the conversion to a scatterlist has to be done page-by-page. And even for users who have all of their data in bare 'struct page', none of them actually use 'struct scatterlist' as their native data structure anyway. They actually use skbs, bvecs, or other formats. - iov_iter is attractive, but ultimately not general enough either (considering the Ceph case for example), but also too general in some ways (like having support for userspace addresses). Additional iter types like ITER_SKB would help a bit, but bloating iov_iter with more types would reduce performance elsewhere in the kernel. 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-7-ebiggers@kernel.org Link: https://patch.msgid.link/20260722021730.16897-1-ebiggers@kernel.org Signed-off-by: Eric Biggers

lib/crypto: aes: Add XTS support

2026-07-20T00:34:16+00:00

Add support for AES-XTS to the crypto library. This will be used to provide a streamlined implementation of the "xts(aes)" crypto_skcipher algorithm. I'm also planning to use this directly in fscrypt and blk-crypto-fallback. As usual, the architecture-optimized AES-XTS code will be migrated into the library as well (using the hooks provided in this commit), eliminating lots of repetitive boilerplate code. Compared to direct implementation of "xts(aes)", I've also eliminated the requirement for architectures to implement ciphertext stealing, as the library just handles it portably instead. That will simplify things considerably. Initial test coverage is provided by the crypto_skcipher support added in a later commit. I'm planning a KUnit test suite as well. Link: https://patch.msgid.link/20260715221153.246410-6-ebiggers@kernel.org Signed-off-by: Eric Biggers

lib/crypto: aes: Add CTR and XCTR support

2026-07-20T00:34:16+00:00

Add support for AES-CTR and AES-XCTR to the crypto library. These will be used to provide streamlined implementations of the "ctr(aes)" and "xctr(aes)" crypto_skcipher algorithms. Most users of "ctr(aes)" will also be able to switch to the library, which as usual will be simpler and faster, e.g.: - net/mac80211/fils_aead.c - net/mac802154/llsec.c As usual, the architecture-optimized AES-CTR and AES-XCTR code will be migrated into the library as well (using the hooks provided in this commit), eliminating lots of repetitive boilerplate code. This is also a prerequisite for supporting AES-GCM, AES-CCM, and AES-HCTR2 in the crypto library. Initial test coverage is provided by the crypto_skcipher support added in a later commit. I'm planning a KUnit test suite as well. Reviewed-by: Thomas Huth Link: https://patch.msgid.link/20260715221153.246410-5-ebiggers@kernel.org Signed-off-by: Eric Biggers

lib/crypto: aes: Add CBC and CBC-CTS support

2026-07-20T00:34:16+00:00

Add support for AES-CBC and AES-CBC-CTS to the crypto library. These will be used to provide streamlined implementations of the "cbc(aes)" and "cts(cbc(aes))" crypto_skcipher algorithms. Most users of these crypto_skcipher algorithms will also be able to switch to the library, which as usual will be simpler and faster, e.g.: - block/blk-crypto-fallback.c (for AES-128-CBC-ESSIV) - fs/crypto/crypto.c (for AES-128-CBC-ESSIV) - fs/crypto/fname.c (for AES-256-CTS and AES-128-CBC) - kernel/bpf/crypto.c - net/ceph/crypto.c - security/keys/encrypted-keys/encrypted.c As usual, the architecture-optimized AES-CBC and AES-CBC-CTS code will be migrated into the library as well (using the hooks provided in this commit), eliminating lots of repetitive boilerplate code. Initial test coverage is provided by the crypto_skcipher support added in a later commit. I'm planning a KUnit test suite as well. Reviewed-by: Thomas Huth Link: https://patch.msgid.link/20260715221153.246410-4-ebiggers@kernel.org Signed-off-by: Eric Biggers

lib/crypto: aes: Add ECB support

2026-07-20T00:34:16+00:00

Add support for AES-ECB to the crypto library. This will be used to provide a streamlined implementation of the "ecb(aes)" crypto_skcipher algorithm. fs/crypto/keysetup_v1.c will also use aes_ecb_encrypt() directly. As usual, the architecture-optimized AES-ECB code will be migrated into the library as well (using the hooks provided in this commit), eliminating lots of repetitive boilerplate code. ECB is obsolete of course, but we need this for parity with the traditional API and to support some odd users of ECB in the kernel. Initial test coverage is provided by the crypto_skcipher support added in a later commit. I'm planning a KUnit test suite as well. Create a documentation file libcrypto-unauth-encryption.rst to hold the documentation for this and other unauthenticated encryption modes. Reviewed-by: Thomas Huth Link: https://patch.msgid.link/20260715221153.246410-3-ebiggers@kernel.org Signed-off-by: Eric Biggers

lib/crypto: tests: Migrate ChaCha20Poly1305 self-test to KUnit

2026-03-30T19:35:30+00:00

Move the ChaCha20Poly1305 test from an ad-hoc self-test to a KUnit test. Keep the same test logic for now, just translated to KUnit. Moving to KUnit has multiple benefits, such as: - Consistency with the rest of the lib/crypto/ tests. - Kernel developers familiar with KUnit, which is used kernel-wide, can quickly understand the test and how to enable and run it. - The test will be automatically run by anyone using lib/crypto/.kunitconfig or KUnit's all_tests.config. - Results are reported using the standard KUnit mechanism. - It eliminates one of the few remaining back-references to crypto/ from lib/crypto/, specifically a reference to CONFIG_CRYPTO_SELFTESTS. Acked-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20260327224229.137532-1-ebiggers@kernel.org Signed-off-by: Eric Biggers

lib/crypto: tests: Add KUnit tests for SM3

2026-03-24T00:50:59+00:00

Add a KUnit test suite for the SM3 library. It closely mirrors the test suites for the other cryptographic hash functions. The actual test and benchmark logic is already in hash-test-template.h; this just wires it up for SM3 in the usual way. Acked-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20260321040935.410034-6-ebiggers@kernel.org Signed-off-by: Eric Biggers