user/sven/linux.git/include/crypto, branch next/master

Merge branch 'for-next' of https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux.git

2026-04-07T11:58:31Z

Merge branch 'libcrypto-next' of https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux.git

2026-04-07T11:57:04Z

Merge branch 'master' of https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git

2026-04-07T11:57:01Z

crypto: rng - Make crypto_stdrng_get_bytes() use normal RNG in non-FIPS mode

2026-04-03T00:56:12Z

"stdrng" is needed only in "FIPS mode". Therefore, make crypto_stdrng_get_bytes() delegate to either the normal Linux RNG or to "stdrng", depending on the current mode. This will eliminate the need to built the SP800-90A DRBG and its dependencies into CRYPTO_FIPS=n kernels. Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu

crypto: rng - Unexport "default RNG" symbols

2026-04-03T00:56:12Z

Now that crypto_default_rng, crypto_get_default_rng(), and crypto_put_default_rng() have no users outside crypto/rng.c itself, unexport them and make them static. Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu

crypto: rng - Add crypto_stdrng_get_bytes()

2026-04-03T00:56:11Z

All callers of crypto_get_default_rng() use the following sequence: crypto_get_default_rng() crypto_rng_get_bytes(crypto_default_rng, ...) crypto_put_default_rng() While it may have been intended that callers amortize the cost of getting and putting the "default RNG" (i.e. "stdrng") over multiple calls, in practice that optimization is never used. The callers just want a function that gets random bytes from the "stdrng". Therefore, add such a function: crypto_stdrng_get_bytes(). Importantly, this decouples the callers from the crypto_rng API. That allows a later commit to make this function simply call get_random_bytes_wait() unless the kernel is in "FIPS mode". Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu

lib/crypto: arm64/aes: Remove obsolete chunking logic

2026-04-01T20:02:09Z

Since commit aefbab8e77eb ("arm64: fpsimd: Preserve/restore kernel mode NEON at context switch"), kernel-mode NEON sections have been preemptible on arm64. And since commit 7dadeaa6e851 ("sched: Further restrict the preemption modes"), voluntary preemption is no longer supported on arm64 either. Therefore, there's no longer any need to limit the length of kernel-mode NEON sections on arm64. Simplify the AES-CBC-MAC code accordingly. Reviewed-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20260401000548.133151-2-ebiggers@kernel.org Signed-off-by: Eric Biggers

crypto: algif_aead - Revert to operating out-of-place

2026-03-31T08:11:47Z

This mostly reverts commit 72548b093ee3 except for the copying of the associated data. There is no benefit in operating in-place in algif_aead since the source and destination come from different mappings. Get rid of all the complexity added for in-place operation and just copy the AD directly. Fixes: 72548b093ee3 ("crypto: algif_aead - copy AAD from src to dst") Reported-by: Taeyang Lee <0wn@theori.io> Signed-off-by: Herbert Xu

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

2026-03-30T19:35:30Z

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

crypto: remove HKDF library

2026-03-27T14:35:03Z

Remove crypto/hkdf.c, since it's no longer used. Originally it had two users, but now both of them just inline the needed HMAC computations using the HMAC library APIs. That ends up being better, since it eliminates all the complexity and performance issues associated with the crypto_shash abstraction and multi-step HMAC input formatting. Acked-by: Ard Biesheuvel Acked-by: Christoph Hellwig Reviewed-by: Hannes Reinecke Signed-off-by: Eric Biggers Signed-off-by: Keith Busch