I'm not sure what the seed has to do with anything. Every CSPRNG has a state which can be leaked, and while nominally larger than a typical seed, if a side-chan

I'm not sure what the seed has to do with anything. Every CSPRNG has a state which can be leaked, and while nominally larger than a typical seed, if a side-channel leaks 32 bytes then it likely can leak 512 bytes, 1Kb, etc. (The way the article distinguishes the "RNG" entropy pool from the "CSRNG" seems rather confusing and maybe a reflection of Linux' convoluted framework. Better to think of the whole framework as a giant, overwrought CSPRNG function.) A proper CSPRNG offers forward security, which means if the state is leaked in the future then past outputs are still secure. This is usually accomplished by cycling the PRNG after output. There'a also backward security (perhaps what you were getting at), which means future outputs are protected from past leaks. Of course, you need new randomness to achieve backward security. AFAIK, typical kernel CSPRNGs mix in new entropy on a regular basis (notwithstanding the implication in the article that on Linux this can be unnecessarily delayed). However, that's not necessarily a better thing. Daniel Bernstein has argued that maybe, depending on your threat model, you're better off with a purely deterministic CSPRNG after initial seeding: https://blog.cr.yp.to/20140205-entropy.html https://blog.cr.yp.to/20140205-entropy.html