]> git.ipfire.org Git - thirdparty/kernel/linux.git/commit
crypto: drbg - Remove obsolete FIPS 140-2 continuous test
authorEric Biggers <ebiggers@kernel.org>
Mon, 20 Apr 2026 06:33:53 +0000 (23:33 -0700)
committerHerbert Xu <herbert@gondor.apana.org.au>
Thu, 7 May 2026 08:09:59 +0000 (16:09 +0800)
commitf4919bbca03c8d130a46eba99535b5730edd89a6
tree4e562449e412a2100952a47f323e951ddd0d26f2
parent06dc3f01e789cdad4d99b99eba35acb26d227f53
crypto: drbg - Remove obsolete FIPS 140-2 continuous test

FIPS 140-2 required that a continuous test for repeated outputs be done
on both "Approved RNGs" and "Non-Approved RNGs".

That's apparently why crypto/drbg.c does such a test on the bytes it
pulls from get_random_bytes(), despite get_random_bytes() being a
"Non-Approved RNG" that is credited with zero entropy for FIPS purposes.
(From FIPS's point of view, the "Approved RNG" is jitterentropy.)

FIPS 140-3 "modernized" the continuous RNG test requirements.  They're
now a bit more sophisticated, requiring both an "Adaptive Proportion
Test" and a "Repetition Count Test".

At the same time, FIPS 140-3 doesn't require continuous RNG tests on
"Non-Approved RNGs" if a "vetted conditioning component" is used.  The
SP800-90A DRBGs are exactly such a vetted conditioning component, by
their design.  (In the case of HASH_DRBG and CTR_DRBG, the derivation
function does have to be implemented.  But the kernel does that.)

In other words: from FIPS 140-3's point of view, get_random_bytes()
still produces zero entropy, but the way the DRBG combines those bytes
with the jitterentropy bytes preserves all the "approved" entropy from
jitterentropy.  Thus no test for get_random_bytes() is required.

Seeing as FIPS 140-2 certificates stopped being issued in 2021 in favor
of FIPS 140-3, this means this code is obsolete.  Remove it.

Signed-off-by: Eric Biggers <ebiggers@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
crypto/drbg.c
include/crypto/drbg.h