When to use /dev/random over /dev/urandom in Linux 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?
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:


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.)
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.)