Re: [PATCH 36/38] crypto: drbg - Remove redundant reseeding based on random.c state
From: Eric Biggers
Date: Mon Apr 20 2026 - 13:32:54 EST
On Mon, Apr 20, 2026 at 11:48:47AM -0500, Joachim Vandersmissen wrote:
> Hi Eric,
>
> On 4/20/26 1:34 AM, Eric Biggers wrote:
> > 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.)
> It's fair to say that the additional input is as good as a reseed (if FIPS
> is not considered), but then is there any reason to keep get_random_bytes()
> in drbg_seed()? You say it could be removed but it's safer to keep it there
> for now? In what way is it safer? The additional input is mixed into the
> HMAC_DRBG state prior to generating random bits, so should already provide
> sufficient assurance that the generated bits incorporate the output of
> get_random_bytes()?
I do agree that patch 34 makes the get_random_bytes() in drbg_seed()
redundant too. I'm just not yet sure that removing it would strike the
right balance between defense in depth and eliminating redundancy.
Keeping it there also keeps it very clear that whenever jitterentropy
entropy is used, we're also using an equal number of bytes from
get_random_bytes() alongside it. (Remember, not everyone "trusts"
jitterentropy. People auditing this code might *really* want to see the
get_random_bytes().) The additional input does achieve the
get_random_bytes() integration anyway, just it's a bit more subtle.
- Eric