Why /dev/urandom Is the Right Choice for Most Cryptographic Needs

What the manuals claim

The Linux man page for the random devices says that a read from /dev/urandom will not block, and that if the entropy pool is low the values could be theoretically vulnerable. It then advises to use /dev/random when that possibility worries you. The wording sounds ominous, especially for people who have heard that “/dev/urandom is insecure”.

What the kernel actually does

Both devices feed from the same cryptographically secure pseudorandom number generator (CSPRNG). The kernel collects entropy from many sources – mouse movements, keyboard timings, network interrupts, hardware RNGs – and feeds the raw data into a hash‑based accumulator (currently ChaCha20‑based). The accumulator continuously updates an internal state that the CSPRNG uses to produce output.

• /dev/random checks the kernel’s entropy estimate before returning data. If the estimate is below the requested number of bits, the read blocks until more events arrive.
• /dev/urandom ignores the estimate and always returns data from the CSPRNG. The state is still being mixed with fresh entropy in the background, so the output remains indistinguishable from random as long as the initial seed had enough entropy.

The key point is that no separate “pure” pool exists for /dev/random; both devices draw from the same state. The only practical difference is the blocking behaviour.

How much entropy is needed?

For modern cryptographic primitives (AES‑256, SHA‑256, ECDSA, Ed25519) a 256‑bit seed provides more than enough security margin. Once the CSPRNG is seeded with that amount, each subsequent output is computationally indistinguishable from random, even if the kernel’s entropy estimate later drops. In practice the kernel gathers far more than 256 bits during a normal boot, especially on systems with hardware RNGs (e.g., Intel RDRAND, AMD RDSEED).

Why blocking hurts more than it helps

When /dev/random blocks, services that need fresh keys can stall. Common symptoms:

• PGP key generation hanging inside a virtual machine.
• TLS handshakes timing out because the server waits for entropy.
• Container orchestration tools failing to start because they cannot read enough bytes.

Administrators often work around the problem by:

• Disabling the block with rngd or haveged.
• Patching applications to call /dev/urandom instead.
• Adding artificial delays that merely waste time.

These hacks reduce availability without improving security; the CSPRNG already provides strong guarantees after the initial seed.

What about the “theoretical attack” mentioned in the man page?

The warning refers to a cryptanalytic attack that would recover the internal state of the kernel’s CSPRNG given only its output and knowledge of the entropy estimate. No such attack is known in the public literature, and the underlying primitives (ChaCha20, SHA‑256, etc.) have withstood extensive analysis. The wording reflects a conservative stance rather than a concrete threat.

When does /dev/urandom actually become a problem?

Two edge cases merit attention:

1. Early boot before the first reseed. On a freshly powered‑on system without a saved seed, the kernel may output data before it has collected enough entropy. Modern distributions mitigate this by persisting a seed file (e.g., /var/lib/systemd/random-seed) across reboots. The first few kilobytes may have slightly lower entropy, but they are rarely used for long‑term keys.
2. Cloned virtual machines. If a VM image is duplicated, the saved seed file is copied verbatim, causing identical CSPRNG state in each instance. The proper fix is to delete the seed file after cloning and let the VM gather fresh entropy, or to inject new entropy via rngd or a cloud‑provided hardware RNG.

Both scenarios are manageable with standard operational practices and do not require a switch to /dev/random.

Re‑seeding: why it matters and why it does not imply blocking

The kernel mixes new entropy into the CSPRNG continuously. This re‑seeding serves two purposes:

• It improves the statistical quality of the internal state, keeping it far from any attacker‑controlled guess.
• It provides a self‑healing property: even if an attacker ever learned the state, later entropy injections make future outputs unpredictable again.

Re‑seeding happens in the background and does not affect the non‑blocking behaviour of /dev/urandom.

Practical recommendations

• Use /dev/urandom for all cryptographic material – session keys, nonces, salts, TLS private keys, SSH host keys, etc.
• Reserve /dev/random only for generating long‑lived keys (e.g., a master GPG key) on a system that has already gathered sufficient entropy.
• Ensure a reliable seed source: enable systemd‑random‑seed.service, use a hardware RNG, or run rngd on headless servers.
• When cloning VMs, delete the saved seed and let the new instance collect fresh entropy before generating any keys.

Bottom line

The myth that /dev/urandom is insecure stems from a misunderstanding of how the Linux RNG works. Both devices share the same CSPRNG; the only real difference is whether the read blocks. With a proper initial seed and continuous entropy injection, /dev/urandom provides cryptographically strong randomness for virtually every practical use case. Blocking for “true” randomness rarely adds security but often harms availability. In short, use /dev/urandom and reserve /dev/random for the few cases where you explicitly need to wait for extra entropy.

---

Further reading

• Linux kernel random number generator design: https://www.kernel.org/doc/html/latest/security/rng.html
• systemd‑random‑seed.service documentation: https://www.freedesktop.org/software/systemd/man/systemd-random-seed.service.html
• Daniel J. Bernstein’s commentary on /dev/random vs /dev/urandom: https://cr.yp.to/docs/rand.html
• Thomas Pornin’s StackExchange answer on entropy estimates: https://crypto.stackexchange.com/a/12345