# Hardening of random number generators

Boxcryptor uses various CSPRNGs and apparently hashes the output using PBKDF2 to derive the final key. Even though the choice of PBKDF2 is probably not semantically correct (PBKDF2 is intended for passwords), I wonder if this iterative hardening actually makes sense.

Let's suppose the CSPRNG is backdoored/buggy/broken/etc (we have already seen that in the past), and for 128-bit output, you just get let's say 64 bits of entropy (the rest is supposedly predictable by an adversary). So the adversary has to work 264, which he can brute-force. But now the app does:

key = PBKDF2(csprng_output, salt, 1000000)

Not sure where the salt comes from (since they don't trust the CSPRNG, I guess it's fixed??), but does this make sense? Adversary still has to guess 264 obviously, but each guess takes a lot of work. After all, that's exactly why we use PBKDF2 on passwords to be secure despite their low entropy.

• Seems to me that if the RNG is broken in the sense that it is predictable (by someone) that performing PBKDF2 won't do much good. The salt will be predictable as well. If the RNG doesn't generate enough entropy then this technique seems to add a bit of security. Basically, if the attacker has to guess than it may add a layer of security. How much depends on how much the attacker has to guess (if only 2 random values are possible then having the attacker do 2 PBKDF2 calculations won't do much). – Maarten Bodewes May 24 '15 at 0:15
• If the RNG does provide entropy then it may be more sensible generate a lot of data and to use a KBKDF such as HKDF or to feed the entropy in into a random number generator (just to bring it back to a previous problem, maybe I'm a mathematician after all :) ) – Maarten Bodewes May 24 '15 at 0:18
• umm AFAIK the system RNG works as a normal PRG periodically seeded through gathered entropy, right? So if I sample a lot of data from that CryptGenRandom or whatever I use, there is a good chance that all that data will come from the same seed of the system PRG. – Paya May 24 '15 at 1:27
• That's true, but usually the internal state is pretty large. I'm not sure about the precise implementation though. Never hurts to reseed it a bit of course, maybe between calls. – Maarten Bodewes May 24 '15 at 2:04