Linux random number generation: /dev/random vs /dev/urandom

I had a problem at work a while ago which appeared again last week where some stuff was taking ages to run through. I found a useful note which explained that the reason for this slowness is because of the encryption type that I was using and the fact that this was using /dev/random for its random number generation and it suggested instead to use /dev/./urandom. This helped resolve the problem but I had no clue why. In this post I'll explain why /dev/urandom is faster than /dev/random, but not as secure.

Firstly, open up a terminal and submit the command:

 $ cat /proc/sys/kernel/random/entropy_avail

This is the entropy that is available for the kernel at any time.  The concept behind an entropy pool is that it is a count of random bits that are assumed to be unknown to a potential attacker. New randomness is added whenever available; for example, when the user hits a key or moves a mouse.

Now, fire off the following command:

 $ hexdump /dev/random

You will probably get like 1 or 2 random numbers out of the system depending on your starting entropy and how many other things you have going on in the box. The /dev/random device works by requesting random bits from the entropy pool, once it has taken its required amount the remainder is subtracted from the estimated number of random bits remaining in the pool. If not enough unknown bits are available the process will be blocked until enough are available.

Now fire off:

 $ hexdump /dev/./urandom

The /dev/urandom device is a simple modification to /dev/random in that it doesn't perform the second check against the entropy pool which disregards estimates of input randomness. This small but significant difference results in the number produced by /dev/urandom is likely not to have as high an entropy count as a number produced by /dev/random.