3 ms·
Relying on seed-based algorithms makes the seed very attractive for leaking by some side channel, how does CSRNG prevent that?
by rini17 7y ago
Relying on seed-based algorithms makes the seed very attractive for leaking by some side channel, how does CSRNG prevent that?
- wahern 7y agoI'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
- baby 7y agoBasically PRNGs often gets re-seeded periodically, preventing a leak/compromise of one seed to lead to a long-lived compromise. (This is a property called backward secrecy or post-compromise security)