Myths About /dev/urandom

by
in code on (#3FC)
story imageThe 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.

Mostly handwavy nonsense himself (Score: 2, Informative)

by brendank310@pipedot.org on 2014-03-10 20:27 (#D9)

The author has a bit of a grasp on the structure of the Linux RNG, but he is missing the large scheme of things. Entropy isn't as handwavy as he makes it out to be, he just claims that it is, so handwave yourself past the blocking to the unblocking read. A guy on StackOverflow agrees too! Blocking does have it's problems, and really ought to be used as a seed for a quality generator function if you need enormous amounts of secure random data (in all likelihood you don't). The facts he lines up don't have anything to do with each other for the most part. The fact that random blocks while urandom doesn't is a performance issue, not a security issue. However, it is always good to have topic brought up every now and then (I personally enjoy it).

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.
Post Comment
Subject
Comment
Captcha
What is 2 + eight?