kernel/linux
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ synced 2026-11-10 20:48:12 +00:00
Code Issues Releases Packages Activity
linux/crypto/drbg.c

617 lines
18 KiB
Raw Permalink Normal View History

crypto: drbg - SP800-90A Deterministic Random Bit Generator This is a clean-room implementation of the DRBG defined in SP800-90A. All three viable DRBGs defined in the standard are implemented: * HMAC: This is the leanest DRBG and compiled per default * Hash: The more complex DRBG can be enabled at compile time * CTR: The most complex DRBG can also be enabled at compile time The DRBG implementation offers the following: * All three DRBG types are implemented with a derivation function. * All DRBG types are available with and without prediction resistance. * All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available for the HMAC and Hash DRBGs. * All AES types of AES-128, AES-192 and AES-256 are available for the CTR DRBG. * A self test is implemented with drbg_healthcheck(). * The FIPS 140-2 continuous self test is implemented. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-05-31 15:44:17 +02:00
crypto: drbg - Remove support for "prediction resistance" "Prediction resistance", i.e. the property that the RNG's output is unpredictable even after a state compromise, might sound like a nice property to have. In reality, it's not very practical, as it requires that fresh entropy be pulled on every request. (The normal Linux RNG doesn't provide prediction resistance.) In the case of drbg.c, that means pulling from "jitterentropy", which is extremely slow. For some perspective, running a simple benchmark, generating 32 random bytes takes the following amount of time: get_random_bytes(): 90 ns drbg_nopr_hmac_sha512: 3707 ns drbg_pr_hmac_sha512: 773082 ns So at least in this case, the "pr" (prediction-resistant) DRBG is over 200 times slower than the "nopr" (non-prediction-resistant) DRBG, or over 8000 times slower than the normal Linux RNG. While anyone using drbg.c has always had to tolerate that it's slower than the normal Linux RNG, the "pr" DRBG is clearly at another level of slowness. Thus, the following is also entirely unsurprising: - FIPS 140-3 doesn't actually require that SP800-90A DRBG implementations support prediction resistance. The non-prediction resistant DRBGs can be, and have been, certified. - drbg.c registers "drbg_nopr_hmac_sha512" with a higher cra_priority than "drbg_pr_hmac_sha512". So "drbg_nopr_hmac_sha512" is already the one actually being used in practice. Given these considerations, it's clear that "drbg_pr_hmac_sha512" isn't actually useful, and it essentially just existed as another curiosity in the museum of crypto algorithms. Remove it to simplify the code. Suggested-by: Joachim Vandersmissen <joachim@jvdsn.com> Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-05-05 17:02:58 -07:00
crypto: drbg - SP800-90A Deterministic Random Bit Generator This is a clean-room implementation of the DRBG defined in SP800-90A. All three viable DRBGs defined in the standard are implemented: * HMAC: This is the leanest DRBG and compiled per default * Hash: The more complex DRBG can be enabled at compile time * CTR: The most complex DRBG can also be enabled at compile time The DRBG implementation offers the following: * All three DRBG types are implemented with a derivation function. * All DRBG types are available with and without prediction resistance. * All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available for the HMAC and Hash DRBGs. * All AES types of AES-128, AES-192 and AES-256 are available for the CTR DRBG. * A self test is implemented with drbg_healthcheck(). * The FIPS 140-2 continuous self test is implemented. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-05-31 15:44:17 +02:00
crypto: drbg - Use HMAC-SHA512 library API Since the HMAC algorithm is now fixed at HMAC-SHA512, just use the HMAC-SHA512 library API. This is simpler and more efficient. Remove error-handling code that is no longer needed. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:06 -07:00
crypto: drbg - SP800-90A Deterministic Random Bit Generator This is a clean-room implementation of the DRBG defined in SP800-90A. All three viable DRBGs defined in the standard are implemented: * HMAC: This is the leanest DRBG and compiled per default * Hash: The more complex DRBG can be enabled at compile time * CTR: The most complex DRBG can also be enabled at compile time The DRBG implementation offers the following: * All three DRBG types are implemented with a derivation function. * All DRBG types are available with and without prediction resistance. * All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available for the HMAC and Hash DRBGs. * All AES types of AES-128, AES-192 and AES-256 are available for the CTR DRBG. * A self test is implemented with drbg_healthcheck(). * The FIPS 140-2 continuous self test is implemented. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-05-31 15:44:17 +02:00
crypto: drbg - Remove unhelpful helper functions Fold the contents of the inline functions crypto_drbg_get_bytes_addtl(), crypto_drbg_get_bytes_addtl_test(), and crypto_drbg_reset_test() into their only caller in drbg_cavs_test(). It ends up being much simpler. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:33:52 -07:00
crypto: drbg - SP800-90A Deterministic Random Bit Generator This is a clean-room implementation of the DRBG defined in SP800-90A. All three viable DRBGs defined in the standard are implemented: * HMAC: This is the leanest DRBG and compiled per default * Hash: The more complex DRBG can be enabled at compile time * CTR: The most complex DRBG can also be enabled at compile time The DRBG implementation offers the following: * All three DRBG types are implemented with a derivation function. * All DRBG types are available with and without prediction resistance. * All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available for the HMAC and Hash DRBGs. * All AES types of AES-128, AES-192 and AES-256 are available for the CTR DRBG. * A self test is implemented with drbg_healthcheck(). * The FIPS 140-2 continuous self test is implemented. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-05-31 15:44:17 +02:00
crypto: drbg - Remove unhelpful helper functions Fold the contents of the inline functions crypto_drbg_get_bytes_addtl(), crypto_drbg_get_bytes_addtl_test(), and crypto_drbg_reset_test() into their only caller in drbg_cavs_test(). It ends up being much simpler. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:33:52 -07:00
crypto: drbg - SP800-90A Deterministic Random Bit Generator This is a clean-room implementation of the DRBG defined in SP800-90A. All three viable DRBGs defined in the standard are implemented: * HMAC: This is the leanest DRBG and compiled per default * Hash: The more complex DRBG can be enabled at compile time * CTR: The most complex DRBG can also be enabled at compile time The DRBG implementation offers the following: * All three DRBG types are implemented with a derivation function. * All DRBG types are available with and without prediction resistance. * All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available for the HMAC and Hash DRBGs. * All AES types of AES-128, AES-192 and AES-256 are available for the CTR DRBG. * A self test is implemented with drbg_healthcheck(). * The FIPS 140-2 continuous self test is implemented. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-05-31 15:44:17 +02:00
crypto: drbg - Remove unhelpful helper functions Fold the contents of the inline functions crypto_drbg_get_bytes_addtl(), crypto_drbg_get_bytes_addtl_test(), and crypto_drbg_reset_test() into their only caller in drbg_cavs_test(). It ends up being much simpler. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:33:52 -07:00
crypto: drbg - SP800-90A Deterministic Random Bit Generator This is a clean-room implementation of the DRBG defined in SP800-90A. All three viable DRBGs defined in the standard are implemented: * HMAC: This is the leanest DRBG and compiled per default * Hash: The more complex DRBG can be enabled at compile time * CTR: The most complex DRBG can also be enabled at compile time The DRBG implementation offers the following: * All three DRBG types are implemented with a derivation function. * All DRBG types are available with and without prediction resistance. * All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available for the HMAC and Hash DRBGs. * All AES types of AES-128, AES-192 and AES-256 are available for the CTR DRBG. * A self test is implemented with drbg_healthcheck(). * The FIPS 140-2 continuous self test is implemented. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-05-31 15:44:17 +02:00
crypto: drbg - Fold include/crypto/drbg.h into crypto/drbg.c include/crypto/drbg.h no longer contains anything that is used externally to crypto/drbg.c. Therefore, fold it into crypto/drbg.c. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:33:54 -07:00
crypto: drbg - Move fixed values into constants Since only one drbg_core remains, the state length, block length, and security strength are now fixed values. Moreover, the maximum request length, maximum additional data length, and maximum number of requests were all already fixed values. Simplify the code by just using #defines for all these fixed values. In drbg_seed_from_random(), take advantage of the constant to define the array size. Remove assertions that are no longer useful. In the case of drbg_blocklen() and drbg_statelen(), replace these with a single value DRBG_STATE_LEN, as for HMAC_DRBG they are the same thing. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:04 -07:00
crypto: drbg - Fold include/crypto/drbg.h into crypto/drbg.c include/crypto/drbg.h no longer contains anything that is used externally to crypto/drbg.c. Therefore, fold it into crypto/drbg.c. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:33:54 -07:00
crypto: drbg - Use callback API for random readiness The get_blocking_random_bytes API is broken because the wait can be arbitrarily long (potentially forever) so there is no safe way of calling it from within the kernel. This patch replaces it with the new callback API which does not have this problem. The patch also removes the entropy buffer registered with the DRBG handle in favor of stack variables to hold the seed data. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-06-09 21:55:38 +08:00
crypto: drbg - Fold include/crypto/drbg.h into crypto/drbg.c include/crypto/drbg.h no longer contains anything that is used externally to crypto/drbg.c. Therefore, fold it into crypto/drbg.c. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:33:54 -07:00
crypto: drbg - Use str_true_false() and str_enabled_disabled() helpers Remove hard-coded strings by using the helper functions str_true_false() and str_enabled_disabled(). Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2024-10-16 15:57:28 +02:00
crypto: drbg - Fix misaligned writes in CTR_DRBG and HASH_DRBG drbg_cpu_to_be32() is being used to do a plain write to a byte array, which doesn't have any alignment guarantee. This can cause a misaligned write. Replace it with the correct function, put_unaligned_be32(). Fixes: 72f3e00dd67e ("crypto: drbg - replace int2byte with cpu_to_be") Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:33:46 -07:00
crypto: drbg - SP800-90A Deterministic Random Bit Generator This is a clean-room implementation of the DRBG defined in SP800-90A. All three viable DRBGs defined in the standard are implemented: * HMAC: This is the leanest DRBG and compiled per default * Hash: The more complex DRBG can be enabled at compile time * CTR: The most complex DRBG can also be enabled at compile time The DRBG implementation offers the following: * All three DRBG types are implemented with a derivation function. * All DRBG types are available with and without prediction resistance. * All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available for the HMAC and Hash DRBGs. * All AES types of AES-128, AES-192 and AES-256 are available for the CTR DRBG. * A self test is implemented with drbg_healthcheck(). * The FIPS 140-2 continuous self test is implemented. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-05-31 15:44:17 +02:00
crypto: drbg - Move fixed values into constants Since only one drbg_core remains, the state length, block length, and security strength are now fixed values. Moreover, the maximum request length, maximum additional data length, and maximum number of requests were all already fixed values. Simplify the code by just using #defines for all these fixed values. In drbg_seed_from_random(), take advantage of the constant to define the array size. Remove assertions that are no longer useful. In the case of drbg_blocklen() and drbg_statelen(), replace these with a single value DRBG_STATE_LEN, as for HMAC_DRBG they are the same thing. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:04 -07:00
crypto: drbg - Change DRBG_MAX_REQUESTS to 4096 Currently a formal reseed happens only after each 1048576 requests. That's quite a high number. Let's follow the example of BoringSSL and use a more conservative value of 4096. Note that in practice this makes little difference, now that we're including 32 bytes from get_random_bytes() in the additional input on every request anyway, which is a de facto reseed. But for the same reason, we might as well decrease the actual reseed interval to something more reasonable. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:19 -07:00
crypto: drbg - Move fixed values into constants Since only one drbg_core remains, the state length, block length, and security strength are now fixed values. Moreover, the maximum request length, maximum additional data length, and maximum number of requests were all already fixed values. Simplify the code by just using #defines for all these fixed values. In drbg_seed_from_random(), take advantage of the constant to define the array size. Remove assertions that are no longer useful. In the case of drbg_blocklen() and drbg_statelen(), replace these with a single value DRBG_STATE_LEN, as for HMAC_DRBG they are the same thing. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:04 -07:00
crypto: drbg - Rename MAX_ADDTL => MAX_ADDTL_BYTES Give this constant a name which is clearer and consistent with DRBG_MAX_REQUEST_BYTES. No functional change. Suggested-by: Joachim Vandersmissen <joachim@jvdsn.com> Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-05-05 17:02:17 -07:00
crypto: drbg - Move fixed values into constants Since only one drbg_core remains, the state length, block length, and security strength are now fixed values. Moreover, the maximum request length, maximum additional data length, and maximum number of requests were all already fixed values. Simplify the code by just using #defines for all these fixed values. In drbg_seed_from_random(), take advantage of the constant to define the array size. Remove assertions that are no longer useful. In the case of drbg_blocklen() and drbg_statelen(), replace these with a single value DRBG_STATE_LEN, as for HMAC_DRBG they are the same thing. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:04 -07:00
crypto: drbg - Fold include/crypto/drbg.h into crypto/drbg.c include/crypto/drbg.h no longer contains anything that is used externally to crypto/drbg.c. Therefore, fold it into crypto/drbg.c. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:33:54 -07:00
crypto: drbg - Embed V and C into struct drbg_state Now that the sizes of V and C are known at compile time, embed them into struct drbg_state rather than using separate allocations. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:05 -07:00
crypto: drbg - Use HMAC-SHA512 library API Since the HMAC algorithm is now fixed at HMAC-SHA512, just use the HMAC-SHA512 library API. This is simpler and more efficient. Remove error-handling code that is no longer needed. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:06 -07:00
crypto: drbg - Remove support for HASH_DRBG Remove the support for HASH_DRBG. It's likely unused code, seeing as HMAC_DRBG is always enabled and prioritized over it unless NETLINK_CRYPTO is used to change the algorithm priorities. There's also no compelling reason to support more than one of [HMAC_DRBG, HASH_DRBG, CTR_DRBG]. By definition, callers cannot tell any difference in their outputs. And all are FIPS-certifiable, which is the only point of the kernel's NIST DRBGs anyway. Switching to HASH_DRBG doesn't seem all that compelling, either. For one, it's more complex than HMAC_DRBG. Thus, let's just drop HASH_DRBG support and focus on HMAC_DRBG. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> # m68k Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:33:57 -07:00
crypto: drbg - Fold include/crypto/drbg.h into crypto/drbg.c include/crypto/drbg.h no longer contains anything that is used externally to crypto/drbg.c. Therefore, fold it into crypto/drbg.c. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:33:54 -07:00
crypto: drbg - Remove drbg_core Now that none of the information in struct drbg_core is used, remove it. The null-ity of the pointer drbg_state::core was used to keep track of whether the DRBG has been instantiated. Replace it with a boolean. No functional change. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:07 -07:00
crypto: drbg - Fold include/crypto/drbg.h into crypto/drbg.c include/crypto/drbg.h no longer contains anything that is used externally to crypto/drbg.c. Therefore, fold it into crypto/drbg.c. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:33:54 -07:00
crypto: drbg - Eliminate use of 'drbg_string' and lists Use straightforward (buffer, len) parameters instead of struct drbg_string or lists of strings. This simplifies the code considerably. For now struct drbg_string is still used in crypto_drbg_ctr_df(), so move its definition to crypto/df_sp80090a.h. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:11 -07:00
crypto: drbg - Fold include/crypto/drbg.h into crypto/drbg.c include/crypto/drbg.h no longer contains anything that is used externally to crypto/drbg.c. Therefore, fold it into crypto/drbg.c. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:33:54 -07:00
crypto: drbg - SP800-90A Deterministic Random Bit Generator This is a clean-room implementation of the DRBG defined in SP800-90A. All three viable DRBGs defined in the standard are implemented: * HMAC: This is the leanest DRBG and compiled per default * Hash: The more complex DRBG can be enabled at compile time * CTR: The most complex DRBG can also be enabled at compile time The DRBG implementation offers the following: * All three DRBG types are implemented with a derivation function. * All DRBG types are available with and without prediction resistance. * All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available for the HMAC and Hash DRBGs. * All AES types of AES-128, AES-192 and AES-256 are available for the CTR DRBG. * A self test is implemented with drbg_healthcheck(). * The FIPS 140-2 continuous self test is implemented. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-05-31 15:44:17 +02:00
crypto: drbg - De-virtualize drbg_state_ops Now that there's only one set of state operations, use direct calls to those operations. No change in behavior. In particular, drbg_alloc_state() doesn't change behavior, because the only remaining drbg_core uses HMAC_DRBG. drbg_uninstantiate() doesn't change behavior, because a NULL d_ops implied NULL priv_data which makes a drbg_fini_hash_kernel() a no-op. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:03 -07:00
crypto: drbg - SP800-90A Deterministic Random Bit Generator This is a clean-room implementation of the DRBG defined in SP800-90A. All three viable DRBGs defined in the standard are implemented: * HMAC: This is the leanest DRBG and compiled per default * Hash: The more complex DRBG can be enabled at compile time * CTR: The most complex DRBG can also be enabled at compile time The DRBG implementation offers the following: * All three DRBG types are implemented with a derivation function. * All DRBG types are available with and without prediction resistance. * All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available for the HMAC and Hash DRBGs. * All AES types of AES-128, AES-192 and AES-256 are available for the CTR DRBG. * A self test is implemented with drbg_healthcheck(). * The FIPS 140-2 continuous self test is implemented. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-05-31 15:44:17 +02:00
crypto: drbg - Eliminate use of 'drbg_string' and lists Use straightforward (buffer, len) parameters instead of struct drbg_string or lists of strings. This simplifies the code considerably. For now struct drbg_string is still used in crypto_drbg_ctr_df(), so move its definition to crypto/df_sp80090a.h. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:11 -07:00
crypto: drbg - SP800-90A Deterministic Random Bit Generator This is a clean-room implementation of the DRBG defined in SP800-90A. All three viable DRBGs defined in the standard are implemented: * HMAC: This is the leanest DRBG and compiled per default * Hash: The more complex DRBG can be enabled at compile time * CTR: The most complex DRBG can also be enabled at compile time The DRBG implementation offers the following: * All three DRBG types are implemented with a derivation function. * All DRBG types are available with and without prediction resistance. * All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available for the HMAC and Hash DRBGs. * All AES types of AES-128, AES-192 and AES-256 are available for the CTR DRBG. * A self test is implemented with drbg_healthcheck(). * The FIPS 140-2 continuous self test is implemented. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-05-31 15:44:17 +02:00
crypto: drbg - Use HMAC-SHA512 library API Since the HMAC algorithm is now fixed at HMAC-SHA512, just use the HMAC-SHA512 library API. This is simpler and more efficient. Remove error-handling code that is no longer needed. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:06 -07:00
crypto: drbg - Consolidate "instantiate" logic and remove drbg_state::C Currently some of the steps of "Instantiate the DRBG" occur in a convoluted way in different places in the call stack: drbg_instantiate() => drbg_seed(reseed=0) sets the raw HMAC key drbg_state::C to its correct initial value, and it sets the state value drbg_state::V to an *incorrect* initial value. => drbg_hmac_update(reseed=0) overwrites drbg_state::V with the correct initial value, then prepares the hmac_sha512_key drbg_state::key from the initial raw HMAC key drbg_state::C. Later, each time the HMAC key is updated, drbg_hmac_update() also uses drbg_state::C to temporarily store the new raw key. Simplify all of this by: - Making drbg_instantiate() set the correct initial values of drbg_state::V and drbg_state::key. - Converting drbg_hmac_update() to generate the raw key in a temporary on-stack array instead of drbg_state::C. - Removing drbg_state::C. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:10 -07:00
crypto: drbg - SP800-90A Deterministic Random Bit Generator This is a clean-room implementation of the DRBG defined in SP800-90A. All three viable DRBGs defined in the standard are implemented: * HMAC: This is the leanest DRBG and compiled per default * Hash: The more complex DRBG can be enabled at compile time * CTR: The most complex DRBG can also be enabled at compile time The DRBG implementation offers the following: * All three DRBG types are implemented with a derivation function. * All DRBG types are available with and without prediction resistance. * All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available for the HMAC and Hash DRBGs. * All AES types of AES-128, AES-192 and AES-256 are available for the CTR DRBG. * A self test is implemented with drbg_healthcheck(). * The FIPS 140-2 continuous self test is implemented. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-05-31 15:44:17 +02:00
crypto: drbg - Clean up loop in drbg_hmac_update() This loop is a bit hard to read, with the loop counter that's used in the HMAC being separate from the actual loop counter, which counts backwards for some reason. Just replace it with a regular loop. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:22 -07:00
crypto: drbg - SP800-90A Deterministic Random Bit Generator This is a clean-room implementation of the DRBG defined in SP800-90A. All three viable DRBGs defined in the standard are implemented: * HMAC: This is the leanest DRBG and compiled per default * Hash: The more complex DRBG can be enabled at compile time * CTR: The most complex DRBG can also be enabled at compile time The DRBG implementation offers the following: * All three DRBG types are implemented with a derivation function. * All DRBG types are available with and without prediction resistance. * All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available for the HMAC and Hash DRBGs. * All AES types of AES-128, AES-192 and AES-256 are available for the CTR DRBG. * A self test is implemented with drbg_healthcheck(). * The FIPS 140-2 continuous self test is implemented. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-05-31 15:44:17 +02:00
crypto: drbg - Use HMAC-SHA512 library API Since the HMAC algorithm is now fixed at HMAC-SHA512, just use the HMAC-SHA512 library API. This is simpler and more efficient. Remove error-handling code that is no longer needed. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:06 -07:00
crypto: drbg - Clean up loop in drbg_hmac_update() This loop is a bit hard to read, with the loop counter that's used in the HMAC being separate from the actual loop counter, which counts backwards for some reason. Just replace it with a regular loop. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:22 -07:00
crypto: drbg - Eliminate use of 'drbg_string' and lists Use straightforward (buffer, len) parameters instead of struct drbg_string or lists of strings. This simplifies the code considerably. For now struct drbg_string is still used in crypto_drbg_ctr_df(), so move its definition to crypto/df_sp80090a.h. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:11 -07:00
crypto: drbg - Consolidate "instantiate" logic and remove drbg_state::C Currently some of the steps of "Instantiate the DRBG" occur in a convoluted way in different places in the call stack: drbg_instantiate() => drbg_seed(reseed=0) sets the raw HMAC key drbg_state::C to its correct initial value, and it sets the state value drbg_state::V to an *incorrect* initial value. => drbg_hmac_update(reseed=0) overwrites drbg_state::V with the correct initial value, then prepares the hmac_sha512_key drbg_state::key from the initial raw HMAC key drbg_state::C. Later, each time the HMAC key is updated, drbg_hmac_update() also uses drbg_state::C to temporarily store the new raw key. Simplify all of this by: - Making drbg_instantiate() set the correct initial values of drbg_state::V and drbg_state::key. - Converting drbg_hmac_update() to generate the raw key in a temporary on-stack array instead of drbg_state::C. - Removing drbg_state::C. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:10 -07:00
crypto: drbg - SP800-90A Deterministic Random Bit Generator This is a clean-room implementation of the DRBG defined in SP800-90A. All three viable DRBGs defined in the standard are implemented: * HMAC: This is the leanest DRBG and compiled per default * Hash: The more complex DRBG can be enabled at compile time * CTR: The most complex DRBG can also be enabled at compile time The DRBG implementation offers the following: * All three DRBG types are implemented with a derivation function. * All DRBG types are available with and without prediction resistance. * All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available for the HMAC and Hash DRBGs. * All AES types of AES-128, AES-192 and AES-256 are available for the CTR DRBG. * A self test is implemented with drbg_healthcheck(). * The FIPS 140-2 continuous self test is implemented. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-05-31 15:44:17 +02:00
crypto: drbg - Use HMAC-SHA512 library API Since the HMAC algorithm is now fixed at HMAC-SHA512, just use the HMAC-SHA512 library API. This is simpler and more efficient. Remove error-handling code that is no longer needed. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:06 -07:00
crypto: drbg - SP800-90A Deterministic Random Bit Generator This is a clean-room implementation of the DRBG defined in SP800-90A. All three viable DRBGs defined in the standard are implemented: * HMAC: This is the leanest DRBG and compiled per default * Hash: The more complex DRBG can be enabled at compile time * CTR: The most complex DRBG can also be enabled at compile time The DRBG implementation offers the following: * All three DRBG types are implemented with a derivation function. * All DRBG types are available with and without prediction resistance. * All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available for the HMAC and Hash DRBGs. * All AES types of AES-128, AES-192 and AES-256 are available for the CTR DRBG. * A self test is implemented with drbg_healthcheck(). * The FIPS 140-2 continuous self test is implemented. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-05-31 15:44:17 +02:00
crypto: drbg - Eliminate use of 'drbg_string' and lists Use straightforward (buffer, len) parameters instead of struct drbg_string or lists of strings. This simplifies the code considerably. For now struct drbg_string is still used in crypto_drbg_ctr_df(), so move its definition to crypto/df_sp80090a.h. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:11 -07:00
crypto: drbg - Use HMAC-SHA512 library API Since the HMAC algorithm is now fixed at HMAC-SHA512, just use the HMAC-SHA512 library API. This is simpler and more efficient. Remove error-handling code that is no longer needed. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:06 -07:00
crypto: drbg - SP800-90A Deterministic Random Bit Generator This is a clean-room implementation of the DRBG defined in SP800-90A. All three viable DRBGs defined in the standard are implemented: * HMAC: This is the leanest DRBG and compiled per default * Hash: The more complex DRBG can be enabled at compile time * CTR: The most complex DRBG can also be enabled at compile time The DRBG implementation offers the following: * All three DRBG types are implemented with a derivation function. * All DRBG types are available with and without prediction resistance. * All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available for the HMAC and Hash DRBGs. * All AES types of AES-128, AES-192 and AES-256 are available for the CTR DRBG. * A self test is implemented with drbg_healthcheck(). * The FIPS 140-2 continuous self test is implemented. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-05-31 15:44:17 +02:00
crypto: drbg - Consolidate "instantiate" logic and remove drbg_state::C Currently some of the steps of "Instantiate the DRBG" occur in a convoluted way in different places in the call stack: drbg_instantiate() => drbg_seed(reseed=0) sets the raw HMAC key drbg_state::C to its correct initial value, and it sets the state value drbg_state::V to an *incorrect* initial value. => drbg_hmac_update(reseed=0) overwrites drbg_state::V with the correct initial value, then prepares the hmac_sha512_key drbg_state::key from the initial raw HMAC key drbg_state::C. Later, each time the HMAC key is updated, drbg_hmac_update() also uses drbg_state::C to temporarily store the new raw key. Simplify all of this by: - Making drbg_instantiate() set the correct initial values of drbg_state::V and drbg_state::key. - Converting drbg_hmac_update() to generate the raw key in a temporary on-stack array instead of drbg_state::C. - Removing drbg_state::C. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:10 -07:00
crypto: drbg - SP800-90A Deterministic Random Bit Generator This is a clean-room implementation of the DRBG defined in SP800-90A. All three viable DRBGs defined in the standard are implemented: * HMAC: This is the leanest DRBG and compiled per default * Hash: The more complex DRBG can be enabled at compile time * CTR: The most complex DRBG can also be enabled at compile time The DRBG implementation offers the following: * All three DRBG types are implemented with a derivation function. * All DRBG types are available with and without prediction resistance. * All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available for the HMAC and Hash DRBGs. * All AES types of AES-128, AES-192 and AES-256 are available for the CTR DRBG. * A self test is implemented with drbg_healthcheck(). * The FIPS 140-2 continuous self test is implemented. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-05-31 15:44:17 +02:00
crypto: drbg - Clean up generation code A few miscellaneous cleanups to make the code a bit more readable: - Replace (buf, buflen) with (out, outlen) - Update (out, outlen) as we go along - Use size_t for lengths - Use min() - Adjust some comments and log messages - Rename a variable named 'len' to 'err', since it isn't a length Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:21 -07:00
crypto: drbg - Include get_random_bytes() output in additional input Woodage & Shumow (2018) (https://eprint.iacr.org/2018/349.pdf) showed that contrary to the claims made by NIST in SP800-90A, HMAC_DRBG doesn't satisfy the formal definition of forward secrecy (i.e. "backtracking resistance") when it's called with an empty additional input string. The actual attack seems pretty benign, as it doesn't actually give the attacker any previous RNG output, but rather just allows them to test whether their guess of the previous block of RNG output is correct. Regardless, it's an annoying design flaw, and it's yet another example of why NIST's DRBGs aren't all that great. Meanwhile, the kernel's HMAC_DRBG code also tries to reseed itself automatically after random.c has reseeded itself. But the implementation is buggy, as it just checks whether 300 seconds have elapsed, rather than looking at the actual generation counter. Let's just follow the example of BoringSSL and use the conservative approach of always including 32 bytes of "regular" random data in the additional input string. This fixes both issues described above. This does reduce performance. But this should be tolerable, since: - Due to earlier changes, the kernel code that was previously using drbg.c regardless of FIPS mode is now using it only in FIPS mode. - The additional input string is processed only once per request. So if a lot of bytes are generated at once, the cost is amortized. - The NIST DRBGs are notoriously slow anyway. Note that this fix should have no impact (either positive or negative) on FIPS 140 certifiability. From FIPS's point of view the code added by this commit simply doesn't matter: it adds zero entropy to something that doesn't need to contain entropy. Fixes: 541af946fe13 ("crypto: drbg - SP800-90A Deterministic Random Bit Generator") Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:18 -07:00
crypto: drbg - SP800-90A Deterministic Random Bit Generator This is a clean-room implementation of the DRBG defined in SP800-90A. All three viable DRBGs defined in the standard are implemented: * HMAC: This is the leanest DRBG and compiled per default * Hash: The more complex DRBG can be enabled at compile time * CTR: The most complex DRBG can also be enabled at compile time The DRBG implementation offers the following: * All three DRBG types are implemented with a derivation function. * All DRBG types are available with and without prediction resistance. * All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available for the HMAC and Hash DRBGs. * All AES types of AES-128, AES-192 and AES-256 are available for the CTR DRBG. * A self test is implemented with drbg_healthcheck(). * The FIPS 140-2 continuous self test is implemented. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-05-31 15:44:17 +02:00
crypto: drbg - Include get_random_bytes() output in additional input Woodage & Shumow (2018) (https://eprint.iacr.org/2018/349.pdf) showed that contrary to the claims made by NIST in SP800-90A, HMAC_DRBG doesn't satisfy the formal definition of forward secrecy (i.e. "backtracking resistance") when it's called with an empty additional input string. The actual attack seems pretty benign, as it doesn't actually give the attacker any previous RNG output, but rather just allows them to test whether their guess of the previous block of RNG output is correct. Regardless, it's an annoying design flaw, and it's yet another example of why NIST's DRBGs aren't all that great. Meanwhile, the kernel's HMAC_DRBG code also tries to reseed itself automatically after random.c has reseeded itself. But the implementation is buggy, as it just checks whether 300 seconds have elapsed, rather than looking at the actual generation counter. Let's just follow the example of BoringSSL and use the conservative approach of always including 32 bytes of "regular" random data in the additional input string. This fixes both issues described above. This does reduce performance. But this should be tolerable, since: - Due to earlier changes, the kernel code that was previously using drbg.c regardless of FIPS mode is now using it only in FIPS mode. - The additional input string is processed only once per request. So if a lot of bytes are generated at once, the cost is amortized. - The NIST DRBGs are notoriously slow anyway. Note that this fix should have no impact (either positive or negative) on FIPS 140 certifiability. From FIPS's point of view the code added by this commit simply doesn't matter: it adds zero entropy to something that doesn't need to contain entropy. Fixes: 541af946fe13 ("crypto: drbg - SP800-90A Deterministic Random Bit Generator") Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:18 -07:00
crypto: drbg - SP800-90A Deterministic Random Bit Generator This is a clean-room implementation of the DRBG defined in SP800-90A. All three viable DRBGs defined in the standard are implemented: * HMAC: This is the leanest DRBG and compiled per default * Hash: The more complex DRBG can be enabled at compile time * CTR: The most complex DRBG can also be enabled at compile time The DRBG implementation offers the following: * All three DRBG types are implemented with a derivation function. * All DRBG types are available with and without prediction resistance. * All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available for the HMAC and Hash DRBGs. * All AES types of AES-128, AES-192 and AES-256 are available for the CTR DRBG. * A self test is implemented with drbg_healthcheck(). * The FIPS 140-2 continuous self test is implemented. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-05-31 15:44:17 +02:00
crypto: drbg - Include get_random_bytes() output in additional input Woodage & Shumow (2018) (https://eprint.iacr.org/2018/349.pdf) showed that contrary to the claims made by NIST in SP800-90A, HMAC_DRBG doesn't satisfy the formal definition of forward secrecy (i.e. "backtracking resistance") when it's called with an empty additional input string. The actual attack seems pretty benign, as it doesn't actually give the attacker any previous RNG output, but rather just allows them to test whether their guess of the previous block of RNG output is correct. Regardless, it's an annoying design flaw, and it's yet another example of why NIST's DRBGs aren't all that great. Meanwhile, the kernel's HMAC_DRBG code also tries to reseed itself automatically after random.c has reseeded itself. But the implementation is buggy, as it just checks whether 300 seconds have elapsed, rather than looking at the actual generation counter. Let's just follow the example of BoringSSL and use the conservative approach of always including 32 bytes of "regular" random data in the additional input string. This fixes both issues described above. This does reduce performance. But this should be tolerable, since: - Due to earlier changes, the kernel code that was previously using drbg.c regardless of FIPS mode is now using it only in FIPS mode. - The additional input string is processed only once per request. So if a lot of bytes are generated at once, the cost is amortized. - The NIST DRBGs are notoriously slow anyway. Note that this fix should have no impact (either positive or negative) on FIPS 140 certifiability. From FIPS's point of view the code added by this commit simply doesn't matter: it adds zero entropy to something that doesn't need to contain entropy. Fixes: 541af946fe13 ("crypto: drbg - SP800-90A Deterministic Random Bit Generator") Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:18 -07:00
crypto: drbg - SP800-90A Deterministic Random Bit Generator This is a clean-room implementation of the DRBG defined in SP800-90A. All three viable DRBGs defined in the standard are implemented: * HMAC: This is the leanest DRBG and compiled per default * Hash: The more complex DRBG can be enabled at compile time * CTR: The most complex DRBG can also be enabled at compile time The DRBG implementation offers the following: * All three DRBG types are implemented with a derivation function. * All DRBG types are available with and without prediction resistance. * All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available for the HMAC and Hash DRBGs. * All AES types of AES-128, AES-192 and AES-256 are available for the CTR DRBG. * A self test is implemented with drbg_healthcheck(). * The FIPS 140-2 continuous self test is implemented. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-05-31 15:44:17 +02:00
crypto: drbg - Clean up generation code A few miscellaneous cleanups to make the code a bit more readable: - Replace (buf, buflen) with (out, outlen) - Update (out, outlen) as we go along - Use size_t for lengths - Use min() - Adjust some comments and log messages - Rename a variable named 'len' to 'err', since it isn't a length Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:21 -07:00
crypto: drbg - Use HMAC-SHA512 library API Since the HMAC algorithm is now fixed at HMAC-SHA512, just use the HMAC-SHA512 library API. This is simpler and more efficient. Remove error-handling code that is no longer needed. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:06 -07:00
crypto: drbg - SP800-90A Deterministic Random Bit Generator This is a clean-room implementation of the DRBG defined in SP800-90A. All three viable DRBGs defined in the standard are implemented: * HMAC: This is the leanest DRBG and compiled per default * Hash: The more complex DRBG can be enabled at compile time * CTR: The most complex DRBG can also be enabled at compile time The DRBG implementation offers the following: * All three DRBG types are implemented with a derivation function. * All DRBG types are available with and without prediction resistance. * All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available for the HMAC and Hash DRBGs. * All AES types of AES-128, AES-192 and AES-256 are available for the CTR DRBG. * A self test is implemented with drbg_healthcheck(). * The FIPS 140-2 continuous self test is implemented. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-05-31 15:44:17 +02:00
crypto: drbg - Use HMAC-SHA512 library API Since the HMAC algorithm is now fixed at HMAC-SHA512, just use the HMAC-SHA512 library API. This is simpler and more efficient. Remove error-handling code that is no longer needed. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:06 -07:00
crypto: drbg - SP800-90A Deterministic Random Bit Generator This is a clean-room implementation of the DRBG defined in SP800-90A. All three viable DRBGs defined in the standard are implemented: * HMAC: This is the leanest DRBG and compiled per default * Hash: The more complex DRBG can be enabled at compile time * CTR: The most complex DRBG can also be enabled at compile time The DRBG implementation offers the following: * All three DRBG types are implemented with a derivation function. * All DRBG types are available with and without prediction resistance. * All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available for the HMAC and Hash DRBGs. * All AES types of AES-128, AES-192 and AES-256 are available for the CTR DRBG. * A self test is implemented with drbg_healthcheck(). * The FIPS 140-2 continuous self test is implemented. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-05-31 15:44:17 +02:00
crypto: drbg - Clean up generation code A few miscellaneous cleanups to make the code a bit more readable: - Replace (buf, buflen) with (out, outlen) - Update (out, outlen) as we go along - Use size_t for lengths - Use min() - Adjust some comments and log messages - Rename a variable named 'len' to 'err', since it isn't a length Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:21 -07:00
crypto: drbg - SP800-90A Deterministic Random Bit Generator This is a clean-room implementation of the DRBG defined in SP800-90A. All three viable DRBGs defined in the standard are implemented: * HMAC: This is the leanest DRBG and compiled per default * Hash: The more complex DRBG can be enabled at compile time * CTR: The most complex DRBG can also be enabled at compile time The DRBG implementation offers the following: * All three DRBG types are implemented with a derivation function. * All DRBG types are available with and without prediction resistance. * All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available for the HMAC and Hash DRBGs. * All AES types of AES-128, AES-192 and AES-256 are available for the CTR DRBG. * A self test is implemented with drbg_healthcheck(). * The FIPS 140-2 continuous self test is implemented. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-05-31 15:44:17 +02:00
crypto: drbg - Include get_random_bytes() output in additional input Woodage & Shumow (2018) (https://eprint.iacr.org/2018/349.pdf) showed that contrary to the claims made by NIST in SP800-90A, HMAC_DRBG doesn't satisfy the formal definition of forward secrecy (i.e. "backtracking resistance") when it's called with an empty additional input string. The actual attack seems pretty benign, as it doesn't actually give the attacker any previous RNG output, but rather just allows them to test whether their guess of the previous block of RNG output is correct. Regardless, it's an annoying design flaw, and it's yet another example of why NIST's DRBGs aren't all that great. Meanwhile, the kernel's HMAC_DRBG code also tries to reseed itself automatically after random.c has reseeded itself. But the implementation is buggy, as it just checks whether 300 seconds have elapsed, rather than looking at the actual generation counter. Let's just follow the example of BoringSSL and use the conservative approach of always including 32 bytes of "regular" random data in the additional input string. This fixes both issues described above. This does reduce performance. But this should be tolerable, since: - Due to earlier changes, the kernel code that was previously using drbg.c regardless of FIPS mode is now using it only in FIPS mode. - The additional input string is processed only once per request. So if a lot of bytes are generated at once, the cost is amortized. - The NIST DRBGs are notoriously slow anyway. Note that this fix should have no impact (either positive or negative) on FIPS 140 certifiability. From FIPS's point of view the code added by this commit simply doesn't matter: it adds zero entropy to something that doesn't need to contain entropy. Fixes: 541af946fe13 ("crypto: drbg - SP800-90A Deterministic Random Bit Generator") Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:18 -07:00
crypto: drbg - SP800-90A Deterministic Random Bit Generator This is a clean-room implementation of the DRBG defined in SP800-90A. All three viable DRBGs defined in the standard are implemented: * HMAC: This is the leanest DRBG and compiled per default * Hash: The more complex DRBG can be enabled at compile time * CTR: The most complex DRBG can also be enabled at compile time The DRBG implementation offers the following: * All three DRBG types are implemented with a derivation function. * All DRBG types are available with and without prediction resistance. * All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available for the HMAC and Hash DRBGs. * All AES types of AES-128, AES-192 and AES-256 are available for the CTR DRBG. * A self test is implemented with drbg_healthcheck(). * The FIPS 140-2 continuous self test is implemented. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-05-31 15:44:17 +02:00
crypto: drbg - Eliminate use of 'drbg_string' and lists Use straightforward (buffer, len) parameters instead of struct drbg_string or lists of strings. This simplifies the code considerably. For now struct drbg_string is still used in crypto_drbg_ctr_df(), so move its definition to crypto/df_sp80090a.h. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:11 -07:00
crypto: drbg - SP800-90A Deterministic Random Bit Generator This is a clean-room implementation of the DRBG defined in SP800-90A. All three viable DRBGs defined in the standard are implemented: * HMAC: This is the leanest DRBG and compiled per default * Hash: The more complex DRBG can be enabled at compile time * CTR: The most complex DRBG can also be enabled at compile time The DRBG implementation offers the following: * All three DRBG types are implemented with a derivation function. * All DRBG types are available with and without prediction resistance. * All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available for the HMAC and Hash DRBGs. * All AES types of AES-128, AES-192 and AES-256 are available for the CTR DRBG. * A self test is implemented with drbg_healthcheck(). * The FIPS 140-2 continuous self test is implemented. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-05-31 15:44:17 +02:00
crypto: drbg - Eliminate use of 'drbg_string' and lists Use straightforward (buffer, len) parameters instead of struct drbg_string or lists of strings. This simplifies the code considerably. For now struct drbg_string is still used in crypto_drbg_ctr_df(), so move its definition to crypto/df_sp80090a.h. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:11 -07:00
crypto: drbg - SP800-90A Deterministic Random Bit Generator This is a clean-room implementation of the DRBG defined in SP800-90A. All three viable DRBGs defined in the standard are implemented: * HMAC: This is the leanest DRBG and compiled per default * Hash: The more complex DRBG can be enabled at compile time * CTR: The most complex DRBG can also be enabled at compile time The DRBG implementation offers the following: * All three DRBG types are implemented with a derivation function. * All DRBG types are available with and without prediction resistance. * All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available for the HMAC and Hash DRBGs. * All AES types of AES-128, AES-192 and AES-256 are available for the CTR DRBG. * A self test is implemented with drbg_healthcheck(). * The FIPS 140-2 continuous self test is implemented. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-05-31 15:44:17 +02:00
crypto: Enable context analysis Enable context analysis for crypto subsystem. This demonstrates a larger conversion to use Clang's context analysis. The benefit is additional static checking of locking rules, along with better documentation. Note the use of the __acquire_ret macro how to define an API where a function returns a pointer to an object (struct scomp_scratch) with a lock held. Additionally, the analysis only resolves aliases where the analysis unambiguously sees that a variable was not reassigned after initialization, requiring minor code changes. Signed-off-by: Marco Elver <elver@google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20251219154418.3592607-36-elver@google.com
2025-12-19 16:40:24 +01:00
crypto: drbg - SP800-90A Deterministic Random Bit Generator This is a clean-room implementation of the DRBG defined in SP800-90A. All three viable DRBGs defined in the standard are implemented: * HMAC: This is the leanest DRBG and compiled per default * Hash: The more complex DRBG can be enabled at compile time * CTR: The most complex DRBG can also be enabled at compile time The DRBG implementation offers the following: * All three DRBG types are implemented with a derivation function. * All DRBG types are available with and without prediction resistance. * All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available for the HMAC and Hash DRBGs. * All AES types of AES-128, AES-192 and AES-256 are available for the CTR DRBG. * A self test is implemented with drbg_healthcheck(). * The FIPS 140-2 continuous self test is implemented. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-05-31 15:44:17 +02:00
crypto: drbg - Use callback API for random readiness The get_blocking_random_bytes API is broken because the wait can be arbitrarily long (potentially forever) so there is no safe way of calling it from within the kernel. This patch replaces it with the new callback API which does not have this problem. The patch also removes the entropy buffer registered with the DRBG handle in favor of stack variables to hold the seed data. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-06-09 21:55:38 +08:00
crypto: drbg - Eliminate use of 'drbg_string' and lists Use straightforward (buffer, len) parameters instead of struct drbg_string or lists of strings. This simplifies the code considerably. For now struct drbg_string is still used in crypto_drbg_ctr_df(), so move its definition to crypto/df_sp80090a.h. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:11 -07:00
crypto: drbg - SP800-90A Deterministic Random Bit Generator This is a clean-room implementation of the DRBG defined in SP800-90A. All three viable DRBGs defined in the standard are implemented: * HMAC: This is the leanest DRBG and compiled per default * Hash: The more complex DRBG can be enabled at compile time * CTR: The most complex DRBG can also be enabled at compile time The DRBG implementation offers the following: * All three DRBG types are implemented with a derivation function. * All DRBG types are available with and without prediction resistance. * All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available for the HMAC and Hash DRBGs. * All AES types of AES-128, AES-192 and AES-256 are available for the CTR DRBG. * A self test is implemented with drbg_healthcheck(). * The FIPS 140-2 continuous self test is implemented. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-05-31 15:44:17 +02:00
crypto: drbg - Rename MAX_ADDTL => MAX_ADDTL_BYTES Give this constant a name which is clearer and consistent with DRBG_MAX_REQUEST_BYTES. No functional change. Suggested-by: Joachim Vandersmissen <joachim@jvdsn.com> Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-05-05 17:02:17 -07:00
crypto: drbg - Fix format string for debugging statements The initial format strings caused warnings on several architectures. The updated format strings now match the variable types. Reported-by: kbuild test robot <fengguang.wu@intel.com> Reported-by: Randy Dunlap <rdunlap@infradead.org> CC: Joe Perches <joe@perches.com> Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-07-06 02:24:03 +02:00
crypto: drbg - Eliminate use of 'drbg_string' and lists Use straightforward (buffer, len) parameters instead of struct drbg_string or lists of strings. This simplifies the code considerably. For now struct drbg_string is still used in crypto_drbg_ctr_df(), so move its definition to crypto/df_sp80090a.h. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:11 -07:00
crypto: drbg - SP800-90A Deterministic Random Bit Generator This is a clean-room implementation of the DRBG defined in SP800-90A. All three viable DRBGs defined in the standard are implemented: * HMAC: This is the leanest DRBG and compiled per default * Hash: The more complex DRBG can be enabled at compile time * CTR: The most complex DRBG can also be enabled at compile time The DRBG implementation offers the following: * All three DRBG types are implemented with a derivation function. * All DRBG types are available with and without prediction resistance. * All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available for the HMAC and Hash DRBGs. * All AES types of AES-128, AES-192 and AES-256 are available for the CTR DRBG. * A self test is implemented with drbg_healthcheck(). * The FIPS 140-2 continuous self test is implemented. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-05-31 15:44:17 +02:00
crypto: drbg - Eliminate use of 'drbg_string' and lists Use straightforward (buffer, len) parameters instead of struct drbg_string or lists of strings. This simplifies the code considerably. For now struct drbg_string is still used in crypto_drbg_ctr_df(), so move its definition to crypto/df_sp80090a.h. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:11 -07:00
crypto: drbg - SP800-90A Deterministic Random Bit Generator This is a clean-room implementation of the DRBG defined in SP800-90A. All three viable DRBGs defined in the standard are implemented: * HMAC: This is the leanest DRBG and compiled per default * Hash: The more complex DRBG can be enabled at compile time * CTR: The most complex DRBG can also be enabled at compile time The DRBG implementation offers the following: * All three DRBG types are implemented with a derivation function. * All DRBG types are available with and without prediction resistance. * All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available for the HMAC and Hash DRBGs. * All AES types of AES-128, AES-192 and AES-256 are available for the CTR DRBG. * A self test is implemented with drbg_healthcheck(). * The FIPS 140-2 continuous self test is implemented. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-05-31 15:44:17 +02:00
crypto: drbg - Use callback API for random readiness The get_blocking_random_bytes API is broken because the wait can be arbitrarily long (potentially forever) so there is no safe way of calling it from within the kernel. This patch replaces it with the new callback API which does not have this problem. The patch also removes the entropy buffer registered with the DRBG handle in favor of stack variables to hold the seed data. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-06-09 21:55:38 +08:00
crypto: drbg - Eliminate use of 'drbg_string' and lists Use straightforward (buffer, len) parameters instead of struct drbg_string or lists of strings. This simplifies the code considerably. For now struct drbg_string is still used in crypto_drbg_ctr_df(), so move its definition to crypto/df_sp80090a.h. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:11 -07:00
crypto: drbg - Use callback API for random readiness The get_blocking_random_bytes API is broken because the wait can be arbitrarily long (potentially forever) so there is no safe way of calling it from within the kernel. This patch replaces it with the new callback API which does not have this problem. The patch also removes the entropy buffer registered with the DRBG handle in favor of stack variables to hold the seed data. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-06-09 21:55:38 +08:00
crypto: drbg - Move fixed values into constants Since only one drbg_core remains, the state length, block length, and security strength are now fixed values. Moreover, the maximum request length, maximum additional data length, and maximum number of requests were all already fixed values. Simplify the code by just using #defines for all these fixed values. In drbg_seed_from_random(), take advantage of the constant to define the array size. Remove assertions that are no longer useful. In the case of drbg_blocklen() and drbg_statelen(), replace these with a single value DRBG_STATE_LEN, as for HMAC_DRBG they are the same thing. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:04 -07:00
crypto: drbg - Eliminate use of 'drbg_string' and lists Use straightforward (buffer, len) parameters instead of struct drbg_string or lists of strings. This simplifies the code considerably. For now struct drbg_string is still used in crypto_drbg_ctr_df(), so move its definition to crypto/df_sp80090a.h. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:11 -07:00
crypto: drbg - use Jitter RNG to obtain seed During initialization, the DRBG now tries to allocate a handle of the Jitter RNG. If such a Jitter RNG is available during seeding, the DRBG pulls the required entropy/nonce string from get_random_bytes and concatenates it with a string of equal size from the Jitter RNG. That combined string is now the seed for the DRBG. Written differently, the initial seed of the DRBG is now: get_random_bytes(entropy/nonce) || jitterentropy (entropy/nonce) If the Jitter RNG is not available, the DRBG only seeds from get_random_bytes. CC: Andreas Steffen <andreas.steffen@strongswan.org> CC: Theodore Ts'o <tytso@mit.edu> CC: Sandy Harris <sandyinchina@gmail.com> Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-05-25 15:09:59 +02:00
crypto: drbg - Use callback API for random readiness The get_blocking_random_bytes API is broken because the wait can be arbitrarily long (potentially forever) so there is no safe way of calling it from within the kernel. This patch replaces it with the new callback API which does not have this problem. The patch also removes the entropy buffer registered with the DRBG handle in favor of stack variables to hold the seed data. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-06-09 21:55:38 +08:00
crypto: drbg - Eliminate use of 'drbg_string' and lists Use straightforward (buffer, len) parameters instead of struct drbg_string or lists of strings. This simplifies the code considerably. For now struct drbg_string is still used in crypto_drbg_ctr_df(), so move its definition to crypto/df_sp80090a.h. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:11 -07:00
crypto: drbg - Use callback API for random readiness The get_blocking_random_bytes API is broken because the wait can be arbitrarily long (potentially forever) so there is no safe way of calling it from within the kernel. This patch replaces it with the new callback API which does not have this problem. The patch also removes the entropy buffer registered with the DRBG handle in favor of stack variables to hold the seed data. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-06-09 21:55:38 +08:00
crypto: drbg - Eliminate use of 'drbg_string' and lists Use straightforward (buffer, len) parameters instead of struct drbg_string or lists of strings. This simplifies the code considerably. For now struct drbg_string is still used in crypto_drbg_ctr_df(), so move its definition to crypto/df_sp80090a.h. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:11 -07:00
crypto: drbg - Use callback API for random readiness The get_blocking_random_bytes API is broken because the wait can be arbitrarily long (potentially forever) so there is no safe way of calling it from within the kernel. This patch replaces it with the new callback API which does not have this problem. The patch also removes the entropy buffer registered with the DRBG handle in favor of stack variables to hold the seed data. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-06-09 21:55:38 +08:00
crypto: drbg - use Jitter RNG to obtain seed During initialization, the DRBG now tries to allocate a handle of the Jitter RNG. If such a Jitter RNG is available during seeding, the DRBG pulls the required entropy/nonce string from get_random_bytes and concatenates it with a string of equal size from the Jitter RNG. That combined string is now the seed for the DRBG. Written differently, the initial seed of the DRBG is now: get_random_bytes(entropy/nonce) || jitterentropy (entropy/nonce) If the Jitter RNG is not available, the DRBG only seeds from get_random_bytes. CC: Andreas Steffen <andreas.steffen@strongswan.org> CC: Theodore Ts'o <tytso@mit.edu> CC: Sandy Harris <sandyinchina@gmail.com> Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-05-25 15:09:59 +02:00
crypto: drbg - ignore jitterentropy errors if not in FIPS mode A subsequent patch will make the jitterentropy RNG to unconditionally report health test errors back to callers, independent of whether fips_enabled is set or not. The DRBG needs access to a functional jitterentropy instance only in FIPS mode (because it's the only SP800-90B compliant entropy source as it currently stands). Thus, it is perfectly fine for the DRBGs to obtain entropy from the jitterentropy source only on a best effort basis if fips_enabled is off. Make the DRBGs to ignore jitterentropy failures if fips_enabled is not set. Signed-off-by: Nicolai Stange <nstange@suse.de> Reviewed-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2021-11-30 15:10:07 +01:00
crypto: drbg - Use callback API for random readiness The get_blocking_random_bytes API is broken because the wait can be arbitrarily long (potentially forever) so there is no safe way of calling it from within the kernel. This patch replaces it with the new callback API which does not have this problem. The patch also removes the entropy buffer registered with the DRBG handle in favor of stack variables to hold the seed data. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-06-09 21:55:38 +08:00
crypto: drbg - Eliminate use of 'drbg_string' and lists Use straightforward (buffer, len) parameters instead of struct drbg_string or lists of strings. This simplifies the code considerably. For now struct drbg_string is still used in crypto_drbg_ctr_df(), so move its definition to crypto/df_sp80090a.h. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:11 -07:00
crypto: drbg - Use callback API for random readiness The get_blocking_random_bytes API is broken because the wait can be arbitrarily long (potentially forever) so there is no safe way of calling it from within the kernel. This patch replaces it with the new callback API which does not have this problem. The patch also removes the entropy buffer registered with the DRBG handle in favor of stack variables to hold the seed data. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-06-09 21:55:38 +08:00
crypto: drbg - ignore jitterentropy errors if not in FIPS mode A subsequent patch will make the jitterentropy RNG to unconditionally report health test errors back to callers, independent of whether fips_enabled is set or not. The DRBG needs access to a functional jitterentropy instance only in FIPS mode (because it's the only SP800-90B compliant entropy source as it currently stands). Thus, it is perfectly fine for the DRBGs to obtain entropy from the jitterentropy source only on a best effort basis if fips_enabled is off. Make the DRBGs to ignore jitterentropy failures if fips_enabled is not set. Signed-off-by: Nicolai Stange <nstange@suse.de> Reviewed-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2021-11-30 15:10:07 +01:00
crypto: drbg - Use callback API for random readiness The get_blocking_random_bytes API is broken because the wait can be arbitrarily long (potentially forever) so there is no safe way of calling it from within the kernel. This patch replaces it with the new callback API which does not have this problem. The patch also removes the entropy buffer registered with the DRBG handle in favor of stack variables to hold the seed data. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-06-09 21:55:38 +08:00
crypto: drbg - always seeded with SP800-90B compliant noise source As the Jitter RNG provides an SP800-90B compliant noise source, use this noise source always for the (re)seeding of the DRBG. To make sure the DRBG is always properly seeded, the reseed threshold is reduced to 1<<20 generate operations. The Jitter RNG may report health test failures. Such health test failures are treated as transient as follows. The DRBG will not reseed from the Jitter RNG (but from get_random_bytes) in case of a health test failure. Though, it produces the requested random number. The Jitter RNG has a failure counter where at most 1024 consecutive resets due to a health test failure are considered as a transient error. If more consecutive resets are required, the Jitter RNG will return a permanent error which is returned to the caller by the DRBG. With this approach, the worst case reseed threshold is significantly lower than mandated by SP800-90A in order to seed with an SP800-90B noise source: the DRBG has a reseed threshold of 2^20 * 1024 = 2^30 generate requests. Yet, in case of a transient Jitter RNG health test failure, the DRBG is seeded with the data obtained from get_random_bytes. However, if the Jitter RNG fails during the initial seeding operation even due to a health test error, the DRBG will send an error to the caller because at that time, the DRBG has received no seed that is SP800-90B compliant. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-04-17 21:34:03 +02:00
crypto: drbg - Use callback API for random readiness The get_blocking_random_bytes API is broken because the wait can be arbitrarily long (potentially forever) so there is no safe way of calling it from within the kernel. This patch replaces it with the new callback API which does not have this problem. The patch also removes the entropy buffer registered with the DRBG handle in favor of stack variables to hold the seed data. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-06-09 21:55:38 +08:00
crypto: drbg - Eliminate use of 'drbg_string' and lists Use straightforward (buffer, len) parameters instead of struct drbg_string or lists of strings. This simplifies the code considerably. For now struct drbg_string is still used in crypto_drbg_ctr_df(), so move its definition to crypto/df_sp80090a.h. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:11 -07:00
crypto: drbg - use Jitter RNG to obtain seed During initialization, the DRBG now tries to allocate a handle of the Jitter RNG. If such a Jitter RNG is available during seeding, the DRBG pulls the required entropy/nonce string from get_random_bytes and concatenates it with a string of equal size from the Jitter RNG. That combined string is now the seed for the DRBG. Written differently, the initial seed of the DRBG is now: get_random_bytes(entropy/nonce) || jitterentropy (entropy/nonce) If the Jitter RNG is not available, the DRBG only seeds from get_random_bytes. CC: Andreas Steffen <andreas.steffen@strongswan.org> CC: Theodore Ts'o <tytso@mit.edu> CC: Sandy Harris <sandyinchina@gmail.com> Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-05-25 15:09:59 +02:00
crypto: drbg - SP800-90A Deterministic Random Bit Generator This is a clean-room implementation of the DRBG defined in SP800-90A. All three viable DRBGs defined in the standard are implemented: * HMAC: This is the leanest DRBG and compiled per default * Hash: The more complex DRBG can be enabled at compile time * CTR: The most complex DRBG can also be enabled at compile time The DRBG implementation offers the following: * All three DRBG types are implemented with a derivation function. * All DRBG types are available with and without prediction resistance. * All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available for the HMAC and Hash DRBGs. * All AES types of AES-128, AES-192 and AES-256 are available for the CTR DRBG. * A self test is implemented with drbg_healthcheck(). * The FIPS 140-2 continuous self test is implemented. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-05-31 15:44:17 +02:00
crypto: drbg - Eliminate use of 'drbg_string' and lists Use straightforward (buffer, len) parameters instead of struct drbg_string or lists of strings. This simplifies the code considerably. For now struct drbg_string is still used in crypto_drbg_ctr_df(), so move its definition to crypto/df_sp80090a.h. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:11 -07:00
crypto: drbg - SP800-90A Deterministic Random Bit Generator This is a clean-room implementation of the DRBG defined in SP800-90A. All three viable DRBGs defined in the standard are implemented: * HMAC: This is the leanest DRBG and compiled per default * Hash: The more complex DRBG can be enabled at compile time * CTR: The most complex DRBG can also be enabled at compile time The DRBG implementation offers the following: * All three DRBG types are implemented with a derivation function. * All DRBG types are available with and without prediction resistance. * All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available for the HMAC and Hash DRBGs. * All AES types of AES-128, AES-192 and AES-256 are available for the CTR DRBG. * A self test is implemented with drbg_healthcheck(). * The FIPS 140-2 continuous self test is implemented. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-05-31 15:44:17 +02:00
crypto: drbg - Remove redundant reseeding based on random.c state We're now incorporating 32 bytes from get_random_bytes() in the additional input string on every request. The additional input string is processed with a call to drbg_hmac_update(), which is exactly how the seed is processed. Thus, in reality this is as good as a reseed. From the perspective of FIPS 140-3, it isn't as good as a reseed. But it doesn't actually matter, because from FIPS's point of view get_random_bytes() provides zero entropy anyway. Thus, neither the reseed with more get_random_bytes() every 300s, nor the logic that reseeds more frequently before rng_is_initialized(), is actually needed anymore. Remove it to simplify the code significantly. (Technically the use of get_random_bytes() in drbg_seed() itself could be removed too. But it's safer to keep it there for now.) Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:20 -07:00
crypto: drbg - Use HMAC-SHA512 library API Since the HMAC algorithm is now fixed at HMAC-SHA512, just use the HMAC-SHA512 library API. This is simpler and more efficient. Remove error-handling code that is no longer needed. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:06 -07:00
crypto: drbg - add FIPS 140-2 CTRNG for noise source FIPS 140-2 section 4.9.2 requires a continuous self test of the noise source. Up to kernel 4.8 drivers/char/random.c provided this continuous self test. Afterwards it was moved to a location that is inconsistent with the FIPS 140-2 requirements. The relevant patch was e192be9d9a30555aae2ca1dc3aad37cba484cd4a . Thus, the FIPS 140-2 CTRNG is added to the DRBG when it obtains the seed. This patch resurrects the function drbg_fips_continous_test that existed some time ago and applies it to the noise sources. The patch that removed the drbg_fips_continous_test was b3614763059b82c26bdd02ffcb1c016c1132aad0 . The Jitter RNG implements its own FIPS 140-2 self test and thus does not need to be subjected to the test in the DRBG. The patch contains a tiny fix to ensure proper zeroization in case of an error during the Jitter RNG data gathering. Signed-off-by: Stephan Mueller <smueller@chronox.de> Reviewed-by: Yann Droneaud <ydroneaud@opteya.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-05-08 16:19:24 +02:00
crypto: drbg - Eliminate use of 'drbg_string' and lists Use straightforward (buffer, len) parameters instead of struct drbg_string or lists of strings. This simplifies the code considerably. For now struct drbg_string is still used in crypto_drbg_ctr_df(), so move its definition to crypto/df_sp80090a.h. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:11 -07:00
crypto: drbg - SP800-90A Deterministic Random Bit Generator This is a clean-room implementation of the DRBG defined in SP800-90A. All three viable DRBGs defined in the standard are implemented: * HMAC: This is the leanest DRBG and compiled per default * Hash: The more complex DRBG can be enabled at compile time * CTR: The most complex DRBG can also be enabled at compile time The DRBG implementation offers the following: * All three DRBG types are implemented with a derivation function. * All DRBG types are available with and without prediction resistance. * All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available for the HMAC and Hash DRBGs. * All AES types of AES-128, AES-192 and AES-256 are available for the CTR DRBG. * A self test is implemented with drbg_healthcheck(). * The FIPS 140-2 continuous self test is implemented. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-05-31 15:44:17 +02:00
crypto: drbg - Clean up generation code A few miscellaneous cleanups to make the code a bit more readable: - Replace (buf, buflen) with (out, outlen) - Update (out, outlen) as we go along - Use size_t for lengths - Use min() - Adjust some comments and log messages - Rename a variable named 'len' to 'err', since it isn't a length Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:21 -07:00
crypto: drbg - SP800-90A Deterministic Random Bit Generator This is a clean-room implementation of the DRBG defined in SP800-90A. All three viable DRBGs defined in the standard are implemented: * HMAC: This is the leanest DRBG and compiled per default * Hash: The more complex DRBG can be enabled at compile time * CTR: The most complex DRBG can also be enabled at compile time The DRBG implementation offers the following: * All three DRBG types are implemented with a derivation function. * All DRBG types are available with and without prediction resistance. * All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available for the HMAC and Hash DRBGs. * All AES types of AES-128, AES-192 and AES-256 are available for the CTR DRBG. * A self test is implemented with drbg_healthcheck(). * The FIPS 140-2 continuous self test is implemented. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-05-31 15:44:17 +02:00
crypto: drbg - Clean up generation code A few miscellaneous cleanups to make the code a bit more readable: - Replace (buf, buflen) with (out, outlen) - Update (out, outlen) as we go along - Use size_t for lengths - Use min() - Adjust some comments and log messages - Rename a variable named 'len' to 'err', since it isn't a length Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:21 -07:00
crypto: drbg - Eliminate use of 'drbg_string' and lists Use straightforward (buffer, len) parameters instead of struct drbg_string or lists of strings. This simplifies the code considerably. For now struct drbg_string is still used in crypto_drbg_ctr_df(), so move its definition to crypto/df_sp80090a.h. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:11 -07:00
crypto: drbg - SP800-90A Deterministic Random Bit Generator This is a clean-room implementation of the DRBG defined in SP800-90A. All three viable DRBGs defined in the standard are implemented: * HMAC: This is the leanest DRBG and compiled per default * Hash: The more complex DRBG can be enabled at compile time * CTR: The most complex DRBG can also be enabled at compile time The DRBG implementation offers the following: * All three DRBG types are implemented with a derivation function. * All DRBG types are available with and without prediction resistance. * All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available for the HMAC and Hash DRBGs. * All AES types of AES-128, AES-192 and AES-256 are available for the CTR DRBG. * A self test is implemented with drbg_healthcheck(). * The FIPS 140-2 continuous self test is implemented. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-05-31 15:44:17 +02:00
crypto: rng - RNGs must return 0 in success case Change the RNGs to always return 0 in success case. This patch ensures that seqiv.c works with RNGs other than krng. seqiv expects that any return code other than 0 is an error. Without the patch, rfc4106(gcm(aes)) will not work when using a DRBG or an ANSI X9.31 RNG. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-03-06 08:26:31 +01:00
crypto: drbg - SP800-90A Deterministic Random Bit Generator This is a clean-room implementation of the DRBG defined in SP800-90A. All three viable DRBGs defined in the standard are implemented: * HMAC: This is the leanest DRBG and compiled per default * Hash: The more complex DRBG can be enabled at compile time * CTR: The most complex DRBG can also be enabled at compile time The DRBG implementation offers the following: * All three DRBG types are implemented with a derivation function. * All DRBG types are available with and without prediction resistance. * All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available for the HMAC and Hash DRBGs. * All AES types of AES-128, AES-192 and AES-256 are available for the CTR DRBG. * A self test is implemented with drbg_healthcheck(). * The FIPS 140-2 continuous self test is implemented. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-05-31 15:44:17 +02:00
crypto: drbg - Clean up generation code A few miscellaneous cleanups to make the code a bit more readable: - Replace (buf, buflen) with (out, outlen) - Update (out, outlen) as we go along - Use size_t for lengths - Use min() - Adjust some comments and log messages - Rename a variable named 'len' to 'err', since it isn't a length Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:21 -07:00
crypto: drbg - Eliminate use of 'drbg_string' and lists Use straightforward (buffer, len) parameters instead of struct drbg_string or lists of strings. This simplifies the code considerably. For now struct drbg_string is still used in crypto_drbg_ctr_df(), so move its definition to crypto/df_sp80090a.h. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:11 -07:00
crypto: Enable context analysis Enable context analysis for crypto subsystem. This demonstrates a larger conversion to use Clang's context analysis. The benefit is additional static checking of locking rules, along with better documentation. Note the use of the __acquire_ret macro how to define an API where a function returns a pointer to an object (struct scomp_scratch) with a lock held. Additionally, the analysis only resolves aliases where the analysis unambiguously sees that a variable was not reassigned after initialization, requiring minor code changes. Signed-off-by: Marco Elver <elver@google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20251219154418.3592607-36-elver@google.com
2025-12-19 16:40:24 +01:00
crypto: drbg - SP800-90A Deterministic Random Bit Generator This is a clean-room implementation of the DRBG defined in SP800-90A. All three viable DRBGs defined in the standard are implemented: * HMAC: This is the leanest DRBG and compiled per default * Hash: The more complex DRBG can be enabled at compile time * CTR: The most complex DRBG can also be enabled at compile time The DRBG implementation offers the following: * All three DRBG types are implemented with a derivation function. * All DRBG types are available with and without prediction resistance. * All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available for the HMAC and Hash DRBGs. * All AES types of AES-128, AES-192 and AES-256 are available for the CTR DRBG. * A self test is implemented with drbg_healthcheck(). * The FIPS 140-2 continuous self test is implemented. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-05-31 15:44:17 +02:00
crypto: drbg - Clean up generation code A few miscellaneous cleanups to make the code a bit more readable: - Replace (buf, buflen) with (out, outlen) - Update (out, outlen) as we go along - Use size_t for lengths - Use min() - Adjust some comments and log messages - Rename a variable named 'len' to 'err', since it isn't a length Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:21 -07:00
crypto: drbg - SP800-90A Deterministic Random Bit Generator This is a clean-room implementation of the DRBG defined in SP800-90A. All three viable DRBGs defined in the standard are implemented: * HMAC: This is the leanest DRBG and compiled per default * Hash: The more complex DRBG can be enabled at compile time * CTR: The most complex DRBG can also be enabled at compile time The DRBG implementation offers the following: * All three DRBG types are implemented with a derivation function. * All DRBG types are available with and without prediction resistance. * All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available for the HMAC and Hash DRBGs. * All AES types of AES-128, AES-192 and AES-256 are available for the CTR DRBG. * A self test is implemented with drbg_healthcheck(). * The FIPS 140-2 continuous self test is implemented. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-05-31 15:44:17 +02:00
crypto: drbg - Remove drbg_core Now that none of the information in struct drbg_core is used, remove it. The null-ity of the pointer drbg_state::core was used to keep track of whether the DRBG has been instantiated. Replace it with a boolean. No functional change. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:07 -07:00
crypto: drbg - Do not seed RNG in drbg_kcapi_init Initialising the RNG in drbg_kcapi_init is a waste of precious entropy because all users will immediately seed the RNG after the allocation. In fact, all users should seed the RNG before using it. So there is no point in doing the seeding in drbg_kcapi_init. This patch removes the initial seeding and the user must seed the RNG explicitly (as they all currently do). This patch also changes drbg_kcapi_reset to allow reseeding. That is, if you call it after a successful initial seeding, then it will not reset the internal state of the DRBG before mixing the new input and entropy. If you still wish to reset the internal state, you can always free the DRBG and allocate a new one. Finally this patch removes locking from drbg_uninstantiate because it's now only called from the destruction path which must not be executed in parallel with normal operations. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Acked-by: Stephan Mueller <smueller@chronox.de>
2015-04-20 11:29:15 +08:00
crypto: drbg - Clean up generation code A few miscellaneous cleanups to make the code a bit more readable: - Replace (buf, buflen) with (out, outlen) - Update (out, outlen) as we go along - Use size_t for lengths - Use min() - Adjust some comments and log messages - Rename a variable named 'len' to 'err', since it isn't a length Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:21 -07:00
crypto: drbg - SP800-90A Deterministic Random Bit Generator This is a clean-room implementation of the DRBG defined in SP800-90A. All three viable DRBGs defined in the standard are implemented: * HMAC: This is the leanest DRBG and compiled per default * Hash: The more complex DRBG can be enabled at compile time * CTR: The most complex DRBG can also be enabled at compile time The DRBG implementation offers the following: * All three DRBG types are implemented with a derivation function. * All DRBG types are available with and without prediction resistance. * All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available for the HMAC and Hash DRBGs. * All AES types of AES-128, AES-192 and AES-256 are available for the CTR DRBG. * A self test is implemented with drbg_healthcheck(). * The FIPS 140-2 continuous self test is implemented. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-05-31 15:44:17 +02:00
crypto: drbg - Eliminate use of 'drbg_string' and lists Use straightforward (buffer, len) parameters instead of struct drbg_string or lists of strings. This simplifies the code considerably. For now struct drbg_string is still used in crypto_drbg_ctr_df(), so move its definition to crypto/df_sp80090a.h. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:11 -07:00
crypto: drbg - SP800-90A Deterministic Random Bit Generator This is a clean-room implementation of the DRBG defined in SP800-90A. All three viable DRBGs defined in the standard are implemented: * HMAC: This is the leanest DRBG and compiled per default * Hash: The more complex DRBG can be enabled at compile time * CTR: The most complex DRBG can also be enabled at compile time The DRBG implementation offers the following: * All three DRBG types are implemented with a derivation function. * All DRBG types are available with and without prediction resistance. * All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available for the HMAC and Hash DRBGs. * All AES types of AES-128, AES-192 and AES-256 are available for the CTR DRBG. * A self test is implemented with drbg_healthcheck(). * The FIPS 140-2 continuous self test is implemented. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-05-31 15:44:17 +02:00
crypto: drbg - Clean up generation code A few miscellaneous cleanups to make the code a bit more readable: - Replace (buf, buflen) with (out, outlen) - Update (out, outlen) as we go along - Use size_t for lengths - Use min() - Adjust some comments and log messages - Rename a variable named 'len' to 'err', since it isn't a length Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:21 -07:00
crypto: drbg - Move fixed values into constants Since only one drbg_core remains, the state length, block length, and security strength are now fixed values. Moreover, the maximum request length, maximum additional data length, and maximum number of requests were all already fixed values. Simplify the code by just using #defines for all these fixed values. In drbg_seed_from_random(), take advantage of the constant to define the array size. Remove assertions that are no longer useful. In the case of drbg_blocklen() and drbg_statelen(), replace these with a single value DRBG_STATE_LEN, as for HMAC_DRBG they are the same thing. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:04 -07:00
crypto: drbg - SP800-90A Deterministic Random Bit Generator This is a clean-room implementation of the DRBG defined in SP800-90A. All three viable DRBGs defined in the standard are implemented: * HMAC: This is the leanest DRBG and compiled per default * Hash: The more complex DRBG can be enabled at compile time * CTR: The most complex DRBG can also be enabled at compile time The DRBG implementation offers the following: * All three DRBG types are implemented with a derivation function. * All DRBG types are available with and without prediction resistance. * All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available for the HMAC and Hash DRBGs. * All AES types of AES-128, AES-192 and AES-256 are available for the CTR DRBG. * A self test is implemented with drbg_healthcheck(). * The FIPS 140-2 continuous self test is implemented. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-05-31 15:44:17 +02:00
crypto: drbg - Rename MAX_ADDTL => MAX_ADDTL_BYTES Give this constant a name which is clearer and consistent with DRBG_MAX_REQUEST_BYTES. No functional change. Suggested-by: Joachim Vandersmissen <joachim@jvdsn.com> Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-05-05 17:02:17 -07:00
crypto: drbg - SP800-90A Deterministic Random Bit Generator This is a clean-room implementation of the DRBG defined in SP800-90A. All three viable DRBGs defined in the standard are implemented: * HMAC: This is the leanest DRBG and compiled per default * Hash: The more complex DRBG can be enabled at compile time * CTR: The most complex DRBG can also be enabled at compile time The DRBG implementation offers the following: * All three DRBG types are implemented with a derivation function. * All DRBG types are available with and without prediction resistance. * All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available for the HMAC and Hash DRBGs. * All AES types of AES-128, AES-192 and AES-256 are available for the CTR DRBG. * A self test is implemented with drbg_healthcheck(). * The FIPS 140-2 continuous self test is implemented. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-05-31 15:44:17 +02:00
crypto: drbg - Eliminate use of 'drbg_string' and lists Use straightforward (buffer, len) parameters instead of struct drbg_string or lists of strings. This simplifies the code considerably. For now struct drbg_string is still used in crypto_drbg_ctr_df(), so move its definition to crypto/df_sp80090a.h. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:11 -07:00
crypto: drbg - Move fixed values into constants Since only one drbg_core remains, the state length, block length, and security strength are now fixed values. Moreover, the maximum request length, maximum additional data length, and maximum number of requests were all already fixed values. Simplify the code by just using #defines for all these fixed values. In drbg_seed_from_random(), take advantage of the constant to define the array size. Remove assertions that are no longer useful. In the case of drbg_blocklen() and drbg_statelen(), replace these with a single value DRBG_STATE_LEN, as for HMAC_DRBG they are the same thing. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:04 -07:00
crypto: drbg - SP800-90A Deterministic Random Bit Generator This is a clean-room implementation of the DRBG defined in SP800-90A. All three viable DRBGs defined in the standard are implemented: * HMAC: This is the leanest DRBG and compiled per default * Hash: The more complex DRBG can be enabled at compile time * CTR: The most complex DRBG can also be enabled at compile time The DRBG implementation offers the following: * All three DRBG types are implemented with a derivation function. * All DRBG types are available with and without prediction resistance. * All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available for the HMAC and Hash DRBGs. * All AES types of AES-128, AES-192 and AES-256 are available for the CTR DRBG. * A self test is implemented with drbg_healthcheck(). * The FIPS 140-2 continuous self test is implemented. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-05-31 15:44:17 +02:00
crypto: drbg - Remove redundant reseeding based on random.c state We're now incorporating 32 bytes from get_random_bytes() in the additional input string on every request. The additional input string is processed with a call to drbg_hmac_update(), which is exactly how the seed is processed. Thus, in reality this is as good as a reseed. From the perspective of FIPS 140-3, it isn't as good as a reseed. But it doesn't actually matter, because from FIPS's point of view get_random_bytes() provides zero entropy anyway. Thus, neither the reseed with more get_random_bytes() every 300s, nor the logic that reseeds more frequently before rng_is_initialized(), is actually needed anymore. Remove it to simplify the code significantly. (Technically the use of get_random_bytes() in drbg_seed() itself could be removed too. But it's safer to keep it there for now.) Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:20 -07:00
crypto: drbg - SP800-90A Deterministic Random Bit Generator This is a clean-room implementation of the DRBG defined in SP800-90A. All three viable DRBGs defined in the standard are implemented: * HMAC: This is the leanest DRBG and compiled per default * Hash: The more complex DRBG can be enabled at compile time * CTR: The most complex DRBG can also be enabled at compile time The DRBG implementation offers the following: * All three DRBG types are implemented with a derivation function. * All DRBG types are available with and without prediction resistance. * All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available for the HMAC and Hash DRBGs. * All AES types of AES-128, AES-192 and AES-256 are available for the CTR DRBG. * A self test is implemented with drbg_healthcheck(). * The FIPS 140-2 continuous self test is implemented. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-05-31 15:44:17 +02:00
crypto: drbg - Remove support for "prediction resistance" "Prediction resistance", i.e. the property that the RNG's output is unpredictable even after a state compromise, might sound like a nice property to have. In reality, it's not very practical, as it requires that fresh entropy be pulled on every request. (The normal Linux RNG doesn't provide prediction resistance.) In the case of drbg.c, that means pulling from "jitterentropy", which is extremely slow. For some perspective, running a simple benchmark, generating 32 random bytes takes the following amount of time: get_random_bytes(): 90 ns drbg_nopr_hmac_sha512: 3707 ns drbg_pr_hmac_sha512: 773082 ns So at least in this case, the "pr" (prediction-resistant) DRBG is over 200 times slower than the "nopr" (non-prediction-resistant) DRBG, or over 8000 times slower than the normal Linux RNG. While anyone using drbg.c has always had to tolerate that it's slower than the normal Linux RNG, the "pr" DRBG is clearly at another level of slowness. Thus, the following is also entirely unsurprising: - FIPS 140-3 doesn't actually require that SP800-90A DRBG implementations support prediction resistance. The non-prediction resistant DRBGs can be, and have been, certified. - drbg.c registers "drbg_nopr_hmac_sha512" with a higher cra_priority than "drbg_pr_hmac_sha512". So "drbg_nopr_hmac_sha512" is already the one actually being used in practice. Given these considerations, it's clear that "drbg_pr_hmac_sha512" isn't actually useful, and it essentially just existed as another curiosity in the museum of crypto algorithms. Remove it to simplify the code. Suggested-by: Joachim Vandersmissen <joachim@jvdsn.com> Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-05-05 17:02:58 -07:00
crypto: drbg - SP800-90A Deterministic Random Bit Generator This is a clean-room implementation of the DRBG defined in SP800-90A. All three viable DRBGs defined in the standard are implemented: * HMAC: This is the leanest DRBG and compiled per default * Hash: The more complex DRBG can be enabled at compile time * CTR: The most complex DRBG can also be enabled at compile time The DRBG implementation offers the following: * All three DRBG types are implemented with a derivation function. * All DRBG types are available with and without prediction resistance. * All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available for the HMAC and Hash DRBGs. * All AES types of AES-128, AES-192 and AES-256 are available for the CTR DRBG. * A self test is implemented with drbg_healthcheck(). * The FIPS 140-2 continuous self test is implemented. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-05-31 15:44:17 +02:00
crypto: drbg - Clean up generation code A few miscellaneous cleanups to make the code a bit more readable: - Replace (buf, buflen) with (out, outlen) - Update (out, outlen) as we go along - Use size_t for lengths - Use min() - Adjust some comments and log messages - Rename a variable named 'len' to 'err', since it isn't a length Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:21 -07:00
crypto: drbg - SP800-90A Deterministic Random Bit Generator This is a clean-room implementation of the DRBG defined in SP800-90A. All three viable DRBGs defined in the standard are implemented: * HMAC: This is the leanest DRBG and compiled per default * Hash: The more complex DRBG can be enabled at compile time * CTR: The most complex DRBG can also be enabled at compile time The DRBG implementation offers the following: * All three DRBG types are implemented with a derivation function. * All DRBG types are available with and without prediction resistance. * All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available for the HMAC and Hash DRBGs. * All AES types of AES-128, AES-192 and AES-256 are available for the CTR DRBG. * A self test is implemented with drbg_healthcheck(). * The FIPS 140-2 continuous self test is implemented. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-05-31 15:44:17 +02:00
crypto: drbg - Eliminate use of 'drbg_string' and lists Use straightforward (buffer, len) parameters instead of struct drbg_string or lists of strings. This simplifies the code considerably. For now struct drbg_string is still used in crypto_drbg_ctr_df(), so move its definition to crypto/df_sp80090a.h. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:11 -07:00
crypto: drbg - SP800-90A Deterministic Random Bit Generator This is a clean-room implementation of the DRBG defined in SP800-90A. All three viable DRBGs defined in the standard are implemented: * HMAC: This is the leanest DRBG and compiled per default * Hash: The more complex DRBG can be enabled at compile time * CTR: The most complex DRBG can also be enabled at compile time The DRBG implementation offers the following: * All three DRBG types are implemented with a derivation function. * All DRBG types are available with and without prediction resistance. * All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available for the HMAC and Hash DRBGs. * All AES types of AES-128, AES-192 and AES-256 are available for the CTR DRBG. * A self test is implemented with drbg_healthcheck(). * The FIPS 140-2 continuous self test is implemented. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-05-31 15:44:17 +02:00
crypto: drbg - Mix a time stamp into DRBG state The current locking approach of the DRBG tries to keep the protected code paths very minimal. It is therefore possible that two threads query one DRBG instance at the same time. When thread A requests random numbers, a shadow copy of the DRBG state is created upon which the request for A is processed. After finishing the state for A's request is merged back into the DRBG state. If now thread B requests random numbers from the same DRBG after the request for thread A is received, but before A's shadow state is merged back, the random numbers for B will be identical to the ones for A. Please note that the time window is very small for this scenario. To prevent that there is even a theoretical chance for thread A and B having the same DRBG state, the current time stamp is provided as additional information string for each new request. The addition of the time stamp as additional information string implies that now all generate functions must be capable to process a linked list with additional information strings instead of a scalar. CC: Rafael Aquini <aquini@redhat.com> Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-07-06 02:25:36 +02:00
crypto: drbg - SP800-90A Deterministic Random Bit Generator This is a clean-room implementation of the DRBG defined in SP800-90A. All three viable DRBGs defined in the standard are implemented: * HMAC: This is the leanest DRBG and compiled per default * Hash: The more complex DRBG can be enabled at compile time * CTR: The most complex DRBG can also be enabled at compile time The DRBG implementation offers the following: * All three DRBG types are implemented with a derivation function. * All DRBG types are available with and without prediction resistance. * All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available for the HMAC and Hash DRBGs. * All AES types of AES-128, AES-192 and AES-256 are available for the CTR DRBG. * A self test is implemented with drbg_healthcheck(). * The FIPS 140-2 continuous self test is implemented. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-05-31 15:44:17 +02:00
crypto: drbg - Clean up generation code A few miscellaneous cleanups to make the code a bit more readable: - Replace (buf, buflen) with (out, outlen) - Update (out, outlen) as we go along - Use size_t for lengths - Use min() - Adjust some comments and log messages - Rename a variable named 'len' to 'err', since it isn't a length Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:21 -07:00
crypto: drbg - SP800-90A Deterministic Random Bit Generator This is a clean-room implementation of the DRBG defined in SP800-90A. All three viable DRBGs defined in the standard are implemented: * HMAC: This is the leanest DRBG and compiled per default * Hash: The more complex DRBG can be enabled at compile time * CTR: The most complex DRBG can also be enabled at compile time The DRBG implementation offers the following: * All three DRBG types are implemented with a derivation function. * All DRBG types are available with and without prediction resistance. * All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available for the HMAC and Hash DRBGs. * All AES types of AES-128, AES-192 and AES-256 are available for the CTR DRBG. * A self test is implemented with drbg_healthcheck(). * The FIPS 140-2 continuous self test is implemented. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-05-31 15:44:17 +02:00
crypto: drbg - Remove support for HASH_DRBG Remove the support for HASH_DRBG. It's likely unused code, seeing as HMAC_DRBG is always enabled and prioritized over it unless NETLINK_CRYPTO is used to change the algorithm priorities. There's also no compelling reason to support more than one of [HMAC_DRBG, HASH_DRBG, CTR_DRBG]. By definition, callers cannot tell any difference in their outputs. And all are FIPS-certifiable, which is the only point of the kernel's NIST DRBGs anyway. Switching to HASH_DRBG doesn't seem all that compelling, either. For one, it's more complex than HMAC_DRBG. Thus, let's just drop HASH_DRBG support and focus on HMAC_DRBG. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> # m68k Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:33:57 -07:00
crypto: drbg - replace spinlock with mutex The creation of a shadow copy is intended to only hold a short term lock. But the drawback is that parallel users have a very similar DRBG state which only differs by a high-resolution time stamp. The DRBG will now hold a long term lock. Therefore, the lock is changed to a mutex which implies that the DRBG can only be used in process context. The lock now guards the instantiation as well as the entire DRBG generation operation. Therefore, multiple callers are fully serialized when generating a random number. As the locking is changed to use a long-term lock to avoid such similar DRBG states, the entire creation and maintenance of a shadow copy can be removed. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-04-18 19:36:17 +02:00
crypto: drbg - SP800-90A Deterministic Random Bit Generator This is a clean-room implementation of the DRBG defined in SP800-90A. All three viable DRBGs defined in the standard are implemented: * HMAC: This is the leanest DRBG and compiled per default * Hash: The more complex DRBG can be enabled at compile time * CTR: The most complex DRBG can also be enabled at compile time The DRBG implementation offers the following: * All three DRBG types are implemented with a derivation function. * All DRBG types are available with and without prediction resistance. * All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available for the HMAC and Hash DRBGs. * All AES types of AES-128, AES-192 and AES-256 are available for the CTR DRBG. * A self test is implemented with drbg_healthcheck(). * The FIPS 140-2 continuous self test is implemented. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-05-31 15:44:17 +02:00
crypto: drbg - Clean up generation code A few miscellaneous cleanups to make the code a bit more readable: - Replace (buf, buflen) with (out, outlen) - Update (out, outlen) as we go along - Use size_t for lengths - Use min() - Adjust some comments and log messages - Rename a variable named 'len' to 'err', since it isn't a length Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:21 -07:00
crypto: drbg - SP800-90A Deterministic Random Bit Generator This is a clean-room implementation of the DRBG defined in SP800-90A. All three viable DRBGs defined in the standard are implemented: * HMAC: This is the leanest DRBG and compiled per default * Hash: The more complex DRBG can be enabled at compile time * CTR: The most complex DRBG can also be enabled at compile time The DRBG implementation offers the following: * All three DRBG types are implemented with a derivation function. * All DRBG types are available with and without prediction resistance. * All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available for the HMAC and Hash DRBGs. * All AES types of AES-128, AES-192 and AES-256 are available for the CTR DRBG. * A self test is implemented with drbg_healthcheck(). * The FIPS 140-2 continuous self test is implemented. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-05-31 15:44:17 +02:00
crypto: drbg - Put rng_alg methods in logical order Put the DRBG implementation of the rng_alg methods in the order in which they're called (cra_init => set_ent => seed => generate => cra_exit) so that it's easier to understand the flow. Also rename drbg_kcapi_random to drbg_kcapi_generate, and drbg_kcapi_cleanup to drbg_kcapi_exit, so they match the method names. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:13 -07:00
crypto: drbg - SP800-90A Deterministic Random Bit Generator This is a clean-room implementation of the DRBG defined in SP800-90A. All three viable DRBGs defined in the standard are implemented: * HMAC: This is the leanest DRBG and compiled per default * Hash: The more complex DRBG can be enabled at compile time * CTR: The most complex DRBG can also be enabled at compile time The DRBG implementation offers the following: * All three DRBG types are implemented with a derivation function. * All DRBG types are available with and without prediction resistance. * All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available for the HMAC and Hash DRBGs. * All AES types of AES-128, AES-192 and AES-256 are available for the CTR DRBG. * A self test is implemented with drbg_healthcheck(). * The FIPS 140-2 continuous self test is implemented. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-05-31 15:44:17 +02:00
crypto: drbg - replace spinlock with mutex The creation of a shadow copy is intended to only hold a short term lock. But the drawback is that parallel users have a very similar DRBG state which only differs by a high-resolution time stamp. The DRBG will now hold a long term lock. Therefore, the lock is changed to a mutex which implies that the DRBG can only be used in process context. The lock now guards the instantiation as well as the entire DRBG generation operation. Therefore, multiple callers are fully serialized when generating a random number. As the locking is changed to use a long-term lock to avoid such similar DRBG states, the entire creation and maintenance of a shadow copy can be removed. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-04-18 19:36:17 +02:00
crypto: drbg - Do not seed RNG in drbg_kcapi_init Initialising the RNG in drbg_kcapi_init is a waste of precious entropy because all users will immediately seed the RNG after the allocation. In fact, all users should seed the RNG before using it. So there is no point in doing the seeding in drbg_kcapi_init. This patch removes the initial seeding and the user must seed the RNG explicitly (as they all currently do). This patch also changes drbg_kcapi_reset to allow reseeding. That is, if you call it after a successful initial seeding, then it will not reset the internal state of the DRBG before mixing the new input and entropy. If you still wish to reset the internal state, you can always free the DRBG and allocate a new one. Finally this patch removes locking from drbg_uninstantiate because it's now only called from the destruction path which must not be executed in parallel with normal operations. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Acked-by: Stephan Mueller <smueller@chronox.de>
2015-04-20 11:29:15 +08:00
crypto: drbg - SP800-90A Deterministic Random Bit Generator This is a clean-room implementation of the DRBG defined in SP800-90A. All three viable DRBGs defined in the standard are implemented: * HMAC: This is the leanest DRBG and compiled per default * Hash: The more complex DRBG can be enabled at compile time * CTR: The most complex DRBG can also be enabled at compile time The DRBG implementation offers the following: * All three DRBG types are implemented with a derivation function. * All DRBG types are available with and without prediction resistance. * All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available for the HMAC and Hash DRBGs. * All AES types of AES-128, AES-192 and AES-256 are available for the CTR DRBG. * A self test is implemented with drbg_healthcheck(). * The FIPS 140-2 continuous self test is implemented. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-05-31 15:44:17 +02:00
crypto: drbg - Put rng_alg methods in logical order Put the DRBG implementation of the rng_alg methods in the order in which they're called (cra_init => set_ent => seed => generate => cra_exit) so that it's easier to understand the flow. Also rename drbg_kcapi_random to drbg_kcapi_generate, and drbg_kcapi_cleanup to drbg_kcapi_exit, so they match the method names. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:13 -07:00
crypto: drbg - SP800-90A Deterministic Random Bit Generator This is a clean-room implementation of the DRBG defined in SP800-90A. All three viable DRBGs defined in the standard are implemented: * HMAC: This is the leanest DRBG and compiled per default * Hash: The more complex DRBG can be enabled at compile time * CTR: The most complex DRBG can also be enabled at compile time The DRBG implementation offers the following: * All three DRBG types are implemented with a derivation function. * All DRBG types are available with and without prediction resistance. * All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available for the HMAC and Hash DRBGs. * All AES types of AES-128, AES-192 and AES-256 are available for the CTR DRBG. * A self test is implemented with drbg_healthcheck(). * The FIPS 140-2 continuous self test is implemented. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-05-31 15:44:17 +02:00
crypto: drbg - Convert to new rng interface This patch converts the DRBG implementation to the new low-level rng interface. This allows us to get rid of struct drbg_gen by using the new RNG API instead. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Acked-by: Stephan Mueller <smueller@chronox.de>
2015-04-21 10:46:41 +08:00
crypto: drbg - Put rng_alg methods in logical order Put the DRBG implementation of the rng_alg methods in the order in which they're called (cra_init => set_ent => seed => generate => cra_exit) so that it's easier to understand the flow. Also rename drbg_kcapi_random to drbg_kcapi_generate, and drbg_kcapi_cleanup to drbg_kcapi_exit, so they match the method names. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:13 -07:00
crypto: drbg - SP800-90A Deterministic Random Bit Generator This is a clean-room implementation of the DRBG defined in SP800-90A. All three viable DRBGs defined in the standard are implemented: * HMAC: This is the leanest DRBG and compiled per default * Hash: The more complex DRBG can be enabled at compile time * CTR: The most complex DRBG can also be enabled at compile time The DRBG implementation offers the following: * All three DRBG types are implemented with a derivation function. * All DRBG types are available with and without prediction resistance. * All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available for the HMAC and Hash DRBGs. * All AES types of AES-128, AES-192 and AES-256 are available for the CTR DRBG. * A self test is implemented with drbg_healthcheck(). * The FIPS 140-2 continuous self test is implemented. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-05-31 15:44:17 +02:00
crypto: drbg - Install separate seed functions for pr and nopr Set rng_alg::seed to different functions for the prediction-resistant and non-prediction-resistant algorithms, so that the function does not need to parse the algorithm name to figure out which algorithm it is. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:08 -07:00
crypto: drbg - Convert to new rng interface This patch converts the DRBG implementation to the new low-level rng interface. This allows us to get rid of struct drbg_gen by using the new RNG API instead. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Acked-by: Stephan Mueller <smueller@chronox.de>
2015-04-21 10:46:41 +08:00
crypto: drbg - Remove support for "prediction resistance" "Prediction resistance", i.e. the property that the RNG's output is unpredictable even after a state compromise, might sound like a nice property to have. In reality, it's not very practical, as it requires that fresh entropy be pulled on every request. (The normal Linux RNG doesn't provide prediction resistance.) In the case of drbg.c, that means pulling from "jitterentropy", which is extremely slow. For some perspective, running a simple benchmark, generating 32 random bytes takes the following amount of time: get_random_bytes(): 90 ns drbg_nopr_hmac_sha512: 3707 ns drbg_pr_hmac_sha512: 773082 ns So at least in this case, the "pr" (prediction-resistant) DRBG is over 200 times slower than the "nopr" (non-prediction-resistant) DRBG, or over 8000 times slower than the normal Linux RNG. While anyone using drbg.c has always had to tolerate that it's slower than the normal Linux RNG, the "pr" DRBG is clearly at another level of slowness. Thus, the following is also entirely unsurprising: - FIPS 140-3 doesn't actually require that SP800-90A DRBG implementations support prediction resistance. The non-prediction resistant DRBGs can be, and have been, certified. - drbg.c registers "drbg_nopr_hmac_sha512" with a higher cra_priority than "drbg_pr_hmac_sha512". So "drbg_nopr_hmac_sha512" is already the one actually being used in practice. Given these considerations, it's clear that "drbg_pr_hmac_sha512" isn't actually useful, and it essentially just existed as another curiosity in the museum of crypto algorithms. Remove it to simplify the code. Suggested-by: Joachim Vandersmissen <joachim@jvdsn.com> Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-05-05 17:02:58 -07:00
crypto: drbg - SP800-90A Deterministic Random Bit Generator This is a clean-room implementation of the DRBG defined in SP800-90A. All three viable DRBGs defined in the standard are implemented: * HMAC: This is the leanest DRBG and compiled per default * Hash: The more complex DRBG can be enabled at compile time * CTR: The most complex DRBG can also be enabled at compile time The DRBG implementation offers the following: * All three DRBG types are implemented with a derivation function. * All DRBG types are available with and without prediction resistance. * All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available for the HMAC and Hash DRBGs. * All AES types of AES-128, AES-192 and AES-256 are available for the CTR DRBG. * A self test is implemented with drbg_healthcheck(). * The FIPS 140-2 continuous self test is implemented. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-05-31 15:44:17 +02:00
crypto: drbg - Fold drbg_instantiate() into drbg_kcapi_seed() Fold drbg_instantiate() into its only caller. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:14 -07:00
crypto: drbg - SP800-90A Deterministic Random Bit Generator This is a clean-room implementation of the DRBG defined in SP800-90A. All three viable DRBGs defined in the standard are implemented: * HMAC: This is the leanest DRBG and compiled per default * Hash: The more complex DRBG can be enabled at compile time * CTR: The most complex DRBG can also be enabled at compile time The DRBG implementation offers the following: * All three DRBG types are implemented with a derivation function. * All DRBG types are available with and without prediction resistance. * All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available for the HMAC and Hash DRBGs. * All AES types of AES-128, AES-192 and AES-256 are available for the CTR DRBG. * A self test is implemented with drbg_healthcheck(). * The FIPS 140-2 continuous self test is implemented. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-05-31 15:44:17 +02:00
crypto: drbg - Fold drbg_instantiate() into drbg_kcapi_seed() Fold drbg_instantiate() into its only caller. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:14 -07:00
crypto: drbg - SP800-90A Deterministic Random Bit Generator This is a clean-room implementation of the DRBG defined in SP800-90A. All three viable DRBGs defined in the standard are implemented: * HMAC: This is the leanest DRBG and compiled per default * Hash: The more complex DRBG can be enabled at compile time * CTR: The most complex DRBG can also be enabled at compile time The DRBG implementation offers the following: * All three DRBG types are implemented with a derivation function. * All DRBG types are available with and without prediction resistance. * All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available for the HMAC and Hash DRBGs. * All AES types of AES-128, AES-192 and AES-256 are available for the CTR DRBG. * A self test is implemented with drbg_healthcheck(). * The FIPS 140-2 continuous self test is implemented. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-05-31 15:44:17 +02:00
crypto: drbg - Remove support for "prediction resistance" "Prediction resistance", i.e. the property that the RNG's output is unpredictable even after a state compromise, might sound like a nice property to have. In reality, it's not very practical, as it requires that fresh entropy be pulled on every request. (The normal Linux RNG doesn't provide prediction resistance.) In the case of drbg.c, that means pulling from "jitterentropy", which is extremely slow. For some perspective, running a simple benchmark, generating 32 random bytes takes the following amount of time: get_random_bytes(): 90 ns drbg_nopr_hmac_sha512: 3707 ns drbg_pr_hmac_sha512: 773082 ns So at least in this case, the "pr" (prediction-resistant) DRBG is over 200 times slower than the "nopr" (non-prediction-resistant) DRBG, or over 8000 times slower than the normal Linux RNG. While anyone using drbg.c has always had to tolerate that it's slower than the normal Linux RNG, the "pr" DRBG is clearly at another level of slowness. Thus, the following is also entirely unsurprising: - FIPS 140-3 doesn't actually require that SP800-90A DRBG implementations support prediction resistance. The non-prediction resistant DRBGs can be, and have been, certified. - drbg.c registers "drbg_nopr_hmac_sha512" with a higher cra_priority than "drbg_pr_hmac_sha512". So "drbg_nopr_hmac_sha512" is already the one actually being used in practice. Given these considerations, it's clear that "drbg_pr_hmac_sha512" isn't actually useful, and it essentially just existed as another curiosity in the museum of crypto algorithms. Remove it to simplify the code. Suggested-by: Joachim Vandersmissen <joachim@jvdsn.com> Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-05-05 17:02:58 -07:00
crypto: drbg - Separate "reseed" case in drbg_kcapi_seed() Clearly separate the code for the "reseed" and "instantiate" cases, since what they need to do is quite different. Note that the mutex guard makes the mutex start being held during the call to drbg_uninstantiate(), which is fine. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:15 -07:00
crypto: drbg - Fold drbg_instantiate() into drbg_kcapi_seed() Fold drbg_instantiate() into its only caller. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:14 -07:00
crypto: drbg - Remove support for "prediction resistance" "Prediction resistance", i.e. the property that the RNG's output is unpredictable even after a state compromise, might sound like a nice property to have. In reality, it's not very practical, as it requires that fresh entropy be pulled on every request. (The normal Linux RNG doesn't provide prediction resistance.) In the case of drbg.c, that means pulling from "jitterentropy", which is extremely slow. For some perspective, running a simple benchmark, generating 32 random bytes takes the following amount of time: get_random_bytes(): 90 ns drbg_nopr_hmac_sha512: 3707 ns drbg_pr_hmac_sha512: 773082 ns So at least in this case, the "pr" (prediction-resistant) DRBG is over 200 times slower than the "nopr" (non-prediction-resistant) DRBG, or over 8000 times slower than the normal Linux RNG. While anyone using drbg.c has always had to tolerate that it's slower than the normal Linux RNG, the "pr" DRBG is clearly at another level of slowness. Thus, the following is also entirely unsurprising: - FIPS 140-3 doesn't actually require that SP800-90A DRBG implementations support prediction resistance. The non-prediction resistant DRBGs can be, and have been, certified. - drbg.c registers "drbg_nopr_hmac_sha512" with a higher cra_priority than "drbg_pr_hmac_sha512". So "drbg_nopr_hmac_sha512" is already the one actually being used in practice. Given these considerations, it's clear that "drbg_pr_hmac_sha512" isn't actually useful, and it essentially just existed as another curiosity in the museum of crypto algorithms. Remove it to simplify the code. Suggested-by: Joachim Vandersmissen <joachim@jvdsn.com> Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-05-05 17:02:58 -07:00
crypto: drbg - Fold drbg_instantiate() into drbg_kcapi_seed() Fold drbg_instantiate() into its only caller. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:14 -07:00
crypto: drbg - Separate "reseed" case in drbg_kcapi_seed() Clearly separate the code for the "reseed" and "instantiate" cases, since what they need to do is quite different. Note that the mutex guard makes the mutex start being held during the call to drbg_uninstantiate(), which is fine. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:15 -07:00
crypto: drbg - Fold drbg_instantiate() into drbg_kcapi_seed() Fold drbg_instantiate() into its only caller. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:14 -07:00
crypto: drbg - Fold drbg_prepare_hrng() into drbg_kcapi_seed() Fold drbg_prepare_hrng() into its only caller. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:16 -07:00
crypto: drbg - Simplify "uninstantiate" logic drbg_kcapi_seed() calls drbg_uninstantiate() only to free drbg->jent and set drbg->instantiated = false. However, the latter is necessary only because drbg_kcapi_seed() sets drbg->instantiated = true too early. Fix that, then just inline the freeing of drbg->jent. Then, simplify the actual "uninstantiate" in drbg_kcapi_exit(). Just free drbg->jent (note that this is a no-op on error and null pointers), then memzero_explicit() the entire drbg_state. Note that in reality the memzero_explicit() is redundant, since the crypto_rng API zeroizes the memory anyway. But the way SP800-90A is worded, it's easy to imagine that someone assessing conformance with it would be looking for code in drbg.c that says it does an "Uninstantiate" and does the zeroization. So it's probably worth keeping it somewhat explicit, even though that means double zeroization in practice. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:17 -07:00
crypto: drbg - Fold drbg_prepare_hrng() into drbg_kcapi_seed() Fold drbg_prepare_hrng() into its only caller. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:16 -07:00
crypto: drbg - Separate "reseed" case in drbg_kcapi_seed() Clearly separate the code for the "reseed" and "instantiate" cases, since what they need to do is quite different. Note that the mutex guard makes the mutex start being held during the call to drbg_uninstantiate(), which is fine. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:15 -07:00
crypto: drbg - Simplify "uninstantiate" logic drbg_kcapi_seed() calls drbg_uninstantiate() only to free drbg->jent and set drbg->instantiated = false. However, the latter is necessary only because drbg_kcapi_seed() sets drbg->instantiated = true too early. Fix that, then just inline the freeing of drbg->jent. Then, simplify the actual "uninstantiate" in drbg_kcapi_exit(). Just free drbg->jent (note that this is a no-op on error and null pointers), then memzero_explicit() the entire drbg_state. Note that in reality the memzero_explicit() is redundant, since the crypto_rng API zeroizes the memory anyway. But the way SP800-90A is worded, it's easy to imagine that someone assessing conformance with it would be looking for code in drbg.c that says it does an "Uninstantiate" and does the zeroization. So it's probably worth keeping it somewhat explicit, even though that means double zeroization in practice. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:17 -07:00
crypto: drbg - SP800-90A Deterministic Random Bit Generator This is a clean-room implementation of the DRBG defined in SP800-90A. All three viable DRBGs defined in the standard are implemented: * HMAC: This is the leanest DRBG and compiled per default * Hash: The more complex DRBG can be enabled at compile time * CTR: The most complex DRBG can also be enabled at compile time The DRBG implementation offers the following: * All three DRBG types are implemented with a derivation function. * All DRBG types are available with and without prediction resistance. * All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available for the HMAC and Hash DRBGs. * All AES types of AES-128, AES-192 and AES-256 are available for the CTR DRBG. * A self test is implemented with drbg_healthcheck(). * The FIPS 140-2 continuous self test is implemented. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-05-31 15:44:17 +02:00
crypto: drbg - Put rng_alg methods in logical order Put the DRBG implementation of the rng_alg methods in the order in which they're called (cra_init => set_ent => seed => generate => cra_exit) so that it's easier to understand the flow. Also rename drbg_kcapi_random to drbg_kcapi_generate, and drbg_kcapi_cleanup to drbg_kcapi_exit, so they match the method names. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:13 -07:00
crypto: drbg - Simplify "uninstantiate" logic drbg_kcapi_seed() calls drbg_uninstantiate() only to free drbg->jent and set drbg->instantiated = false. However, the latter is necessary only because drbg_kcapi_seed() sets drbg->instantiated = true too early. Fix that, then just inline the freeing of drbg->jent. Then, simplify the actual "uninstantiate" in drbg_kcapi_exit(). Just free drbg->jent (note that this is a no-op on error and null pointers), then memzero_explicit() the entire drbg_state. Note that in reality the memzero_explicit() is redundant, since the crypto_rng API zeroizes the memory anyway. But the way SP800-90A is worded, it's easy to imagine that someone assessing conformance with it would be looking for code in drbg.c that says it does an "Uninstantiate" and does the zeroization. So it's probably worth keeping it somewhat explicit, even though that means double zeroization in practice. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:17 -07:00
crypto: drbg - Put rng_alg methods in logical order Put the DRBG implementation of the rng_alg methods in the order in which they're called (cra_init => set_ent => seed => generate => cra_exit) so that it's easier to understand the flow. Also rename drbg_kcapi_random to drbg_kcapi_generate, and drbg_kcapi_cleanup to drbg_kcapi_exit, so they match the method names. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:13 -07:00
crypto: drbg - Simplify "uninstantiate" logic drbg_kcapi_seed() calls drbg_uninstantiate() only to free drbg->jent and set drbg->instantiated = false. However, the latter is necessary only because drbg_kcapi_seed() sets drbg->instantiated = true too early. Fix that, then just inline the freeing of drbg->jent. Then, simplify the actual "uninstantiate" in drbg_kcapi_exit(). Just free drbg->jent (note that this is a no-op on error and null pointers), then memzero_explicit() the entire drbg_state. Note that in reality the memzero_explicit() is redundant, since the crypto_rng API zeroizes the memory anyway. But the way SP800-90A is worded, it's easy to imagine that someone assessing conformance with it would be looking for code in drbg.c that says it does an "Uninstantiate" and does the zeroization. So it's probably worth keeping it somewhat explicit, even though that means double zeroization in practice. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:17 -07:00
crypto: drbg - Put rng_alg methods in logical order Put the DRBG implementation of the rng_alg methods in the order in which they're called (cra_init => set_ent => seed => generate => cra_exit) so that it's easier to understand the flow. Also rename drbg_kcapi_random to drbg_kcapi_generate, and drbg_kcapi_cleanup to drbg_kcapi_exit, so they match the method names. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:13 -07:00
crypto: drbg - SP800-90A Deterministic Random Bit Generator This is a clean-room implementation of the DRBG defined in SP800-90A. All three viable DRBGs defined in the standard are implemented: * HMAC: This is the leanest DRBG and compiled per default * Hash: The more complex DRBG can be enabled at compile time * CTR: The most complex DRBG can also be enabled at compile time The DRBG implementation offers the following: * All three DRBG types are implemented with a derivation function. * All DRBG types are available with and without prediction resistance. * All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available for the HMAC and Hash DRBGs. * All AES types of AES-128, AES-192 and AES-256 are available for the CTR DRBG. * A self test is implemented with drbg_healthcheck(). * The FIPS 140-2 continuous self test is implemented. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-05-31 15:44:17 +02:00
crypto: drbg - Eliminate use of 'drbg_string' and lists Use straightforward (buffer, len) parameters instead of struct drbg_string or lists of strings. This simplifies the code considerably. For now struct drbg_string is still used in crypto_drbg_ctr_df(), so move its definition to crypto/df_sp80090a.h. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:11 -07:00
crypto: drbg - SP800-90A Deterministic Random Bit Generator This is a clean-room implementation of the DRBG defined in SP800-90A. All three viable DRBGs defined in the standard are implemented: * HMAC: This is the leanest DRBG and compiled per default * Hash: The more complex DRBG can be enabled at compile time * CTR: The most complex DRBG can also be enabled at compile time The DRBG implementation offers the following: * All three DRBG types are implemented with a derivation function. * All DRBG types are available with and without prediction resistance. * All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available for the HMAC and Hash DRBGs. * All AES types of AES-128, AES-192 and AES-256 are available for the CTR DRBG. * A self test is implemented with drbg_healthcheck(). * The FIPS 140-2 continuous self test is implemented. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-05-31 15:44:17 +02:00
crypto: drbg - Fix unused value warning in drbg_healthcheck_sanity() Coverity warns uf an unused value: CID 44865 (#2 of 2): Unused value (UNUSED_VALUE) assigned_value: Assigning value -14 to ret here, but that stored value is overwritten before it can be used. 2006 int ret = -EFAULT; ... value_overwrite: Overwriting previous write to ret with value from drbg_seed(drbg, &addtl, false). 2052 ret = drbg_seed(drbg, &addtl, false); Fix this by removing the variable initializer. Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: "David S. Miller" <davem@davemloft.net> Cc: linux-crypto@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2021-09-10 13:01:17 -06:00
crypto: drbg - SP800-90A Deterministic Random Bit Generator This is a clean-room implementation of the DRBG defined in SP800-90A. All three viable DRBGs defined in the standard are implemented: * HMAC: This is the leanest DRBG and compiled per default * Hash: The more complex DRBG can be enabled at compile time * CTR: The most complex DRBG can also be enabled at compile time The DRBG implementation offers the following: * All three DRBG types are implemented with a derivation function. * All DRBG types are available with and without prediction resistance. * All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available for the HMAC and Hash DRBGs. * All AES types of AES-128, AES-192 and AES-256 are available for the CTR DRBG. * A self test is implemented with drbg_healthcheck(). * The FIPS 140-2 continuous self test is implemented. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-05-31 15:44:17 +02:00
Convert 'alloc_obj' family to use the new default GFP_KERNEL argument This was done entirely with mindless brute force, using git grep -l '\<k[vmz]*alloc_objs*(.*, GFP_KERNEL)' | xargs sed -i 's/\(alloc_objs*(.*\), GFP_KERNEL)/\1)/' to convert the new alloc_obj() users that had a simple GFP_KERNEL argument to just drop that argument. Note that due to the extreme simplicity of the scripting, any slightly more complex cases spread over multiple lines would not be triggered: they definitely exist, but this covers the vast bulk of the cases, and the resulting diff is also then easier to check automatically. For the same reason the 'flex' versions will be done as a separate conversion. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2026-02-21 16:37:42 -08:00
crypto: drbg - SP800-90A Deterministic Random Bit Generator This is a clean-room implementation of the DRBG defined in SP800-90A. All three viable DRBGs defined in the standard are implemented: * HMAC: This is the leanest DRBG and compiled per default * Hash: The more complex DRBG can be enabled at compile time * CTR: The most complex DRBG can also be enabled at compile time The DRBG implementation offers the following: * All three DRBG types are implemented with a derivation function. * All DRBG types are available with and without prediction resistance. * All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available for the HMAC and Hash DRBGs. * All AES types of AES-128, AES-192 and AES-256 are available for the CTR DRBG. * A self test is implemented with drbg_healthcheck(). * The FIPS 140-2 continuous self test is implemented. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-05-31 15:44:17 +02:00
crypto: Use scoped init guard Convert lock initialization to scoped guarded initialization where lock-guarded members are initialized in the same scope. This ensures the context analysis treats the context as active during member initialization. This is required to avoid errors once implicit context assertion is removed. Signed-off-by: Marco Elver <elver@google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20260119094029.1344361-5-elver@google.com
2026-01-19 10:05:54 +01:00
crypto: drbg - Remove drbg_core Now that none of the information in struct drbg_core is used, remove it. The null-ity of the pointer drbg_state::core was used to keep track of whether the DRBG has been instantiated. Replace it with a boolean. No functional change. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:07 -07:00
crypto: drbg - Initialise mutex in drbg_healthcheck_sanity As we moved the mutex init out of drbg_instantiate and into cra_init we need to explicitly initialise the mutex in drbg_healthcheck_sanity. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Acked-by: Stephan Mueller <smueller@chronox.de>
2015-04-20 11:26:48 +08:00
crypto: drbg - SP800-90A Deterministic Random Bit Generator This is a clean-room implementation of the DRBG defined in SP800-90A. All three viable DRBGs defined in the standard are implemented: * HMAC: This is the leanest DRBG and compiled per default * Hash: The more complex DRBG can be enabled at compile time * CTR: The most complex DRBG can also be enabled at compile time The DRBG implementation offers the following: * All three DRBG types are implemented with a derivation function. * All DRBG types are available with and without prediction resistance. * All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available for the HMAC and Hash DRBGs. * All AES types of AES-128, AES-192 and AES-256 are available for the CTR DRBG. * A self test is implemented with drbg_healthcheck(). * The FIPS 140-2 continuous self test is implemented. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-05-31 15:44:17 +02:00
crypto: Fix several spelling mistakes in comments Fix several typos in comments and messages. No functional change. Signed-off-by: Sun Chaobo <suncoding913@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-03-13 22:52:57 +08:00
crypto: drbg - Rename MAX_ADDTL => MAX_ADDTL_BYTES Give this constant a name which is clearer and consistent with DRBG_MAX_REQUEST_BYTES. No functional change. Suggested-by: Joachim Vandersmissen <joachim@jvdsn.com> Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-05-05 17:02:17 -07:00
crypto: drbg - Fix ineffective sanity check Fix drbg_healthcheck_sanity() to correctly check the return value of drbg_generate(). drbg_generate() returns 0 on success, or a negative errno value on failure. drbg_healthcheck_sanity() incorrectly assumed that it returned a positive value on success. This didn't make the sanity check fail, but it made it ineffective. Fixes: cde001e4c3c3 ("crypto: rng - RNGs must return 0 in success case") Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:33:47 -07:00
crypto: drbg - SP800-90A Deterministic Random Bit Generator This is a clean-room implementation of the DRBG defined in SP800-90A. All three viable DRBGs defined in the standard are implemented: * HMAC: This is the leanest DRBG and compiled per default * Hash: The more complex DRBG can be enabled at compile time * CTR: The most complex DRBG can also be enabled at compile time The DRBG implementation offers the following: * All three DRBG types are implemented with a derivation function. * All DRBG types are available with and without prediction resistance. * All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available for the HMAC and Hash DRBGs. * All AES types of AES-128, AES-192 and AES-256 are available for the CTR DRBG. * A self test is implemented with drbg_healthcheck(). * The FIPS 140-2 continuous self test is implemented. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-05-31 15:44:17 +02:00
crypto: drbg - Eliminate use of 'drbg_string' and lists Use straightforward (buffer, len) parameters instead of struct drbg_string or lists of strings. This simplifies the code considerably. For now struct drbg_string is still used in crypto_drbg_ctr_df(), so move its definition to crypto/df_sp80090a.h. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:11 -07:00
crypto: drbg - Fix ineffective sanity check Fix drbg_healthcheck_sanity() to correctly check the return value of drbg_generate(). drbg_generate() returns 0 on success, or a negative errno value on failure. drbg_healthcheck_sanity() incorrectly assumed that it returned a positive value on success. This didn't make the sanity check fail, but it made it ineffective. Fixes: cde001e4c3c3 ("crypto: rng - RNGs must return 0 in success case") Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:33:47 -07:00
crypto: drbg - SP800-90A Deterministic Random Bit Generator This is a clean-room implementation of the DRBG defined in SP800-90A. All three viable DRBGs defined in the standard are implemented: * HMAC: This is the leanest DRBG and compiled per default * Hash: The more complex DRBG can be enabled at compile time * CTR: The most complex DRBG can also be enabled at compile time The DRBG implementation offers the following: * All three DRBG types are implemented with a derivation function. * All DRBG types are available with and without prediction resistance. * All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available for the HMAC and Hash DRBGs. * All AES types of AES-128, AES-192 and AES-256 are available for the CTR DRBG. * A self test is implemented with drbg_healthcheck(). * The FIPS 140-2 continuous self test is implemented. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-05-31 15:44:17 +02:00
crypto: drbg - Rename MAX_ADDTL => MAX_ADDTL_BYTES Give this constant a name which is clearer and consistent with DRBG_MAX_REQUEST_BYTES. No functional change. Suggested-by: Joachim Vandersmissen <joachim@jvdsn.com> Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-05-05 17:02:17 -07:00
crypto: drbg - Eliminate use of 'drbg_string' and lists Use straightforward (buffer, len) parameters instead of struct drbg_string or lists of strings. This simplifies the code considerably. For now struct drbg_string is still used in crypto_drbg_ctr_df(), so move its definition to crypto/df_sp80090a.h. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:11 -07:00
crypto: drbg - SP800-90A Deterministic Random Bit Generator This is a clean-room implementation of the DRBG defined in SP800-90A. All three viable DRBGs defined in the standard are implemented: * HMAC: This is the leanest DRBG and compiled per default * Hash: The more complex DRBG can be enabled at compile time * CTR: The most complex DRBG can also be enabled at compile time The DRBG implementation offers the following: * All three DRBG types are implemented with a derivation function. * All DRBG types are available with and without prediction resistance. * All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available for the HMAC and Hash DRBGs. * All AES types of AES-128, AES-192 and AES-256 are available for the CTR DRBG. * A self test is implemented with drbg_healthcheck(). * The FIPS 140-2 continuous self test is implemented. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-05-31 15:44:17 +02:00
crypto: drbg - do not call drbg_instantiate in healt test When calling the DRBG health test in FIPS mode, the Jitter RNG is not yet present in the kernel crypto API which will cause the instantiation to fail and thus the health test to fail. As the health tests cover the enforcement of various thresholds, invoke the functions that are supposed to enforce the thresholds directly. This patch also saves precious seed. Reported-by: Tapas Sarangi <TSarangi@trustwave.com> Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2016-08-09 21:02:36 +02:00
crypto: drbg - Eliminate use of 'drbg_string' and lists Use straightforward (buffer, len) parameters instead of struct drbg_string or lists of strings. This simplifies the code considerably. For now struct drbg_string is still used in crypto_drbg_ctr_df(), so move its definition to crypto/df_sp80090a.h. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:11 -07:00
crypto: drbg - SP800-90A Deterministic Random Bit Generator This is a clean-room implementation of the DRBG defined in SP800-90A. All three viable DRBGs defined in the standard are implemented: * HMAC: This is the leanest DRBG and compiled per default * Hash: The more complex DRBG can be enabled at compile time * CTR: The most complex DRBG can also be enabled at compile time The DRBG implementation offers the following: * All three DRBG types are implemented with a derivation function. * All DRBG types are available with and without prediction resistance. * All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available for the HMAC and Hash DRBGs. * All AES types of AES-128, AES-192 and AES-256 are available for the CTR DRBG. * A self test is implemented with drbg_healthcheck(). * The FIPS 140-2 continuous self test is implemented. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-05-31 15:44:17 +02:00
crypto: drbg - Remove support for "prediction resistance" "Prediction resistance", i.e. the property that the RNG's output is unpredictable even after a state compromise, might sound like a nice property to have. In reality, it's not very practical, as it requires that fresh entropy be pulled on every request. (The normal Linux RNG doesn't provide prediction resistance.) In the case of drbg.c, that means pulling from "jitterentropy", which is extremely slow. For some perspective, running a simple benchmark, generating 32 random bytes takes the following amount of time: get_random_bytes(): 90 ns drbg_nopr_hmac_sha512: 3707 ns drbg_pr_hmac_sha512: 773082 ns So at least in this case, the "pr" (prediction-resistant) DRBG is over 200 times slower than the "nopr" (non-prediction-resistant) DRBG, or over 8000 times slower than the normal Linux RNG. While anyone using drbg.c has always had to tolerate that it's slower than the normal Linux RNG, the "pr" DRBG is clearly at another level of slowness. Thus, the following is also entirely unsurprising: - FIPS 140-3 doesn't actually require that SP800-90A DRBG implementations support prediction resistance. The non-prediction resistant DRBGs can be, and have been, certified. - drbg.c registers "drbg_nopr_hmac_sha512" with a higher cra_priority than "drbg_pr_hmac_sha512". So "drbg_nopr_hmac_sha512" is already the one actually being used in practice. Given these considerations, it's clear that "drbg_pr_hmac_sha512" isn't actually useful, and it essentially just existed as another curiosity in the museum of crypto algorithms. Remove it to simplify the code. Suggested-by: Joachim Vandersmissen <joachim@jvdsn.com> Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-05-05 17:02:58 -07:00
crypto: drbg - Simplify algorithm registration Now that "drbg_pr_hmac_sha512" and "drbg_nopr_hmac_sha512" are the only crypto_rng algorithms left in crypto/drbg.c, simplify the algorithm registration logic to register these more directly without relying on the drbg_cores[] array (which will be removed). Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:02 -07:00
crypto: drbg - SP800-90A Deterministic Random Bit Generator This is a clean-room implementation of the DRBG defined in SP800-90A. All three viable DRBGs defined in the standard are implemented: * HMAC: This is the leanest DRBG and compiled per default * Hash: The more complex DRBG can be enabled at compile time * CTR: The most complex DRBG can also be enabled at compile time The DRBG implementation offers the following: * All three DRBG types are implemented with a derivation function. * All DRBG types are available with and without prediction resistance. * All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available for the HMAC and Hash DRBGs. * All AES types of AES-128, AES-192 and AES-256 are available for the CTR DRBG. * A self test is implemented with drbg_healthcheck(). * The FIPS 140-2 continuous self test is implemented. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-05-31 15:44:17 +02:00
crypto: drbg - fix error return code Fix to return a negative error code from the error handling case instead of 0. Signed-off-by: Wei Yongjun <weiyj.lk@gmail.com> Acked-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2016-08-20 15:06:51 +00:00
crypto: drbg - SP800-90A Deterministic Random Bit Generator This is a clean-room implementation of the DRBG defined in SP800-90A. All three viable DRBGs defined in the standard are implemented: * HMAC: This is the leanest DRBG and compiled per default * Hash: The more complex DRBG can be enabled at compile time * CTR: The most complex DRBG can also be enabled at compile time The DRBG implementation offers the following: * All three DRBG types are implemented with a derivation function. * All DRBG types are available with and without prediction resistance. * All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available for the HMAC and Hash DRBGs. * All AES types of AES-128, AES-192 and AES-256 are available for the CTR DRBG. * A self test is implemented with drbg_healthcheck(). * The FIPS 140-2 continuous self test is implemented. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-05-31 15:44:17 +02:00
crypto: drbg - Simplify algorithm registration Now that "drbg_pr_hmac_sha512" and "drbg_nopr_hmac_sha512" are the only crypto_rng algorithms left in crypto/drbg.c, simplify the algorithm registration logic to register these more directly without relying on the drbg_cores[] array (which will be removed). Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:02 -07:00
crypto: drbg - Remove support for "prediction resistance" "Prediction resistance", i.e. the property that the RNG's output is unpredictable even after a state compromise, might sound like a nice property to have. In reality, it's not very practical, as it requires that fresh entropy be pulled on every request. (The normal Linux RNG doesn't provide prediction resistance.) In the case of drbg.c, that means pulling from "jitterentropy", which is extremely slow. For some perspective, running a simple benchmark, generating 32 random bytes takes the following amount of time: get_random_bytes(): 90 ns drbg_nopr_hmac_sha512: 3707 ns drbg_pr_hmac_sha512: 773082 ns So at least in this case, the "pr" (prediction-resistant) DRBG is over 200 times slower than the "nopr" (non-prediction-resistant) DRBG, or over 8000 times slower than the normal Linux RNG. While anyone using drbg.c has always had to tolerate that it's slower than the normal Linux RNG, the "pr" DRBG is clearly at another level of slowness. Thus, the following is also entirely unsurprising: - FIPS 140-3 doesn't actually require that SP800-90A DRBG implementations support prediction resistance. The non-prediction resistant DRBGs can be, and have been, certified. - drbg.c registers "drbg_nopr_hmac_sha512" with a higher cra_priority than "drbg_pr_hmac_sha512". So "drbg_nopr_hmac_sha512" is already the one actually being used in practice. Given these considerations, it's clear that "drbg_pr_hmac_sha512" isn't actually useful, and it essentially just existed as another curiosity in the museum of crypto algorithms. Remove it to simplify the code. Suggested-by: Joachim Vandersmissen <joachim@jvdsn.com> Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-05-05 17:02:58 -07:00
crypto: drbg - Simplify algorithm registration Now that "drbg_pr_hmac_sha512" and "drbg_nopr_hmac_sha512" are the only crypto_rng algorithms left in crypto/drbg.c, simplify the algorithm registration logic to register these more directly without relying on the drbg_cores[] array (which will be removed). Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:02 -07:00
crypto: drbg - Remove support for "prediction resistance" "Prediction resistance", i.e. the property that the RNG's output is unpredictable even after a state compromise, might sound like a nice property to have. In reality, it's not very practical, as it requires that fresh entropy be pulled on every request. (The normal Linux RNG doesn't provide prediction resistance.) In the case of drbg.c, that means pulling from "jitterentropy", which is extremely slow. For some perspective, running a simple benchmark, generating 32 random bytes takes the following amount of time: get_random_bytes(): 90 ns drbg_nopr_hmac_sha512: 3707 ns drbg_pr_hmac_sha512: 773082 ns So at least in this case, the "pr" (prediction-resistant) DRBG is over 200 times slower than the "nopr" (non-prediction-resistant) DRBG, or over 8000 times slower than the normal Linux RNG. While anyone using drbg.c has always had to tolerate that it's slower than the normal Linux RNG, the "pr" DRBG is clearly at another level of slowness. Thus, the following is also entirely unsurprising: - FIPS 140-3 doesn't actually require that SP800-90A DRBG implementations support prediction resistance. The non-prediction resistant DRBGs can be, and have been, certified. - drbg.c registers "drbg_nopr_hmac_sha512" with a higher cra_priority than "drbg_pr_hmac_sha512". So "drbg_nopr_hmac_sha512" is already the one actually being used in practice. Given these considerations, it's clear that "drbg_pr_hmac_sha512" isn't actually useful, and it essentially just existed as another curiosity in the museum of crypto algorithms. Remove it to simplify the code. Suggested-by: Joachim Vandersmissen <joachim@jvdsn.com> Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-05-05 17:02:58 -07:00
crypto: drbg - SP800-90A Deterministic Random Bit Generator This is a clean-room implementation of the DRBG defined in SP800-90A. All three viable DRBGs defined in the standard are implemented: * HMAC: This is the leanest DRBG and compiled per default * Hash: The more complex DRBG can be enabled at compile time * CTR: The most complex DRBG can also be enabled at compile time The DRBG implementation offers the following: * All three DRBG types are implemented with a derivation function. * All DRBG types are available with and without prediction resistance. * All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available for the HMAC and Hash DRBGs. * All AES types of AES-128, AES-192 and AES-256 are available for the CTR DRBG. * A self test is implemented with drbg_healthcheck(). * The FIPS 140-2 continuous self test is implemented. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-05-31 15:44:17 +02:00
crypto: drbg - Remove support for "prediction resistance" "Prediction resistance", i.e. the property that the RNG's output is unpredictable even after a state compromise, might sound like a nice property to have. In reality, it's not very practical, as it requires that fresh entropy be pulled on every request. (The normal Linux RNG doesn't provide prediction resistance.) In the case of drbg.c, that means pulling from "jitterentropy", which is extremely slow. For some perspective, running a simple benchmark, generating 32 random bytes takes the following amount of time: get_random_bytes(): 90 ns drbg_nopr_hmac_sha512: 3707 ns drbg_pr_hmac_sha512: 773082 ns So at least in this case, the "pr" (prediction-resistant) DRBG is over 200 times slower than the "nopr" (non-prediction-resistant) DRBG, or over 8000 times slower than the normal Linux RNG. While anyone using drbg.c has always had to tolerate that it's slower than the normal Linux RNG, the "pr" DRBG is clearly at another level of slowness. Thus, the following is also entirely unsurprising: - FIPS 140-3 doesn't actually require that SP800-90A DRBG implementations support prediction resistance. The non-prediction resistant DRBGs can be, and have been, certified. - drbg.c registers "drbg_nopr_hmac_sha512" with a higher cra_priority than "drbg_pr_hmac_sha512". So "drbg_nopr_hmac_sha512" is already the one actually being used in practice. Given these considerations, it's clear that "drbg_pr_hmac_sha512" isn't actually useful, and it essentially just existed as another curiosity in the museum of crypto algorithms. Remove it to simplify the code. Suggested-by: Joachim Vandersmissen <joachim@jvdsn.com> Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-05-05 17:02:58 -07:00
crypto: drbg - SP800-90A Deterministic Random Bit Generator This is a clean-room implementation of the DRBG defined in SP800-90A. All three viable DRBGs defined in the standard are implemented: * HMAC: This is the leanest DRBG and compiled per default * Hash: The more complex DRBG can be enabled at compile time * CTR: The most complex DRBG can also be enabled at compile time The DRBG implementation offers the following: * All three DRBG types are implemented with a derivation function. * All DRBG types are available with and without prediction resistance. * All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available for the HMAC and Hash DRBGs. * All AES types of AES-128, AES-192 and AES-256 are available for the CTR DRBG. * A self test is implemented with drbg_healthcheck(). * The FIPS 140-2 continuous self test is implemented. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-05-31 15:44:17 +02:00
crypto: drbg - drbg_exit() can be static CC: Stephan Mueller <smueller@chronox.de> Signed-off-by: Fengguang Wu <fengguang.wu@intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-07-10 16:52:04 +08:00
crypto: drbg - SP800-90A Deterministic Random Bit Generator This is a clean-room implementation of the DRBG defined in SP800-90A. All three viable DRBGs defined in the standard are implemented: * HMAC: This is the leanest DRBG and compiled per default * Hash: The more complex DRBG can be enabled at compile time * CTR: The most complex DRBG can also be enabled at compile time The DRBG implementation offers the following: * All three DRBG types are implemented with a derivation function. * All DRBG types are available with and without prediction resistance. * All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available for the HMAC and Hash DRBGs. * All AES types of AES-128, AES-192 and AES-256 are available for the CTR DRBG. * A self test is implemented with drbg_healthcheck(). * The FIPS 140-2 continuous self test is implemented. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-05-31 15:44:17 +02:00
crypto: drbg - Remove support for "prediction resistance" "Prediction resistance", i.e. the property that the RNG's output is unpredictable even after a state compromise, might sound like a nice property to have. In reality, it's not very practical, as it requires that fresh entropy be pulled on every request. (The normal Linux RNG doesn't provide prediction resistance.) In the case of drbg.c, that means pulling from "jitterentropy", which is extremely slow. For some perspective, running a simple benchmark, generating 32 random bytes takes the following amount of time: get_random_bytes(): 90 ns drbg_nopr_hmac_sha512: 3707 ns drbg_pr_hmac_sha512: 773082 ns So at least in this case, the "pr" (prediction-resistant) DRBG is over 200 times slower than the "nopr" (non-prediction-resistant) DRBG, or over 8000 times slower than the normal Linux RNG. While anyone using drbg.c has always had to tolerate that it's slower than the normal Linux RNG, the "pr" DRBG is clearly at another level of slowness. Thus, the following is also entirely unsurprising: - FIPS 140-3 doesn't actually require that SP800-90A DRBG implementations support prediction resistance. The non-prediction resistant DRBGs can be, and have been, certified. - drbg.c registers "drbg_nopr_hmac_sha512" with a higher cra_priority than "drbg_pr_hmac_sha512". So "drbg_nopr_hmac_sha512" is already the one actually being used in practice. Given these considerations, it's clear that "drbg_pr_hmac_sha512" isn't actually useful, and it essentially just existed as another curiosity in the museum of crypto algorithms. Remove it to simplify the code. Suggested-by: Joachim Vandersmissen <joachim@jvdsn.com> Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-05-05 17:02:58 -07:00
crypto: drbg - SP800-90A Deterministic Random Bit Generator This is a clean-room implementation of the DRBG defined in SP800-90A. All three viable DRBGs defined in the standard are implemented: * HMAC: This is the leanest DRBG and compiled per default * Hash: The more complex DRBG can be enabled at compile time * CTR: The most complex DRBG can also be enabled at compile time The DRBG implementation offers the following: * All three DRBG types are implemented with a derivation function. * All DRBG types are available with and without prediction resistance. * All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available for the HMAC and Hash DRBGs. * All AES types of AES-128, AES-192 and AES-256 are available for the CTR DRBG. * A self test is implemented with drbg_healthcheck(). * The FIPS 140-2 continuous self test is implemented. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-05-31 15:44:17 +02:00
Revert "crypto: run initcalls for generic implementations earlier" This reverts commit c4741b23059794bd99beef0f700103b0d983b3fd. Crypto API self-tests no longer run at registration time and now occur either at late_initcall or upon the first use. Therefore the premise of the above commit no longer exists. Revert it and subsequent additions of subsys_initcall and arch_initcall. Note that lib/crypto calls will stay at subsys_initcall (or rather downgraded from arch_initcall) because they may need to occur before Crypto API registration. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-04-30 16:17:02 +08:00
crypto: drbg - SP800-90A Deterministic Random Bit Generator This is a clean-room implementation of the DRBG defined in SP800-90A. All three viable DRBGs defined in the standard are implemented: * HMAC: This is the leanest DRBG and compiled per default * Hash: The more complex DRBG can be enabled at compile time * CTR: The most complex DRBG can also be enabled at compile time The DRBG implementation offers the following: * All three DRBG types are implemented with a derivation function. * All DRBG types are available with and without prediction resistance. * All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available for the HMAC and Hash DRBGs. * All AES types of AES-128, AES-192 and AES-256 are available for the CTR DRBG. * A self test is implemented with drbg_healthcheck(). * The FIPS 140-2 continuous self test is implemented. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-05-31 15:44:17 +02:00
crypto: drbg - Remove support for HASH_DRBG Remove the support for HASH_DRBG. It's likely unused code, seeing as HMAC_DRBG is always enabled and prioritized over it unless NETLINK_CRYPTO is used to change the algorithm priorities. There's also no compelling reason to support more than one of [HMAC_DRBG, HASH_DRBG, CTR_DRBG]. By definition, callers cannot tell any difference in their outputs. And all are FIPS-certifiable, which is the only point of the kernel's NIST DRBGs anyway. Switching to HASH_DRBG doesn't seem all that compelling, either. For one, it's more complex than HMAC_DRBG. Thus, let's just drop HASH_DRBG support and focus on HMAC_DRBG. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> # m68k Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:33:57 -07:00
crypto: drbg - Add stdrng alias and increase priority This patch adds the stdrng module alias and increases the priority to ensure that it is loaded in preference to other RNGs. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-06-03 14:49:28 +08:00
crypto: drbg - Move module aliases to end of file Move the MODULE_ALIAS_CRYPTO lines in the middle of the file to the end so that they are in the usual place and next to the other one. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-04-19 23:34:09 -07:00