← All modules
Foundations·10 min

Random number generation: the primitive everything else depends on

Every key, nonce, and IV in this catalog assumes truly unpredictable randomness. When that assumption breaks, everything built on top breaks with it.

Developer / EngineerSecurity ArchitectIT Ops / DevOpsResearcher / Academic

CSPRNGs vs. ordinary randomness

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.

Ordinary PRNG (e.g. Mersenne Twister)

  • Excellent statistical distribution — passes randomness test suites
  • Deterministic from its seed — no unpredictability requirement
  • Observing enough output can let an attacker reconstruct the internal state and predict all future output
  • Fine for simulations and games; unsafe for keys, nonces, or IVs

CSPRNG

  • Seeded from real hardware/OS entropy sources
  • Output must be unpredictable even to an attacker who sees part of it
  • Designed so recovering internal state from output is computationally infeasible
  • Required for every key, nonce, and IV in this catalog

Where entropy actually comes from

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.

When it goes wrong: real incidents

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.

Knowledge check

Test what you just learned →

3 quick questions, with an explanation for every answer.

Up next

Side-channel & timing attacks: when the math is fine but the implementation isn't

A cryptographic algorithm can be mathematically unbreakable and still leak its secret key through how long it takes to run.