The Hard Truth About Random Number Generation

Generating truly random numbers is a surprisingly complex challenge in computer science, a field built on deterministic logic. While seemingly straightforward, the quest for unpredictable numbers underpins countless critical systems, from cryptographic keys securing online transactions to fair gameplay in video games and robust scientific simulations. The inherent determinism of computers makes true randomness an elusive ideal, forcing engineers and cryptographers to devise sophisticated solutions to approximate it reliably. This article will delve into why generating randomness is so hard, explore the different types of random number generators, highlight common pitfalls, and outline best practices for developers.

The Illusion of Randomness: Pseudo-Random Number Generators (PRNGs)

At its core, a computer is a deterministic machine. Given the same input and state, it will always produce the same output. This fundamental characteristic directly conflicts with the very definition of randomness: unpredictability. Consequently, most “random numbers” generated by software are, in fact, pseudo-random.

Pseudo-Random Number Generators (PRNGs) are algorithms that produce sequences of numbers that appear random but are entirely determined by an initial value called a seed. Given the same seed, a PRNG will always produce the exact same sequence of numbers. Common PRNG algorithms include Linear Congruential Generators (LCGs) and the Mersenne Twister. The Mersenne Twister, for instance, has an enormous period (2^19937 - 1), meaning it can generate a vast sequence of numbers before repeating.

While PRNGs are fast and efficient, making them suitable for non-security-critical applications like simulations, games, or generating aesthetically pleasing patterns, their deterministic nature is a critical vulnerability for security. If an attacker can deduce the seed or observe enough of the output sequence, they can predict all future (and often past) numbers generated by the PRNG. This predictability renders them wholly unsuitable for cryptographic purposes where true unpredictability is paramount.

PRNG flowchart — Photo by Joshua Hoehne on Unsplash

Chasing True Randomness: Hardware-Based TRNGs

To escape the deterministic confines of software, we must turn to the physical world. True Random Number Generators (TRNGs), also known as Hardware Random Number Generators (HRNGs), derive their randomness from inherently unpredictable physical phenomena, often referred to as entropy sources.

These physical sources exploit microscopic or macroscopic events that are genuinely non-deterministic and cannot be replicated or predicted. Examples include:

Thermal noise: The random motion of electrons in a resistor.
Atmospheric noise: Fluctuations in radio signals.
Radioactive decay: The unpredictable timing of atomic decay events.
Quantum phenomena: Events at the quantum level are considered fundamentally random.
System events: Irregularities in user input (mouse movements, keyboard timings), disk activity, network traffic, and interrupt timings.

TRNGs offer the highest quality of randomness, making them essential for generating cryptographic keys and other highly sensitive data. However, they come with their own set of challenges. They are typically slower, more resource-intensive, and often require specialized hardware components. The process of collecting, conditioning, and digitizing these analog physical events into usable random bits can be complex and susceptible to bias if not implemented carefully.

The Best of Both Worlds: Cryptographically Secure PRNGs (CSPRNGs)

Given the speed limitations of TRNGs and the predictability risks of simple PRNGs, modern systems rely heavily on a hybrid approach: Cryptographically Secure Pseudo-Random Number Generators (CSPRNGs). These generators strike a crucial balance, combining the true randomness from entropy sources with the speed and efficiency of a deterministic algorithm.

A CSPRNG starts with a strong, high-entropy seed obtained from a TRNG or a pool of unpredictable system events. It then uses a robust, cryptographically strong algorithm to “stretch” this initial seed into a much longer sequence of pseudo-random numbers. The key distinction from a regular PRNG is that a CSPRNG is designed to resist specific cryptographic attacks. Its output should be indistinguishable from true randomness, even if an attacker knows the algorithm and has observed a significant portion of its output.

Crucially, CSPRNGs incorporate mechanisms to continuously gather new entropy from the environment and re-seed themselves. This protects against state compromise extension attacks, where even if an attacker gains knowledge of the generator’s internal state at one point, they cannot use that information to predict past outputs (backtracking resistance) or future outputs indefinitely (forward security).

Prominent examples of CSPRNGs include:

Fortuna: Designed by cryptographers Bruce Schneier and Niels Ferguson, Fortuna is built upon entropy accumulators that collect random data from various sources (user inputs, network traffic, system timings). This entropy is then used to reseed a deterministic generator, often employing a symmetric encryption algorithm like AES in counter mode. FreeBSD and Apple operating systems leverage Fortuna for their random number generation.
NIST SP 800-90A: The National Institute of Standards and Technology (NIST) provides recommendations for deterministic random bit generators (DRBGs), including Hash_DRBG, HMAC_DRBG, and CTR_DRBG, based on hash functions and block ciphers.
Operating System Provided Sources: Linux systems offer /dev/random and /dev/urandom.
- /dev/random draws directly from the kernel’s entropy pool. It blocks if the pool’s estimated entropy is insufficient, ensuring the highest quality of randomness but potentially causing delays.
- /dev/urandom (unlimited random) is generally preferred for most applications. It uses a CSPRNG seeded by the entropy pool and will not block, even if the entropy pool is low. While its output is technically “pseudo-random” if the pool is exhausted, it remains cryptographically secure for almost all practical purposes, as long as the initial seed was strong.

CSPRNG architecture — Photo by Joshua Hoehne on Unsplash

The Peril of Poor Randomness: Real-World Vulnerabilities and Best Practices

The failure to generate or properly utilize secure random numbers has led to numerous, often catastrophic, security vulnerabilities. If the randomness is predictable, the entire cryptographic system built upon it can crumble.

Historically, weak PRNGs have been exploited in various contexts:

Predictable Seeds: Early versions of Netscape Navigator’s SSL implementation used a PRNG seeded with easily guessable values, making session keys vulnerable.
Insufficient Entropy: The WEP (Wired Equivalent Privacy) protocol suffered from a design flaw that, combined with insufficient random number generation, allowed attackers to decrypt network traffic.
Repeated Nonces: In cryptographic modes like AES-GCM or ChaCha20-Poly1305, reusing a nonce (a “number used once”) due to poor randomness can compromise data confidentiality and integrity. A notable case involved nonce reuse in WPA2, leading to KRACK attacks.
Weak Key Generation: Research has shown that a significant number of RSA keys, especially on IoT and network devices, share common factors due to poor random number generation, making them susceptible to factoring and compromise. The Debian OpenSSL vulnerability, caused by a developer removing code that used uninitialized memory, severely reduced the entropy available for key generation, leading to the widespread regeneration of SSH and SSL/TLS keys.

These examples underscore that algorithms and protocols cannot compensate for bad random numbers. The quality of randomness directly affects the security of cryptographic keys, session tokens, initialization vectors, and other crucial elements.

Best Practices for Developers

For developers, the message is clear: always use cryptographically secure random number generators for security-critical applications.

Prefer OS-Provided CSPRNGs: Leverage the secure random number facilities provided by your operating system or programming language’s standard library. In Python, use the secrets module, and in Java, java.security.SecureRandom. These are typically wrappers around the operating system’s CSPRNG (e.g., /dev/urandom on Linux, BCryptGenRandom on Windows).
Ensure Sufficient Entropy: While system-provided CSPRNGs generally manage entropy collection, be aware of environments where entropy might be scarce (e.g., freshly booted virtual machines, embedded devices). Mechanisms like rngd or hardware random number generators (HRNGs) can help feed the kernel’s entropy pool.
Avoid Custom PRNGs for Security: Do not implement your own random number generator for security purposes, and avoid using general-purpose PRNGs (like Math.random() in JavaScript or rand() in C/C++) for cryptography, as they are not designed to withstand adversarial attacks.
Understand /dev/random vs. /dev/urandom: For most applications needing random data (e.g., session IDs, nonces), /dev/urandom is sufficient and preferred because it won’t block. Use /dev/random only when the highest possible entropy is strictly required and blocking is acceptable, such as for long-term cryptographic key generation, though modern kernels make /dev/urandom robust enough for nearly all use cases.

Broken padlock security vulnerability — Photo by FlyD on Unsplash

In conclusion, generating random numbers is hard because true randomness clashes with the deterministic nature of computers. While pseudo-random numbers offer speed for non-critical tasks, cryptographic security demands genuine unpredictability derived from physical entropy. CSPRNGs bridge this gap, but their effectiveness hinges on a robust entropy source and careful implementation. Understanding these nuances is not just an academic exercise; it’s a fundamental requirement for building secure and reliable software in an increasingly interconnected world.

References

Schneier, B., & Ferguson, N. (2003). Practical Cryptography. John Wiley & Sons.
National Institute of Standards and Technology (2015). SP 800-90A Rev. 1, Recommendation for Random Number Generation Using Deterministic Random Bit Generators.
Zerolynx (2025). The Achilles’ heel of cryptography: how PRNGs can ruin your security.
Krauss, A. (2017). Why Random Numbers are Impossible in Software.
Netdata (2023). Understanding Entropy: Key To Secure Cryptography & Randomness.