Randomness & Entropy

Every key, nonce, IV, salt and signature nonce in this domain assumes an unpredictable random value. That assumption is the most load-bearing and least examined part of any deployment: no cipher, key length, or protocol survives a predictable RNG, and the public record of cryptographic failure is dominated by entropy bugs rather than broken math.

Three kinds of "random", and only one is safe #

The distinguishing property of a CSPRNG is next-bit unpredictability: given all prior output, the next bit is not guessable better than 50/50. Mersenne Twister passes every statistical randomness test and fails this catastrophically — 624 consecutive 32-bit outputs fully determine its state and hence all future output. Passing Diehard or TestU01 says nothing about cryptographic fitness.

How a kernel CSPRNG actually works #

Modern kernels do not hand out "raw entropy". They collect unpredictable events, mix them into a pool, and use that pool to key a cryptographic stream generator:

flowchart LR
  HW["Hardware events<br/>IRQ timing, disk, HID"] --> POOL["Entropy pool<br/>(BLAKE2s mixer)"]
  RD["RDSEED / RDRAND"] --> POOL
  SEED["Seed file, bootloader<br/>hypervisor, device tree"] --> POOL
  POOL --> EXTRACT["Extract + rekey"] --> CS["ChaCha20 stream"] --> OUT["getrandom(2)<br/>/dev/urandom"]

Linux's 2022 rewrite replaced the old SHA-1 based, two-pool design with BLAKE2s for mixing and ChaCha20 for output, and made per-CPU generation the norm. The essential property: once the pool has been seeded with enough real entropy even once, the CSPRNG output is computationally unpredictable forever after — a well-seeded stream cipher does not "run out".

The failure that actually happens: boot-time entropy #

The dangerous window is the first seconds of a machine's life, before any unpredictable events have accumulated. A headless device with no keyboard, no mouse, no rotating disk, and a deterministic boot sequence may reach "generate the SSH host key" with a pool that is nearly identical across every unit shipped.

Related failure modes with the same shape:

• Android SecureRandom (2013) — an initialisation flaw let the PRNG repeat output, which repeated ECDSA signature nonces in Bitcoin wallets. Repeated nonces are visible on a public blockchain, so wallets were drained by anyone scanning for equal r values.
• Debian OpenSSL (CVE-2008-0166) — a removed line reduced the seed space to the process ID: 32,767 possible keys per type. Every key generated on Debian/Ubuntu for two years was enumerable; the cleanup took years.
• VM cloning and snapshots — restoring a snapshot restores the RNG state. Two clones then produce identical "random" values. Fixed by hypervisor reseeding (VMGENID on Linux, which forces an immediate reseed after a snapshot restore).
• Containers — share the host kernel's RNG, so they inherit host seeding; a container image must never ship a seed file.

Entropy the concept, briefly #

Shannon entropy measures average information content; for key material the relevant measure is min-entropy, $H_\infty = -\log_2 p_{max}$, governed by the most likely outcome. A source can have high Shannon entropy and low min-entropy — meaning it is usually unpredictable but occasionally very guessable, which is exactly what an attacker targets. NIST SP 800-90B specifies how to estimate min-entropy from a physical source and validate it.

A 128-bit key needs 128 bits of min-entropy, not 128 bits of output from something that looks random. And note the direction of the guarantee: entropy can be stretched safely by a CSPRNG, but never created. Feeding 20 bits of real entropy into any generator yields at most 20 bits of unpredictability, no matter how much output you draw.

Two further rules that fall out of everything above: never reuse a nonce or IV under the same key (see AEAD modes — for GCM it costs you the authentication key outright), and prefer deterministic constructions where the standard offers one — RFC 6979 nonces and Ed25519 both derive the per-signature secret from the key and message, removing the RNG from the signing path entirely. The most reliable way to survive a bad RNG is to not depend on it at signing time.