4 ms·
For cryptographic applications you generally just hash every input you have together with secure hash function. Somewhat philosophical corollary to that is tha
by dfox 9y ago
For cryptographic applications you generally just hash every input you have together with secure hash function.
Somewhat philosophical corollary to that is that when you have hash function that is secure enough for your application you can just build CSPRNG from it and use small (eg. 128 or 256 bit) seed and you have no need for hardware RNG.
- tptacek 9y agoYes, modulo the fact that you want to update the CSPRNG with new entropy continuously to re-key it. Not to improve the cryptographic strength of the output or (for God's sake) to avoid "depletion", but to create forward secrecy. For instance: if the interval between reseedings is short enough, because updates are super cheap, you can make your RNG state churn too fast to be a useful target for something like Meltdown.
- dfox 9y agoYes, but you don't need some dedicated source of high-bandwith random noise for that, using sources that already exist in essentially any system is almost certainly sufficient.
- tptacek 9y agoYep.
- pvg 9y agoHow does reseeding the CSPRNG create forward secrecy? I thought that if someone lifts your CSPRNG internal state (after it's been seeded and the seed tossed), they wouldn't be able to play it backwards to get previous output you've used as session keys or whatever.
- tptacek 9y agoI'm abusing the term, I know. But the idea is simple, right? Even a minuscule update to the kernel entropy pool makes a previously compromised state unusable. So you don't want your CSPRNG to just be a bit generator, like HMAC or CTR. (Zvi Gutterman refers to the property I'm talking about as "backwards security", so my abuse of the term is particularly egregious).
- pvg 9y agoHah, I was really asking what you meant, not trying to chide you about about terminology. Makes sense, thanks.