Seed / reseed DRBG too often?

Question

There are limits to how much you can use a the DRBG before you have to reseed it, but are there any limits to how much you must use it before reseeding?

Take the following scenarios as an example…

Usually you seed the DRBG once, then you use that instance until you reach the reseed limit. Like so:

seed     = seedFromUrandom    // Reads entropy from /dev/urandom
genStart = drbgFromSeed seed
(v1, gen1) = genBytes genStart // Generates random data and the next state 
                               // of the DRBG as a tuple
/*
    Code using the random data in v1
*/
(v2, gen2) = genBytes gen1 // Generates more random data and the next state
                           // of the DRBG as a tuple. Note that gen1 is 
                           // used here and not genStart.
/*
    Code using the random data in v2
*/

What if you created a newly seeded instance each time you want to generate random data? Like so:

seed     = seedFromUrandom    // Reads entropy from /dev/urandom
genStart = drbgFromSeed seed
(v1, _)  = genBytes genStart // Generates random data and ignores the
                             // next instance of the DRBG.
/*
    Code using the random data in v1
*/
seed     = seedFromUrandom    // Reads entropy from /dev/urandom
genStart = drbgFromSeed seed
(v2, _)  = genBytes genStart // Generates random data and ignores the
                             // next instance of the DRBG.
/*
    Code using the random data in v2
*/

Please note:

• When I say “DRBG”, I mean the NIST standardized number-theoretically secure random number generator. Either HMAC (SHA512), Hash (SHA512), or counter (AES 128).
• Like stated in the pseudo-code, entropy is read from /dev/urandom.

Answer 1

/dev/urandom itself is an acceptable crypto-quality (P)RNG. Therefore it can't hurt security to call it as often as you want. Assuming that /dev/urandom operates correctly (i.e. returns bit that cannot be predicted), the probability for an observer to correctly predict the bits generated by drbgFromSeed decreases (very slowly) with the number of generated bits.

You could, in fact, read from /dev/urandom and never use a DRBG internally. There are reasons not to do that, but they aren't security:

• The most common reason to avoid reading /dev/urandom too often is performance.
• You may prefer to use a know PRNG internally and keep outside sources as strictly entropy injection. This would make your application portable to platforms that don't provide a usable PRNG, and you have to make do with something else (e.g. downloaded or pre-seeded entropy).
• Using your own DRBG implementation (or a known good one) can help if you need to demonstrate the security of your application.
• Maybe you need the determinism property at some point — but then you're better off using an explicit KDF.

What you need to be extremely careful of is never using the same DRBG state more than once. Discarding a DRBG state is fine. The DRBG state has an affine type (your syntax looks like Haskell, beware that without a monad to enforce linearity, the mistake of reusing a DRBG state is a lot more likely than in an imperative language).

Answer 2

Too long for a comment...

The Haskell DRBG package makes you reseed every so often (2^48 requests, iirc) because that is what SP800-90 specified. Instead of reseeding, you could construct an auto-reseeding generator, which would have higher period, and genBytes from the exception module (so you don't have to deal with an Either type). Notice the second generator, the one performing the auto-reseed, could be one that never needs reseeding - such as SystemRandom.