Random Number Generation in Cryptography

Core Idea

Cryptographic security depends critically on high-quality randomness for key generation, nonces, IVs, and padding. A cryptographically secure pseudorandom number generator (CSPRNG) expands a short truly random seed into a long pseudorandom stream that is computationally indistinguishable from true randomness. Entropy — genuine physical unpredictability — must be harvested from hardware sources (timing jitter, thermal noise, etc.) and cannot be created algorithmically. Weak or predictable randomness has caused catastrophic real-world failures: the Debian OpenSSL bug (2008) reduced key entropy to 15 bits, and Dual_EC_DRBG contained an NSA backdoor. Using the OS-provided CSPRNG (/dev/urandom, CryptGenRandom) is the correct practice.

Explainer

Every cryptographic operation that generates keys, nonces, IVs, or random padding depends on a source of randomness that an adversary cannot predict. If an attacker can predict or narrow down the random values used in key generation, they can break the system regardless of how strong the algorithms are. Entropy — genuine physical unpredictability — is the foundation of cryptographic randomness, and it cannot be manufactured by computation. A deterministic algorithm, no matter how complex, produces a predictable output from a predictable input. Randomness must ultimately come from physical processes: hardware timing jitter, thermal noise, radioactive decay, or user input timing.

A cryptographically secure pseudorandom number generator (CSPRNG) bridges the gap between the small amount of entropy available from hardware sources and the large amount of randomness that cryptographic operations consume. It takes a short truly random seed (128-256 bits of entropy) and expands it into an arbitrarily long stream that is computationally indistinguishable from true randomness — no polynomial-time algorithm can tell the CSPRNG's output from a truly random string. Modern CSPRNGs (like ChaCha20-based designs in Linux) also provide forward secrecy: even if the internal state is compromised at some point, past outputs remain unpredictable, and the generator recovers security as new entropy is mixed in.

The critical principle is that a CSPRNG cannot create entropy; it can only expand it. If the seed has 30 bits of entropy (e.g., seeded with a timestamp), the output has 30 bits of entropy — the CSPRNG merely obscures which 30-bit value was used. Real-world catastrophes confirm this. The Debian OpenSSL bug (2006-2008) accidentally reduced entropy to the process ID (~15 bits), making every key generated on affected systems guessable from a set of ~32,768 possibilities. A developer who seeds a PRNG with time.time() provides perhaps 25-30 bits of entropy to an attacker who can estimate when the key was generated. These failures are invisible: the output looks random, passes statistical tests, and appears to work perfectly — until an attacker exploits the predictability.

The correct practice is simple: use your operating system's CSPRNG. On Linux, /dev/urandom (or the getrandom() system call) provides a CSPRNG seeded from hardware entropy sources, continuously reseeded, and maintained by security experts. On Windows, BCryptGenRandom serves the same role. These implementations handle entropy collection, pool management, and reseeding automatically. Rolling your own is almost always wrong — the Dual_EC_DRBG scandal (a NIST-standardized PRNG with a probable NSA backdoor exploiting the relationship between two elliptic curve points) showed that even standards bodies can get it wrong, but OS implementations receive the most scrutiny and the fastest patches. For application developers, the rule is absolute: never implement your own random number generation for cryptographic purposes.