Myths About /dev/urandom
The differences between /dev/random and /dev/urandom have spawned some misconceptions. This article attempts to explain some of the myths surrounding this perplexing random number device.
Also of interest, is a report on weak entropy in key generation, especially during bootup, and another report on the aftermath of Debian's recent OpenSSL vulnerability.
Also of interest, is a report on weak entropy in key generation, especially during bootup, and another report on the aftermath of Debian's recent OpenSSL vulnerability.
Estimating the amount of entropy in a given pool is difficult, Bruce Schneir says that is the real difficulty in creating a CSPRNG. Some designs don't rely on pools (see Schneir's Yarrow). In reality the issue is going to become more and more moot, as hardware instructions are available for latter processors to produce fast streams of random numbers that are adequate for reseeding a CSPRNG quite often, or use the output by itself. Intel's project was called Blue Mountain, and the instruction is available on post-Sandy Bridge architectures (It's non-priveleged, assembly x86 instruction rdrand). I think it would be an interesting patch to allow that to be used within the kernel RNG. It relies on instability of (semi-)digital circuits to create random bits at the speed of the clock. Some people may yell it's NSA backdoored, but using it with dabs of your input, disk and network entropy is better than anything we currently have.
Is using /dev/urandom probably good enough? Yeah probably, but I don't see using /dev/random as such a huge issue in the first place. Want the best of both worlds? Read from /dev/random and write it into /dev/urandom, then do reads from urandom. Don't rely on this guys blog post, because even his improved diagram of the Linux RNG is incorrect. He knows enough to be dangerous, not enough to know that he's dangerous.