Hacker News Reader

Comment by Spittie | Hacker News Reader

This is probably a stupid question, as I don't know much about /dev/random and /dev/urandom (and that article doesn't seems to address it fully), but I'll ask anyway: Doesn't /dev/random block only when it estimates that the entropy pool is empty, aka when it would create unsafe numbers? The article says that the estimate is likely wrong and there is still enough entropy left, but what if it's actually empty?

If this is true, then /dev/urandom might split out unsafe bits (as unlikely it is), which to me sounds like a terrible idea when creating a key or similar very importants secrets.

View on HN

> If this is true, then /dev/urandom might split out unsafe bits (as unlikely it is), which to me sounds like a terrible idea when creating a key or similar very importants secrets.

CSPRNGs such as /dev/urandom use the same cryptographic primitives that symmetric ciphers (such as AES, Twofish, Salsa20, ChaCha20, etc.) use. In the unlikely event that our CSPRNGs are broken (meaning /dev/urandom outputs "unsafe bits"), our symmetric ciphers will all be broken too. Therefore there is absolutely no point in insisting on using /dev/random to generate keys that will be used with symmetric ciphers.

(That's a little hand-wavy but I hope you get the general idea.)

No, the entropy estimator in /dev/random does not keep /dev/random from spitting out unsafe bits while allowing /dev/urandom to do that. A CSPRNG is akin to a stream cipher. The keystream of a stream cipher is as secure at it's 0th bit as it is at its 18446744073709551616th. An AES-CTR keystream doesn't "run out" of key, and /dev/urandom doesn't "run out" of entropy.

It's frustrating the the Linux random man page implies otherwise, because the idea is cryptographically nonsensical.

You should read the article to answer your own question in depth. The short version is: on Linux, both /dev/random and /dev/urandom are fed from the same CSPRNG. A CSPRNG only needs to be seeded with a few bits of entropy to generate a whole stream of unpredictable numbers. After the CSPRNG is seeded (at system boot) it no longer matters that you run out of entropy.

Disclaimer: I am not a cryptographer.

I have (actually, twice. Once when it was posted sometimes ago on HN, and once now before writing the comment).

What threw me off was that part: "Still, if you insist on never handing out random numbers that are not “backed” by sufficient entropy, you might be nervous here. I'm sleeping sound because I don't care about the entropy estimate."

I was missing the fact that the CSPRNG only needs to be seeded once to be safe, and reseeding is only a "nice thing" that's not really needed. To be fair, the article cover this, I guess I just didn't understand that part really well.

I've got it now, and it actually make sense. Thanks to you, and everyone else that used some time to educate me.

Randomness is not any physical entity and thus "entropy" here is just a word for data that cannot be derived from a system state. When it is not available, the attacker still has to know the seed of kernel's PRNG to be able to re-create the keys you generated in this state. To this end, she/he has to either sniff some impractically large amount of the PRNG output (and if this is possible your machine is likely already compromised), be able to set it to a given value (see above), or to know it from some prior knowledge, for instance has an image of the VM you use or knows the default value set on boot when no entropy is available whatsoever.

In other words, if the seed hasn't leaked it is easier to brute-force the key than to fit the CPRNG output that generated it.

Please explain the mechanism behind entropy depletion.

Reply on news.ycombinator.com