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>

0 files changed, 0 insertions, 0 deletions