CSPRNG's (ELI5) What's the purpose of multiple seeds/ regenerating sources of entropy (i.e. /dev/random)?

Question

Why is there a need to generate more than one high entropy seed? It would seem like if the original source of entropy is high quality, than some 512 bits should be more than enough to seed a CSPRNG which has no strong (or known) weaknesses, and pretty much endlessly generate new random numbers and re-seed itself. The average user needs very few cryptographically strong random numbers over the life time of a computer, almost surely (<10⁶) will be enough for all of said users potential applications.

On the other hand reading about cryptographic RNGs / encryption as some one that deals with them occasionally in code, and knows a bit of math, (but not highly technical literature by any means), one gets a highly disjointed sense of what people consider correct seeding procedure, how often a seed should be re-used, /dev/random vs. /dev/urandom, etcetera.

Would re-seeding to generate some 10⁶ random bytes really be enough to find a weakness in CSPRNG and in such a way as to make the original entropy source weak enough to regenerate it with a human lifetime?

I'm not sure if this is more of a Math Stack Exchange or Stack Overflow question. But I would really like to see some mathematically / logically convincing guidelines. I can reference some specific CSPRNGs (but I'm not sure whether that helps or hurts the discussion).

Answer 1

Check out NIST SP800-90A.

8.6: Seeds

Reseeding is a means of restoring the secrecy of the output of the DRBG if a seed or the internal state becomes known. Periodic reseeding is a good way of addressing the threat of either the DRBG seed, entropy input or working state being compromised over time. In some implementations (e.g., smartcards), an adequate reseeding process may not be possible. In these cases, the best policy might be to replace the DRBG, obtaining a new seed in the process (e.g., obtain a new smart card).

8.6.8: Reseeding

Generating too many outputs from a seed (and other input information) may provide sufficient information for successfully predicting future outputs (see Section 8.8). Periodic reseeding will reduce security risks, reducing the likelihood of a compromise of the data that is protected by cryptographic mechanisms that use the DRBG.

But also:

9.2: Reseeding a DRBG Instantiation

The reseeding of an instantiation is not required, but is recommended whenever a comsuming application and implementation are able to perform this process. Reseeding will insert additional entropy input into the generation of pseudorandom bits.

It depends on the random number generator if a reseed is necessary. For hash based algorithms, the time before the algorithm hits the same state is very high, so reseeding is certainly not directly required for that reason.

---

NIST specifies 2^48 calls as maximum to DRBG (e.g. 10.1, table 2) before the DRBG should be reseeded. Even if you take just one bit, then this would still be more than 10^6 that you mention. This is for the hash and AES based algorithms. The number of calls to the 3DES and Dual_EC DRNG's is much lower though, so in the end it depends on the DRNG in use.

---

Note that stating that 10^6 of random numbers is enough for anyone is like stating that 64 KiB is enough for anyone. I would not make that statement in the same way that Bill didn't.

Reseeding should not have to happen very often if leakage of the state can be avoided (beware of side channel attacks). Saying that it should never happen is however taking it too far. That said, if my computer wouldn't reseed for a week, I would not loose any sleep over it.