4 ms·
Thanks, that's an elegant solution. In case the entropy pool is drained, one would still want to get more than 128 bits from urandom and then hash this with SH
by jorangreef 11y ago
Thanks, that's an elegant solution.
In case the entropy pool is drained, one would still want to get more than 128 bits from urandom and then hash this with SHA2 to get the 128 bit key, right?
I had in mind something portable to the browser without requiring AES there, but will try it out on the server.
- tptacek 11y agoIn a practical sense, there is no such thing as draining an entropy pool. The period for AES-CTR is 2^128. The primary reason CSPRNGs rekey themselves periodically is for forward security, so that if your machine gets hacked, an attacker can't snarf the RNG state and predict all future numbers the machine generates.
- Tomte 11y agoForward security is obviously a desirable design feature in a CSPRNG (as a building block that's evaluated and reviewed on its own merits), but I can't help but feel that it's often distracting people from a whole system view. If an attacker has access to your computer on a level where he can inspect the CSPRNG's state, you've probably lost completely and no reseeding will help you.
- tptacek 11y agoI agree, of course.
- tedunangst 11y agoYou also want to stop backtracking. If I can grab the key and counter for your AES stream, I can roll back and generate all the numbers you generated last week too.