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>

0 files changed, 0 insertions, 0 deletions