Debunking the Myths of /dev/urandom and /dev/random

For years, a persistent narrative has circulated among developers and system administrators: "/dev/urandom is insecure; always use /dev/random for cryptographic purposes." This advice is often repeated in forums, old tutorials, and even vaguely implied in system man pages. The core of the fear is "entropy exhaustion"—the idea that the system can "run out" of randomness, leaving your encryption keys vulnerable.

In reality, this intuition is fundamentally wrong. For the vast majority of cryptographic applications on UNIX-like systems, /dev/urandom is not only secure but is the preferred choice. Understanding why requires a dive into how the Linux kernel actually handles randomness and the difference between information-theoretic and computational security.

The Core Misconception: "True" vs. "Pseudo" Randomness

Many believe that /dev/random provides "true" randomness harvested directly from hardware noise, while /dev/urandom is a pseudo-random number generator (PRNG) that fills in the gaps when the "true" entropy runs low.

This is a myth. In reality, both /dev/random and /dev/urandom utilize the same Cryptographically Secure Pseudorandom Number Generator (CSPRNG). The primary difference is not the quality of the numbers they produce, but their behavior when the kernel's entropy estimate is low.

Computational Security vs. Information-Theoretic Security

To understand why a CSPRNG is sufficient, we must distinguish between two types of security:

1. Information-Theoretic Security: This is the gold standard where a system is secure regardless of the attacker's computational power (e.g., a One-Time Pad). This requires a truly random key as long as the message itself.
2. Computational Security: This is what almost all modern cryptography (AES, RSA, Elliptic Curve) relies on. These algorithms are secure because it would take an astronomical amount of time—longer than the age of the universe—for a computer to brute-force the keys.

Since we are using computationally secure algorithms for our encryption, using a computationally secure source of randomness (a CSPRNG) is perfectly appropriate. If an attacker could predict the output of a CSPRNG, they could likely break the underlying block ciphers or hash functions that the rest of your security infrastructure depends on anyway.

How the Linux Randomness Architecture Works

The Pre-Linux 4.8 Era

Before version 4.8, the kernel mixed entropy from various sources (like keyboard timings and disk interrupts) into a pool. This pool seeded a CSPRNG.

• /dev/urandom would pull from the CSPRNG and never block.
• /dev/random would pull from the same CSPRNG but would block if the kernel's internal entropy estimate fell below a certain threshold.

Crucially, the entropy "count" is just an estimate. It is not a precise measurement of available randomness. Blocking based on an estimate provides no actual security benefit but introduces significant availability risks.

Linux 4.8 and Beyond

In Linux 4.8, the distinction was further refined. /dev/urandom now pulls directly from the CSPRNG. The fundamental principle remains: once the CSPRNG is seeded with enough initial entropy (typically 256 bits), it can produce a virtually endless stream of cryptographically secure bytes.

The Danger of Blocking

Choosing /dev/random because it blocks can actually decrease your system's security. When a system blocks waiting for entropy, it creates a denial-of-service condition. In production environments, this leads to:

• Application Hangs: Web servers may stop responding while waiting to generate ephemeral session keys.
• Dangerous Workarounds: Frustrated administrators may disable SSL/TLS, patch out calls to random(), or use insecure ioctl calls to artificially inflate the entropy counter just to get the system running.

By choosing /dev/urandom, you maintain system availability without sacrificing cryptographic strength.

Addressing Common Counter-Arguments

"But the man page says..."

The man pages for /dev/random and /dev/urandom are notoriously ambiguous, often suggesting that /dev/urandom is "theoretically vulnerable" to attack. However, as noted by experts in the field, these theoretical attacks are not known in unclassified literature and are no more practical than an attack on AES itself.

"What about re-seeding?"

Systems constantly inject new entropy into the CSPRNG. This isn't because the generator "runs out" of randomness, but to provide Perfect Forward Secrecy. If an attacker were to somehow compromise the internal state of the generator, the continuous injection of new entropy ensures the state eventually becomes random again, "healing" the generator over time.

The One Real Weakness: The Boot Process

There is one scenario where /dev/urandom can be problematic: immediately after boot. If the kernel hasn't gathered enough entropy to seed the CSPRNG for the first time, the output may be predictable.

Linux mitigates this by saving a seed file during shutdown and loading it at boot. However, this can be a challenge for virtual machines (VMs), where cloned images or restored checkpoints can lead to multiple VMs starting with the same seed. The solution here is not to switch to /dev/random, but to ensure that each VM is properly seeded upon cloning or restoration.

Final Verdict

As cryptographer Daniel Bernstein (djb) pointed out, the idea that we can use a single key to encrypt many messages (SSL/PGP) but cannot deterministically expand a 256-bit seed into a stream of unpredictable keys is a contradiction.

"For a cryptographer this doesn’t even pass the laugh test."

The bottom line: Just use /dev/urandom.