When to use /dev/random over /dev/urandom in Linux

Question

In my response to my question "what does the letter 'u' mean in /dev/urandom?" the myths about /dev/urandom page was posted in two comments and an answer.

The myths about /dev/urandom page is trying to steer people heavily into using /dev/urandom over dev/random.

This guy knows more than I do, so it would be easy for me to nod and accept, but I'd like to post it here so that other people who also know more than I do could comment.

What irks me about myths about /dev/urandom is that:

• The two devices still have a differing behaviour depending on the size of the entropy pool
• There are no use cases given where /dev/random is the better choice (which seems unbalanced)

I note that cryptsetup has an option --use-random:

NOTES ON RANDOM NUMBER GENERATORS

Using /dev/random on a system without enough entropy sources can cause luksFormat to block until the requested amount of random data is gathered. In a low-entropy situation (embedded system), this can take a very long time and potentially forever. At the same time, using /dev/urandom in a low-entropy situation will produce low-quality keys. This is a serious problem, but solving it is out of scope for a mere man-page. See urandom(4) for more information.

So my question is:

In which practical situations would one want to use /dev/random in preference to /dev/urandom, and why?

Answer 1

In which practical situations would one want to use /dev/random in preference to /dev/urandom, and why?

Basically none on a typical desktop or server system. Assuming the PRNG produces cryptographically secure random numbers, there is no reason to use /dev/random instead.

There are a couple of corner cases, however:

1. You use the random numbers for a one-time pad. In that case if you wanted information theoretic security you should not use pseudorandom numbers. (No real reason to do that in my opinion.)

2. Early boot on a very low entropy device. The /dev/urandom device cannot guarantee that it has received enough initial entropy, while when using /dev/random that is guaranteed (even if it may block). However, in this case you could use the newer getrandom interface (man page) instead.

Running cryptsetup on first boot of an embedded device is the kind of thing where you would need to consider your options. (Modern desktop and server CPUs tend to include hardware random number generators which are used to seed /dev/urandom.)

There is some work underway to make /dev/urandom block when initial entropy is insufficient, but it may not be possible due to programs which assume it will never block. (See e.g. this LKML thread.)

Answer 2

Assuming enough entropy was collected to seed the pseudo-random number generator, there is no reason to use the potentially blocking /dev/random. In general, a well studied PRNG (/dev/urandom), that is seeded properly should be the way to go.

Answer 3

They both produce the same pseudo random numbers based on a repetitive SHA1 hashing of a small quasi-entropy pool.

There is a clear use case for one over the other. The number of numbers it produces. /dev/random is very very slow. I've timed it producing random numbers in the order of <0.1 bytes /sec. That means that after consuming the initial 128 (or so) available bytes, it effectively stops. The only effective way to increase the generation rate is to do the typing monkey thing and hammer away at the key board. On a server, you're stuffed.

Consequently, unless you have access to an external hardware entropy source, you can't really use /dev/random for anything productive. You can't even use it realistically for generating one time pads for anything longer than a single sentence. Thus you're left with /dev/urandom where I guess the "u" stands for unlimited.

So the answer is that there is no practical use for /dev/random. If you want to see this for yourself, type

cat /dev/random | hexdump

and watch it do nothing much at all...