Random number generation: the primitive everything else depends on

Before asking whether a source is random enough for cryptography, it helps to have a precise way to measure "how random." Claude Shannon (the same Shannon behind the one-time pad's perfect-secrecy proof, covered in the history module) defined entropy as the quantity of unpredictability, or "surprise," in a source, measured in bits: for a source where outcome i happens with probability pᵢ, entropy is H = −Σ pᵢ·log₂(pᵢ). A fair coin flip carries exactly 1 bit of entropy. A biased coin that lands heads 99% of the time carries far less — it's still technically random, but far more predictable, and its entropy reflects that directly.

Cryptography almost always deals with the simpler special case: every one of N possible outcomes equally likely. There, the general formula collapses to a single logarithm: H = log₂(N) bits. This is exactly the same "bits of security" language used throughout this catalog — a 128-bit AES key drawn uniformly at random has 128 bits of entropy, precisely because its keyspace has 2¹²⁸ equally likely values, no more and no less.

Worked example: an 8-character password drawn uniformly from the 26 lowercase letters has a keyspace of 26⁸ ≈ 208 billion possibilities. Its entropy is log₂(26⁸) = 8 × log₂(26) ≈ 8 × 4.70 ≈ 37.6 bits — low enough that modern hardware can exhaust it in a practical amount of time, despite the password "looking" reasonably long to a human reader.

A cryptographically secure pseudorandom number generator (CSPRNG) must satisfy a stronger property than statistical randomness: even seeing part of its output must give an attacker no useful ability to predict the rest, or to reconstruct its internal state. An ordinary PRNG used for simulations or games (like the Mersenne Twister) is often statistically excellent but trivially predictable once enough output is observed — it must never be used for keys, nonces, or IVs.

Operating systems gather unpredictability (entropy) from physical sources — hardware interrupt timing, disk I/O timing, dedicated hardware RNGs on modern CPUs — and feed it into a CSPRNG exposed through an OS API: /dev/urandom on Linux and macOS, CryptGenRandom/BCryptGenRandom on Windows. Application code should always call these platform APIs rather than implementing its own randomness.

In 2008, a patch to Debian's OpenSSL package accidentally removed nearly all sources of entropy from its key generation, causing it to produce keys from a pool of only about 32,768 possibilities for over a year before discovery — every key generated on an affected system was practically guessable. The 2010 Sony PlayStation 3 incident (referenced in the ECC module) was a related but distinct failure: not weak entropy, but reuse of the exact same "random" nonce for every ECDSA signature, which directly exposed the signing private key through simple algebra.

That "32,768 possibilities" figure is worth converting into the unit this catalog uses everywhere else — bits of entropy — to see just how far the Debian bug fell from a real key size.