Entropy is fed into /dev/random
at a rather slow rate, so if you use any program that uses /dev/random
, it's pretty common for the entropy to be low.
Even if you believe in Linux's definition of entropy, low entropy isn't a security problem. /dev/random
blocks until it's satisfied that it has enough entropy. With low entropy, you'll get applications sitting around waiting for you to wiggle the mouse, but not a loss of randomness.
In fact Linux's definition of entropy is flawed: it's an extremely conservative definition which strives to achieve a theoretical level of randomness that's useless in practice. In fact, entropy does not wear out — once you have enough, you have enough. Unfortunately, Linux only has two interfaces to get random numbers: /dev/random
, which blocks when it shouldn't, and /dev/urandom
, which never blocks. Fortunately, in practice, /dev/urandom
is almost always correct, because a system quickly gathers enough entropy, after which point /dev/urandom
is ok forever (including uses such as generating cryptographic keys).
The only time when /dev/urandom
is problematic is when a system doesn't have enough entropy yet, for example on the first boot of a fresh installation, after booting a live CD, or after cloning a virtual machine. In such situations, wait until /proc/sys/kernel/random/entropy_avail
reaches 200 or so. After that, you can use /dev/urandom
as much as you like.
Best Answer
TL;DR
Use
/dev/urandom
for most practical purposes.The longer answer depends on the flavour of Unix that you're running.
Linux
Historically,
/dev/random
and/dev/urandom
were introduced at the same time.As @DavidSchwartz pointed out in a comment, using
/dev/urandom
is preferred in the vast majority of cases. He and others also provided a link to the excellent Myths about/dev/urandom
article which I recommend for further reading.In summary:
/dev/random
blocks when it runs out of entropy, so reading from/dev/random
can halt process execution./dev/urandom
will never block./dev/urandom
may not produce high-quality randomness./dev/urandom
does not deplete the entropy pool (used by/dev/random
) but uses the CSPRNG output from upstream./dev/urandom
.Exceptions to the rule
In the Cryptography Stack Exchange's When to use
/dev/random
over/dev/urandom
in Linux @otus gives two use cases:Shortly after boot on a low entropy device, if enough entropy has not yet been generated to properly seed
/dev/urandom
.Generating a one-time pad with information theoretic security
If you're worried about (1), you can check the entropy available in
/dev/random
.If you're doing (2) you'll know it already :)
Note: You can check if reading from /dev/random will block, but beware of possible race conditions.
Alternative: use neither!
@otus also pointed out that the
getrandom()
system will read from/dev/urandom
and only block if the initial seed entropy is unavailable.There are issues with changing
/dev/urandom
to usegetrandom()
, but it is conceivable that a new/dev/xrandom
device is created based upongetrandom()
.macOS
It doesn't matter, as Wikipedia says:
FreeBSD
It doesn't matter, as Wikipedia says:
This means that after boot, FreeBSD is smart enough to wait until enough seed entropy has been gathered before delivering a never-ending stream of random goodness.
NetBSD
Use
/dev/urandom
, assuming your system has read at least once from/dev/random
to ensure proper initial seeding.The rnd(4) manpage says: