kernel/linux.git/crypto/drbg.c, branch v7.2-rc1

crypto: drbg - Remove support for "prediction resistance"

2026-05-15T10:08:47+00:00

"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 Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu

crypto: drbg - Rename MAX_ADDTL => MAX_ADDTL_BYTES

2026-05-15T10:08:47+00:00

Give this constant a name which is clearer and consistent with DRBG_MAX_REQUEST_BYTES. No functional change. Suggested-by: Joachim Vandersmissen Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu

crypto: drbg - Clean up loop in drbg_hmac_update()

2026-05-07T08:10:01+00:00

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 Signed-off-by: Herbert Xu

crypto: drbg - Clean up generation code

2026-05-07T08:10:01+00:00

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 Signed-off-by: Herbert Xu

crypto: drbg - Remove redundant reseeding based on random.c state

2026-05-07T08:10:01+00:00

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 Signed-off-by: Herbert Xu

crypto: drbg - Change DRBG_MAX_REQUESTS to 4096

2026-05-07T08:10:01+00:00

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 Signed-off-by: Herbert Xu

crypto: drbg - Include get_random_bytes() output in additional input

2026-05-07T08:10:01+00:00

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 Signed-off-by: Herbert Xu

crypto: drbg - Simplify "uninstantiate" logic

2026-05-07T08:10:01+00:00

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 Signed-off-by: Herbert Xu

crypto: drbg - Fold drbg_prepare_hrng() into drbg_kcapi_seed()

2026-05-07T08:10:01+00:00

Fold drbg_prepare_hrng() into its only caller. Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu

crypto: drbg - Separate "reseed" case in drbg_kcapi_seed()

2026-05-07T08:10:01+00:00

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 Signed-off-by: Herbert Xu