* https://news.ycombinator.com/item?id=7359992

Also:

2020: https://news.ycombinator.com/item?id=22683627

2018: https://news.ycombinator.com/item?id=17779657

2017: https://news.ycombinator.com/item?id=13332741

2015: https://news.ycombinator.com/item?id=10149019

Having a good entropy source makes mathematical sense, and you want something a bit more "random" than a dice roll, but I wonder at which point it becomes security theatre.

Of all the possible avenues for exploiting a modern OS might have, I figure kernel PRNG prediction to be very, very far down the list of things to try.

A CSPRNG is just an algorithm that uses some entropy as a key and feeds back on itself to generate a stream of random bytes. It is a way of expanding a small bit of entropy into a much larger sequence of random values.

From that you can derive the underlying objection here: estimating entropy, blocking /dev/random, and all the other noise is equivalent to saying "cryptography doesn't work". It is both wrong and pointless.

The only place it matters is at boot when there is no hardware source of randomness _which excludes pretty much all PCs which have hardware generators_. You need a true random key to start the CSPRNG but that's it. If you don't have a hardware unit you use time of arrival of the next network packet. Or the frequency of keystrokes on the keyboard.

Now you might ask: why bother seeing the entropy pool at all? The answer is Perfect Forward Secrecy. By mixing in new randomness you are effectively slowly swapping out the key used for the encrypted stream. Thus even if someone is able to compromise something based on guessing the random number sequence your CSPRNG generated their guesses will get more and more wrong as new entropy enters the pool eventually becoming useless. This is a defense-in-depth policy though, not a practical attack mechanism.

On linux it is unfortunate that /dev/urandom has the property of silently vending non-random bytes on hardware without an RNG just after boot and that /dev/random was designed to block when the magical fairies say so but of the two failure modes /dev/urandom is the least bad because practically most hardware (even embedded hardware these days) simply can't encounter its failure mode.

I couldn’t find any good way to debug it and a friend suggested GDB. I had never thought of using such a low level debugger on a scripting language, but what choice did I have? Fired it up, found a blocked process and sure enough it was blocked on reads to /dev/random.

I leaned two things that day: the decision to make and keep /dev/random blocking was dumb and GDB (or lldb, or valgrind, etc.) is useful for debugging just about anything.

Were the man page musings written in response to the (alleged, but... uh... NSA) kleptographic backdoor in Dual_EC_DRBG? It requires multiple successive outputs to compromise and derive internal PRNG state, if memory serves.

In that one construction, /dev/random blocking on seeding would have a mild state-hiding advantage over /dev/urandom, I imagine... but, sheesh. Nobody use that generator.

Edit: can't count.