Blog

/dev/urandom

40 down vote accepted

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 both 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:

  • The manpage is misleading
  • Both are fed by the same CSPRNG to generate randomness (diagrams 2 and 3)
  • /dev/random blocks when it runs out of entropy
  • The amount of entropy is conservatively estimated, but not counted
  • /dev/urandom will never block, reading from /dev/random can halt processes execution.
  • In rare cases very shortly after boot, the CSPRNG may not have had enough entropy to be properly seeded and /dev/urandom may not produce high-quality randomness.
  • Entropy running low is not a problem if the CSPRNG was initially seeded properly
  • The CSPRNG is being constantly re-seeded
  • In Linux 4.8 and onward, /dev/urandom does not deplete the entropy pool (used by /dev/random) but uses the CSPRNG output from upstream.
  • Use /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:

  1. Shortly after boot on a low entropy device, if enough entropy has not yet been generated to properly seed /dev/urandom.
  2. 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 use getrandom(), but it is conceivable that a new /dev/xrandom device is created based upon getrandom().

macOS

It does’t matter, as Wikipedia says:

macOS uses 160-bit Yarrow based on SHA1. There is no difference between /dev/random and /dev/urandom; both behave identically. Apple’s iOS also uses Yarrow.

FreeBSD

It does’t matter, as Wikipedia says:

/dev/urandom is just a link to /dev/random and only blocks until properly seeded.

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:

/dev/urandom Never blocks.

/dev/random Sometimes blocks. Will block early at boot if the system’s state is known to be predictable.

Applications should read from /dev/urandom when they need randomly generated data, e.g. cryptographic keys or seeds for simulations.

Systems should be engineered to judiciously read at least once from /dev/random at boot before running any services that talk to the internet or otherwise require cryptography, in order to avoid generating keys predictably.

Leave a Reply