Parag Mali - tag: csprng

Predictable or Repeated: The Only Two Ways Cryptographic Randomness Betrays You

noreply@paragmali.com (Parag Mali) — Wed, 08 Jul 2026 03:29:38 GMT

Every cryptographic key, nonce, IV, and salt is only as safe as two invisible properties: was it *unpredictable* when it had to be, and *unique* when it had to be? A cryptographically secure pseudorandom number generator (CSPRNG) manufactures unpredictability by stretching a little true entropy into unlimited output, and fails when the seed is guessable, the state cloned, the design back-doored, or the draw biased. But that is only half the story: the four roles each demand a different mix of unique, unpredictable, and secret, so a perfect generator still gets you owned if you reuse a GCM nonce or predict a CBC IV. A field guide to both halves, through every famous break.

1. Two Lines of Code

In 1996, two Berkeley graduate students needed only seconds to reconstruct the secret keys protecting Netscape's SSL. The RC4 and RSA math was flawless. The browser had simply seeded its random number generator from the time of day and a couple of process IDs, and there were only so many of those [@src-netscape1996]. In 2008, a one-line change to Debian's OpenSSL quietly collapsed the space of every key it generated, for SSH, SSL, and OpenVPN, down to about 32,768 possibilities, small enough to enumerate on a laptop over lunch [@src-debian2008].

In both cases the cipher was flawless and the keys were guessable. That is the whole problem with cryptographic randomness: it is the one primitive whose failures are invisible, and there are only two of them.

Look closely at Netscape first. Ian Goldberg and David Wagner reverse-engineered the Navigator's seeding code and found that the entire unpredictable input to the session key came from the current time, the process ID, and the parent process ID [@src-netscape1996]. An attacker who knew roughly when you connected, and process IDs live in a small range, could reproduce the seed and therefore the key. The seed was the secret, and the secret was enumerable. Nothing about RC4 or RSA had to break; the attacker simply recomputed what the generator would produce.

Debian, twelve years later, is the same mistake wearing a different costume. A developer commented out a line in OpenSSL that fed unpredictable data into the seed, silencing a memory-analysis warning about reading uninitialized bytes.The specific tool that flagged the warning is often reported as Valgrind, sometimes as Purify; the Debian advisory itself names neither, so we will not assert one. The load-bearing fact is the collapsed keyspace, which is not in dispute [@src-debian2008]. With that input gone, the only entropy left was the process ID, so the effective keyspace for roughly two years of Debian-generated keys shrank to about $2^{15}$ values, and CVE-2008-0166 was born [@src-debian2008, @src-cve2008]. Every SSH host key, TLS certificate, and OpenVPN key produced on an affected system could be pre-computed and looked up in a table.

A deterministic algorithm that stretches a short, truly-random *seed* into an arbitrarily long output stream that no efficient adversary can distinguish from uniform random bits, even after observing part of the stream. The word *cryptographically* is what separates it from an ordinary statistical PRNG: the guarantee is about unpredictability to a computationally bounded attacker, not merely about passing statistical tests.

Neither of these was a broken algorithm. Both were broken randomness, and the reason they feel like the same story is that they are the same story. A weak or misused random value emits bytes that look perfect, pass every statistical test, and are catastrophically broken anyway. The generator hums along; the ciphertext validates; the signature verifies. The failure is silent until someone else computes what you computed.

Note: A broken cipher raises an error. A bad MAC rejects. A weak or reused random value does neither: it produces output that is statistically indistinguishable from good randomness and passes every test you can run against it, while being fully predictable or fatally repeated to an attacker who knows where to look. You cannot detect the failure by inspecting the output. This is why randomness bugs survive code review, ship to production, and are found years later by the people exploiting them.

Once you have seen these two breaks side by side, the organizing claim of this article is hard to unsee. A random value can betray you in exactly one of two ways, and the failure can happen in exactly one of two places.

Key idea: There are only two ways a random value fails: it is predictable when it needed to be unpredictable, or repeated when it needed to be unique. And each failure happens in exactly one of two places: the generator that manufactures the bits, or the role that consumes them (key, nonce, IV, salt). Two knobs, two places. Every famous break in this article is a single knob turned the wrong way in a single place.

This is Part 2 of a field guide for protocol designers. Part 1 argued that the standard security definition, IND-CPA, mandates randomized encryption: a scheme that encrypts the same message the same way twice cannot hide whether two ciphertexts carry the same plaintext, so a nonce or IV is the randomness the definition demands. This part supplies, and disciplines, that randomness. By the end you should be able to look at any randomness bug, Netscape or Debian or the ones still shipping today, and name on sight which knob turned and which place failed.

Both breaks were the generator half failing on the predictability knob. To see why that failure was almost inevitable, we have to go back to the moment cryptography decided to put all of its secrecy into a string of unguessable bits.

2. Why Randomness Became a Primitive

In 1883, Auguste Kerckhoffs told cryptographers something that sounds obvious now and was radical then: assume the enemy knows your algorithm [@src-kerckhoffs1883]. Do not build your security on the secrecy of the machine, because the machine will be captured, reverse-engineered, or sold. Build it on the key. That single move relocated all of a system's secrecy into one place, a string of bits, and quietly made the unpredictability of that string the foundation of everything, without ever saying where the string should come from.

Sixty-six years later, Claude Shannon made the requirement mathematical. In Communication Theory of Secrecy Systems (1949), he proved that the one-time pad achieves perfect secrecy: a ciphertext reveals nothing whatsoever about the plaintext, not even to an adversary with unlimited computing power [@src-shannon1949].

But the proof comes with a receipt. Perfect secrecy demands a key that is perfectly random and at least as long as the message, used once. Randomness stopped being a nice-to-have and became a first-class, provable requirement, the raw material perfect secrecy is quite literally made of. Hold onto the price tag on that key; it comes back in Section 8 as the gap no engineering closes.

*Entropy* measures how much true unpredictability a source contains. For cryptography the conservative measure is *min-entropy*, defined for a distribution $X$ as $H_\infty(X) = -\log_2 \max_x \Pr[X = x]$. It is governed by the single most likely outcome, that is, by the attacker's best single guess. A source with $n$ bits of min-entropy resists guessing about as well as $n$ uniformly random bits. This worst-case framing is deliberate: an average-case measure like Shannon entropy can look healthy while one dominant value makes the source easy to guess.

But where do perfectly random bits come from? In 1951 John von Neumann issued the warning that still hangs over the whole field. Studying ways to generate random digits on the first computers, he tried the middle-square method, squaring a number and taking the middle digits as the next value, and watched it collapse into short repeating cycles or fall to zero. His verdict was characteristically sharp.

"Any one who considers arithmetical methods of producing random digits is, of course, in a state of sin." -- John von Neumann, 1951 [@src-vonneumann1951]

The point was not that deterministic recipes are useless, but that arithmetic alone only simulates randomness; it cannot manufacture the genuine article [@src-vonneumann1951]. A formula has no unpredictability of its own. Whatever you get out was already determined by what you put in.

So for a while, randomness was treated as a scarce physical resource you harvested and rationed. In 1955 the RAND Corporation published A Million Random Digits with 100,000 Normal Deviates, an entire book whose content was a table of random numbers generated from electronic noise, sold so that scientists could look up randomness the way they looked up logarithms [@src-rand1955].Two years later the UK built ERNIE (Electronic Random Number Indicator Equipment) to draw Premium Bond winners from thermal noise. It is a lovely piece of history, but no contemporaneous engineering primary survives that we could verify, so treat it as color, not evidence [@src-ernie1957]. Randomness you could buy in a bookstore is a charming idea and a useless one for cryptography, because a published table is, by definition, known to your adversary, and it cannot produce a fresh, secret, per-session value on demand.

Von Neumann's ban is on arithmetic *manufacturing* randomness from nothing. It says nothing against *extracting* clean randomness from a messy physical source that already contains some, which is exactly what a modern entropy source does, and what a [fuzzy extractor](/blog/fuzzy-extractors-windows-hello/) does when it turns a noisy biometric into a stable key. Extraction concentrates existing unpredictability; it never conjures it. Garbage in, garbage out remains the law.

The conceptual breakthrough that made a deterministic generator respectable arrived in the early 1980s. Andrew Yao (1982) and Manuel Blum with Silvio Micali (1984) redefined what "random enough" should mean for cryptography [@src-yao1982, @src-blummicali1984]. Their answer was not statistical but computational: a sequence is cryptographically strong if no efficient algorithm, given all the output bits so far, can predict the next bit with probability meaningfully better than one-half.

A pseudorandom generator passes the *next-bit test* if no probabilistic polynomial-time algorithm, shown any prefix of the output sequence, can guess the following bit with advantage non-negligibly above $1/2$. Yao proved this test is equivalent to indistinguishability from uniform: pass the next-bit test and you pass *every* efficient statistical test at once [@src-yao1982, @src-blummicali1984, @src-katzlindell]. This is unpredictability made rigorous, and it is a yardstick no finite battery of statistical tests can ever meet.

This is knob number one, unpredictability, turned into a precise definition. Notice what it does not promise: it says nothing about where the seed comes from, and it holds only against a bounded adversary. Both caveats will return to bite. But the intellectual foundation was now in place. Shannon and Kerckhoffs had made unguessable bits the foundation of everything; von Neumann had warned that no formula can produce them from thin air. So engineers reached for the nearest deterministic recipe that merely looked random, and walked straight into the first disaster.

3. Statistical Randomness That Was Not Unpredictable

Here is a fact that should bother you. The Mersenne Twister, the default random generator in Python, Ruby, PHP, R, MATLAB, and countless other systems [@src-python-random], passes essentially every statistical randomness test ever devised. Its output is beautifully uniform, its period is astronomically long, and it is completely predictable. Observe 624 of its 32-bit outputs and you can reconstruct its entire internal state and compute every value it will ever emit, forward and backward [@src-mersenne1998]. That gap, between "looks random" and "is unguessable," is the mistake that organizes the rest of this article.

Start with the simplest offender. A linear congruential generator (LCG) produces its next value with $x_{n+1} = (a \cdot x_n + c) \bmod m$. It is fast, it is fine for shuffling a deck in a video game, and it is fatal for cryptography, because given a handful of outputs you can solve for the hidden constants and then predict everything. There is no unpredictability here at all, only arithmetic dressed up to look busy.

The Mersenne Twister (MT19937, 1998) is vastly more sophisticated, with 19,937 bits of state and excellent equidistribution, but it shares the same fatal property: it is linear over the field $\mathbb{F}_2$ [@src-mersenne1998]. Every output bit is a fixed linear function of the state bits. Collect enough outputs and you have a system of linear equations whose solution is the state. Sophistication did not buy unpredictability, because unpredictability was never what the design optimized for.

A *statistical PRNG* is built to produce output with good distributional properties: uniformity, long period, no detectable correlations. A *cryptographically secure* generator is built to a strictly harder standard: no efficient adversary who has seen past output can predict future output, the next-bit test of Section 2. The two goals are independent. The Mersenne Twister maximizes the first and fails the second completely. Passing statistical batteries is necessary but nowhere near sufficient for cryptography.

The first genuinely cryptographic generators came from the banking world. The ANSI X9.17 and later X9.31 designs used a block cipher (two-key Triple-DES in X9.17; Triple-DES or AES in X9.31) rather than a linear recurrence [@src-hac, @src-ansix931], so predicting the output required breaking the cipher itself, not solving a linear system. This was real progress.

But it moved the whole burden onto a single secret: the seed key $K$ baked into the construction. If $K$ leaks, or worse, if it is hard-coded into shipped firmware, the generator becomes fully predictable to anyone who reads the binary. That is not a hypothetical. It is exactly the DUHK attack we will meet in Section 4, where hard-coded X9.31 keys let researchers decrypt live VPN traffic [@src-duhk2018].

And then there is the naive-seeding family, the Netscape lineage: take a strong-enough algorithm and feed it a weak seed built from the clock, the process ID, and the parent process ID [@src-netscape1996]. The algorithm is irrelevant if the seed is enumerable. In 2005 the IETF wrote this lesson into a Best Current Practice, RFC 4086, whose Section 3 explicitly warns against seeding from clocks and serial numbers because they are low-entropy and guessable [@src-rfc4086]. The rule was written in blood.

{` // The cipher is never touched. Only the seed is guessed. // We model a small seed space, like Netscape's time+PID+PPID // or Debian's collapsed ~2^15..2^18 keyspace.

function prng(seed) { // a toy stand-in for the real generator let s = seed >>> 0; s = (Math.imul(1103515245, s) + 12345) >>> 0; // classic LCG constants return s; // the victim's "key material" }

const SEED_BITS = 18; // pretend this is all the entropy there was const seedSpace = 1 << SEED_BITS; // 262144 possibilities const secretSeed = Math.floor(Math.random() * seedSpace); const victimKey = prng(secretSeed); // a "256-bit key" -- but only 18 bits of real entropy

// Attacker knows the seed came from a small space and enumerates it: let tries = 0, recovered = -1; for (let guess = 0; guess < seedSpace; guess++) { tries++; if (prng(guess) === victimKey) { recovered = guess; break; } }

console.log('seed space:', seedSpace, 'possibilities'); console.log('attacker tries needed:', tries); console.log('key recovered:', recovered === secretSeed); console.log('note: a 256-bit key with 18 bits of seed entropy is an 18-bit key'); `}

Note: The clock, the process ID, the MAC address, a counter: all are low-entropy and often knowable to an attacker. A generator seeded from them has only as much unpredictability as the seed, no matter how strong the algorithm downstream. RFC 4086 codifies this as a rule: do not seed from clocks or serial numbers [@src-rfc4086]. In practice you should never seed a CSPRNG by hand at all; ask the operating system, which is the entire lesson of Sections 5 and 10.

Note: This is the first place your mental model has to shift. Statistical quality and cryptographic unpredictability are different properties, and the second does not follow from the first. The Mersenne Twister is the proof: it sails through the test batteries and collapses after 624 outputs [@src-mersenne1998]. Unpredictability is a computational claim about what an adversary can compute, not a statistical claim about how the bits are distributed. Tests can falsify a generator; they can never certify one, a limit we make precise in Section 8.

The theorists had, in fact, already named the generator that gets this right.

Blum, Blum and Shub (1986) built a generator whose unpredictability *provably* reduces to the hardness of factoring large integers: break the generator and you have factored the modulus [@src-bbs1986]. It is the gold standard on paper. It is also almost never deployed, because it computes only a few bits per modular squaring, orders of magnitude too slow for a system handing out billions of random bytes a day. It is a deliberate non-deployment: the theoretically cleanest answer, benched for being impractical, while the field builds fast generators on other assumptions.

The Mersenne Twister is not a villain, incidentally.For Monte-Carlo simulation, numerical integration, and procedural graphics, the Mersenne Twister is excellent and appropriate. It is disqualified only for cryptography, where its predictability is disqualifying. "Wrong for crypto" is not "wrong for everything." The lesson is narrower and sharper: statistical excellence is not unpredictability, and unpredictability is the only thing cryptography cares about. Turning that computational ideal into something an operating system can hand out billions of times a day took four decades and a string of named catastrophes. Here is how the generator evolved.

4. CSPRNG Design, Generation by Generation

No single insight fixed cryptographic randomness. Instead there was a ratchet. Each generation of generator worked until a named disaster exposed the one thing it got wrong, and that disaster defined the next generation. Walk the ladder and you will notice every rung is one of the two knobs failing in the generator half of the problem. The consumer-half failures, PS3 and BEAST and the rest, are on the ladder too, because they drove design changes, but their real home is Section 6.

NIST's term for the deterministic-expansion core of a modern generator: the algorithm that takes a seed and produces output bits by repeatedly applying a cryptographic function (a block cipher, a hash, or an HMAC). "DRBG" names the *expansion* half specifically; it does not include the entropy source that supplies the seed. A DRBG never creates unpredictability, it only stretches whatever the seed already contained. The short, high-entropy input a DRBG expands. Its length is set by the target security level (for example, 256 bits of seed for a 256-bit security level). Everything the generator's output can resist is bounded by the min-entropy of this seed: expand a 15-bit seed into a gigabyte of output and you have a gigabyte with 15 bits of unpredictability, which is exactly what happened to Debian.

Generation 0, physical and tabular (1949 to 1957). Harvest physical noise; if you must reuse it, print it in a book [@src-rand1955]. Superseded because a static table cannot deliver a fresh, secret, per-session value on demand, and von Neumann's middle-square degenerated to short cycles [@src-vonneumann1951].

Generation 1, statistical PRNGs with ad-hoc seeding (1960s to 1998). LCGs and the Mersenne Twister, seeded from the clock and the PID. Two knob-one failures stacked on top of each other: the generator is linearly invertible (624 outputs recover a Mersenne Twister) and the seed is enumerable (Netscape) [@src-mersenne1998, @src-netscape1996].

Generation 2, block-cipher PRNGs (ANSI X9.17 and X9.31, 1985 to 1998). A cipher instead of a linear recurrence, so the output is not linearly invertible. It failed because all security rested on a secret seed key $K$, and real products hard-coded $K$ into firmware. In 2017 the DUHK attack recovered full generator state and decrypted VPN traffic on devices such as FortiOS by exploiting a hard-coded X9.31 key, with no entropy input, no reseed, and no forward secrecy to save them [@src-duhk2018].

Generation 3, OS entropy pools (Linux /dev/random, Ts'o 1994). The operating system harvests timing from interrupts, keystrokes, and disk activity into a hashed pool, estimates how much entropy it holds, and blocks when the estimate runs low [@src-random-c, @src-random4man]. This was the first mass-deployed OS CSPRNG and a real advance, but it had three weaknesses: entropy estimation is guesswork; blocking starves fresh systems at boot and spawned years of /dev/random-versus-/dev/urandom confusion; and low boot entropy breaks real keys at scale. In 2012, Mining Your Ps and Qs scanned the internet and found that 5.57% of TLS hosts and 9.60% of SSH hosts shared keys, with thousands of RSA moduli factorable because devices generated keys before their pools had any entropy [@src-heninger2012, @src-factorable]. The independent Ron was wrong, Whit is right study found shared RSA prime factors across millions of moduli the same year [@src-lenstra2012], and in 2013 researchers factored 184 RSA keys from Taiwan's government-certified Citizen Digital Certificate smartcards, hardware that had passed FIPS and Common Criteria evaluation [@src-smartfacts, @src-coppersmith2013]. The Linux RNG's internal state had already been shown recoverable by cryptanalysis in 2006 [@src-gutterman2006], and the Windows generator was analyzed the following year [@src-dorrendorf2007].

Generation 4, standardized DRBGs (NIST SP 800-90A, 2006 onward). Hash_DRBG, HMAC_DRBG, and CTR_DRBG: a seed plus a cryptographic function stretched deterministically, with a defined reseed limit (at most $2^{48}$ generate requests) and a backtracking-resistant update step [@src-sp80090a]. And, shipped in the same document, the field's most instructive cautionary tale: Dual_EC_DRBG. It had a documented output bias, distinguishable from uniform independently of any back door (Schoenmakers and Sidorenko, 2006) [@src-schoenmakers2006], and, far worse, a trapdoor: whoever chose its elliptic-curve points $P$ and $Q$ could recover the internal state from about 32 bytes of output and predict all future output (Shumow and Ferguson, 2007) [@src-shumow2007]. It was reported in 2013 as a deliberate program [@src-reuters2013] and caught weaponized in Juniper's ScreenOS in 2015 [@src-checkoway2016]. A generator can pass every statistical test and still be owned by whoever chose its constants.

flowchart TD G0["Gen 0: physical and tabular (1949 to 1957)"] -->|"a table makes no fresh secret"| G1["Gen 1: statistical PRNGs, ad-hoc seeds"] G1 -->|"MT 624 outputs, Netscape seed"| G2["Gen 2: block-cipher PRNGs (X9.17, X9.31)"] G2 -->|"DUHK hard-coded key"| G3["Gen 3: OS entropy pools (Linux, 1994)"] G3 -->|"boot starvation, Mining Ps and Qs"| G4["Gen 4: standardized DRBGs (SP 800-90A)"] G4 -->|"Dual EC back door"| G5["Gen 5: accumulation, ChaCha20, getrandom"] G5 -->|"fork or VM-snapshot clone"| G6["Gen 6: converged validated architecture (90B, 90A, 90C)"]

Generation 5, entropy accumulation, stream-cipher cores, and non-blocking syscalls (1999 to 2022). Yarrow (1999) [@src-yarrow1999] led to Fortuna (2003), whose 32 staggered pools abolish entropy estimation altogether [@src-fortuna2003, @src-freebsd-random]. The output core moved to ChaCha20, Bernstein's refinement of his earlier Salsa20 cipher [@src-chacha, @src-snuffle]: OpenBSD re-cored arc4random on it in 2014 [@src-arc4random], and Linux replaced its non-blocking pool with a ChaCha20 CRNG in kernel 4.8, October 2016 [@src-linux48].Pin this milestone at Linux 4.8 (October 2016), commit e192be9d9a30555. A "5.6 / 2020" figure sometimes cited refers to an unrelated change in how /dev/random handles O_NONBLOCK, not the ChaCha20 output core [@src-linux48]. Jason Donenfeld's 5.17 to 5.18 rewrite in 2022 added BLAKE2s extraction, per-CPU fast key erasure, and unified /dev/random with /dev/urandom [@src-donenfeld2022]. The getrandom(2) syscall (2014) blocks once at boot until the pool is seeded, then never again [@src-getrandom]. One hazard the generator alone cannot fix remained: fork() and VM-snapshot cloning duplicate the entire generator state and re-emit identical values, a uniqueness failure measured in the wild by Ristenpart and Yilek (2010) and Everspaugh et al. (2014) [@src-ristenpart2010, @src-everspaugh2014].OpenBSD kept the name arc4random for source compatibility even though the "RC4" it originally stood for is long gone; since 2014 the bytes come from ChaCha20 [@src-arc4random].

Generation 6, the converged validated architecture (2018 to 2026, current state of the art). A validated entropy source (SP 800-90B) [@src-sp80090b] seeds a computational DRBG (SP 800-90A) [@src-sp80090a], and the two are tied together by SP 800-90C [@src-sp80090c], with continuous reseeding, forward secrecy, clone defense, and no single component trusted on its own. We draw the whole pipeline in Section 5.

flowchart TD K["State: Key and counter block V"] --> G["Generate: AES-CTR keystream from Key and V"] G --> O["Hand the requested bytes to the caller"] G --> U["Update: re-derive a fresh Key and V"] U --> K2["New state replaces the old one, so prior output cannot be recomputed (backtracking resistance)"] K2 --> R["After up to 2 to the 48 requests, reseed from the entropy source"] R --> K

Now put every break on one page. This is the spine of the article: read down the two middle columns and each disaster resolves to a single knob turned the wrong way in a single place.

Table 1: The Failure Catalog.

Break	Year	Knob broken	Place	Root cause	Lesson
Netscape SSL [@src-netscape1996]	1996	predictable	generator	Seed was time + PID + PPID	Never seed from the clock or a PID
Debian OpenSSL [@src-debian2008]	2008	predictable	generator	Entropy input removed, keyspace ~2^15	Never delete an entropy source
PS3 signing key [@src-fail0verflow2010]	2010	repeated	role (nonce)	Same ECDSA nonce k on every signature	A signature nonce must be unique
Android Bitcoin [@src-android2013]	2013	repeated	role (nonce)	SecureRandom mis-init repeated k	Seed the RNG before drawing a nonce
Mining Ps and Qs [@src-heninger2012]	2012	predictable	generator	Keys generated before pool seeded	Do not make keys at cold boot
Dual_EC_DRBG [@src-shumow2007]	2007-15	predictable	generator	Trapdoor in chosen points P, Q	Choose constants verifiably; never trust one source
VM-snapshot reset [@src-ristenpart2010]	2010-14	repeated	generator	Snapshot clones generator state	Force a reseed after any clone
DUHK [@src-duhk2018]	2017	predictable	generator	Hard-coded X9.31 seed key	Never hard-code the seed key
BEAST [@src-cve2011]	2011	predictable	role (CBC IV)	TLS 1.0 chained the previous ciphertext block as IV	A CBC IV must be unpredictable
GCM nonce reuse in TLS [@src-cve2016]	2016	repeated	role (nonce)	Repeated 96-bit nonce under one key	Never reuse a GCM nonce per key
CTR_DRBG cache attack [@src-cohney2020]	2020	predictable	generator	AES-table cache timing leaks state	Prefer a constant-time core
PuTTY P-521 [@src-putty2024]	2024	predictable	role (nonce)	Biased k, first 9 bits always zero [@src-putty-oss]	A nonce must be uniform or derived

Two columns, two values each. Every row is one knob times one place. Hold this table in mind; Section 10 hands it back to you as the Common Misuse catalog, the same evidence seen from the developer's chair.

Dual_EC did more than embarrass a standard; it changed how the field designs generators. Before it, the working assumption was "trust the standardized construction." After it, the assumption became "mix multiple sources and trust no single one, and choose your constants so anyone can verify there is no hidden structure." That is why modern kernels fold hardware RNG output *into* a pool rather than using it raw, why NIST's newer curves come with published nothing-up-my-sleeve derivations, and why SP 800-90C validates the *whole* pipeline instead of asking you to trust the source and the DRBG separately [@src-sp80090c].

The lesson generalizes: a generator that can be back-doored by whoever picks its constants is not secure just because it passes tests. This philosophy shapes Sections 5 and 7.

The most surprising fix of all runs the other direction. After the PlayStation 3, the Bitcoin wallets, and eventually PuTTY, all showed that a random per-signature nonce is catastrophic when it repeats or leaks,Recovery differs by failure mode. A repeated nonce means two signatures share $k$, so simple algebra recovers the private key, as on the PlayStation 3. A biased nonce, like PuTTY's nine always-zero leading bits, falls to a lattice attack on the Hidden Number Problem: each signature leaks a few key bits, and lattice reduction solves for the key once about 60 accumulate [@src-putty-oss]. RFC 6979 (2013) responded by removing the randomness: it derives the ECDSA nonce deterministically from the private key and the message, so that signers, in the RFC's own words,

"...do not need access to a source of high-quality randomness." -- RFC 6979, on deterministic ECDSA nonces [@src-rfc6979]

The fix for a randomness disaster was less randomness. That inversion is the clue that the generator is only half the story, and often not the interesting half. Seven generations and a dozen named disasters later, the modern architecture is strikingly simple once you see what every break was really teaching. Strip away the history and one design remains, built from two layers most engineers never separate.

5. The Modern Architecture, and the Two Layers Underneath It

Every fix in Section 4 was pushing toward one shape, and here it is. A true entropy source seeds a computational DRBG that stretches a little unpredictability into unlimited output, with continuous reseeding, forward secrecy, and clone defense, and with distrust of any single component built in. Nothing exotic. Just forty years of scar tissue drawn as a single pipeline.

flowchart LR E["Entropy sources: interrupts, RDSEED, TPM"] --> A["Accumulate and condition"] A --> D["DRBG expansion: AES-CTR or ChaCha20"] D --> I["OS interface: getrandom, arc4random, BCryptGenRandom"] I --> R["Consumer roles: key, nonce, IV, salt"] D -.->|"reseed and fast key erasure"| A

Read it left to right. Physical noise (interrupt timing, the RDSEED instruction, a TPM) is accumulated and conditioned into a seed. A DRBG expands that seed into as many bytes as anyone asks for. An operating-system interface hands those bytes to your program, which pours them into one of four roles. The dotted return edge carries the two properties that keep the whole thing honest: reseeding, which periodically mixes fresh entropy back in, and forward secrecy, which we define in a moment.

The distinction the whole subject turns on is the one from Sections 2 and 3, now with a job. Computational unpredictability is about what an adversary can compute, and the DRBG delivers it by construction, provided the seed carried real entropy. A DRBG does not create entropy; it stretches it. Garbage seed in, garbage out, which is why the entire left side of the diagram exists.

A generator has *forward secrecy* if an attacker who compromises its state at some moment still cannot reconstruct output it produced *earlier*. ChaCha20-based generators achieve it by *fast key erasure*: after generating a block, the first bytes of fresh keystream overwrite the generator's own key, and only the remaining bytes are handed out [@src-donenfeld2022]. The key that produced earlier output no longer exists anywhere, so a later memory capture cannot roll time backward. Periodically folding fresh entropy into the generator's state, on a schedule (SP 800-90A mandates a reseed within $2^{48}$ requests) or on an event (after a `fork()`, after a VM resumes from a snapshot) [@src-sp80090a]. Reseeding gives *backward* secrecy: even if the state was compromised, once enough new entropy is mixed in, future output becomes unpredictable again. sequenceDiagram participant S as Generator state participant O as Output S->>O: emit one block of keystream S->>S: overwrite the key with fresh keystream Note over S: the old key is gone, so earlier output cannot be recomputed

Now the correction that clears away half the folklore in this field: the difference between an OS interface and a CPU instruction. These are two different layers, and conflating them is the source of endless bad advice.

An OS-provided interface is what your code should call: getrandom(2) or /dev/urandom on Linux, getentropy(3) or arc4random(3) on BSD and macOS, BCryptGenRandom or ProcessPrng on Windows [@src-getrandom, @src-arc4random]. On Linux, getrandom blocks once until the pool is first seeded and then never again, which is what finally ended the /dev/random-versus-/dev/urandom dilemma at the interface level [@src-getrandom, @src-lwn2014].

A CPU instruction is what the operating system consumes, not what you call. Intel's RDRAND returns the output of an on-die hardware DRBG; RDSEED returns near-raw, seed-grade entropy [@src-intel-drng]. The kernel does not hand these to you and does not trust them on their own. It mixes them into its pool alongside other sources, precisely the post-Dual_EC discipline: never let one opaque component be the whole answer [@src-donenfeld2022].

Note: The rule is a single sentence: applications call the OS interface; only the kernel touches the CPU instruction. If you find yourself calling RDRAND directly in application code, you have skipped the layer that mixes, reseeds, and forward-secures the output, and you are trusting one piece of opaque silicon with the whole job, the exact mistake Dual_EC taught the field never to make [@src-shumow2007]. Call getrandom, getentropy, or BCryptGenRandom, and let the kernel decide how much to trust the hardware [@src-getrandom, @src-donenfeld2022].

flowchart TD APP["Your application"] -->|"calls this"| OSI["OS interface: getrandom, arc4random, BCryptGenRandom"] OSI --> POOL["Kernel entropy pool and DRBG"] POOL --> OSI RDRAND["CPU RDRAND: on-die DRBG output"] -.->|"mixed in, never trusted alone"| POOL RDSEED["CPU RDSEED: seed-grade entropy"] -.->|"mixed in, never trusted alone"| POOL So why not skip the pool and read `RDRAND` directly? Because mixing is what turns "trust no single source" from a slogan into a working defense. If the kernel folds `RDRAND` into a pool that also holds interrupt timing and a saved seed, then even a compromised `RDRAND` cannot by itself make the output predictable, because it is only one of several inputs to the mix. Trust is not placed in any one component; it is *diluted* across all of them. We return to the hardware-versus-software question in Section 7.

Seen this way, the generator's entire job is to manufacture knob number one, unpredictability, and to keep manufacturing it reliably. Everything else in the pipeline, reseeding, forward secrecy, clone defense, architected distrust, exists to stop that one property from silently failing. The four decades of history collapse into a single sentence: keep the seed unguessable, keep the state fresh, and never let one component be the whole answer.

Windows implements this same pipeline with a CTR_DRBG tree behind BCryptGenRandom and ProcessPrng; the platform-specific internals, including how the kernel seeds per-processor generators and defends against VM cloning, are the subject of a dedicated companion article on the Windows CSPRNG, and the CNG API surface itself lives in a companion post. We will not re-derive them here.

That is the generator half, essentially solved as engineering. But a flawless generator is only half the battle, because the same perfect byte stream is catastrophic if you pour it into the wrong role. What, exactly, does each role demand?

6. What Ships in 2026, and the Four Roles

By 2026 the generator architecture is settled engineering, and most real-world breaks happen after the generator, when good bytes are used wrong. So we cover what ships in a paragraph, then spend the rest of the section on the practitioner's heart of the matter: the four roles and the exact property mix each one demands.

What ships: the SP 800-90A trio (CTR_DRBG, HMAC_DRBG, Hash_DRBG) [@src-sp80090a]; Fortuna on FreeBSD [@src-freebsd-random]; and ChaCha20-based generators reachable through Linux getrandom and OpenBSD or macOS arc4random [@src-donenfeld2022, @src-arc4random].

The 2025 capstone is SP 800-90C, which stops treating "the entropy source" and "the DRBG" as separate acts of faith and validates the whole pipeline as one of four RBG construction classes: RBG1 (seeded once, no ongoing source, for constrained devices), RBG2 (continuous access to a validated SP 800-90B source, the common server case), RBG3 (an enhanced, full-entropy construction combining a physical source directly with a DRBG), and RBGC (chained constructions built from approved components) [@src-sp80090c].

A pre-draft SP 800-90A Rev. 2 adds an XOF_DRBG built on the SHAKE functions from FIPS 202, forward-looking but not yet final [@src-sp80090a-r2].

Post-quantum cryptography makes randomness more foundational, not less. The 2024 standards each draw fresh CSPRNG output per operation: ML-KEM consumes random seeds during key generation and encapsulation [@src-fips203], ML-DSA draws a fresh value per signature [@src-fips204], and SLH-DSA pulls several seeds per operation [@src-fips205]. More draws mean more surface for a weak generator to ruin, which is why the post-quantum migration guides for these algorithms treat the CSPRNG as a first-class dependency.

Now the centerpiece. There are exactly four roles a random value plays in cryptography, and each demands a different combination of three properties: uniqueness, unpredictability, and secrecy. Getting the combination wrong is how a perfect generator still gets you owned.

Table 2: The four roles and what each one owes.

Role	Unique?	Unpredictable?	Secret?	Canonical failure if violated
Key	yes	yes	yes	Guessable key: Netscape 1996, Debian 2008 [@src-debian2008]
CBC IV	yes	yes	no	Predictable IV enabled BEAST [@src-cve2011]
CTR/GCM nonce	yes	no	no	Repeated nonce leaks the auth key: GCM in TLS 2016 [@src-cve2016]
Salt	yes	no (but random)	no	Reused or global salt enables shared precomputed tables

Read the differences, because they are the whole point.

A *nonce* is a "number used once." Its one absolute requirement is *uniqueness* per key: no two operations under the same key may ever use the same nonce. A nonce does *not* have to be unpredictable, and it does *not* have to be secret. A simple monotonic counter is a perfectly good nonce, and often the safest one, because a counter cannot accidentally repeat the way random draws can. An *IV* is the per-message starting value for a block-cipher mode, and its requirement depends entirely on the mode. In CBC, the IV must be both *unpredictable* and *unique*. In CTR and GCM, the value the spec labels "IV" is really a *nonce*, and needs only to be *unique*. The word "IV" therefore does not name a fixed requirement; the *mode* names the requirement. This is the single most common source of confusion in applied randomness.

The nonce-versus-IV correction deserves stating precisely, because folklore gets it backwards. The same value slot is called an "IV" or a "nonce" depending on the mode, and the mode dictates the requirement.

A CBC IV must be unpredictable and unique. TLS 1.0 chained CBC records by using the previous ciphertext block as the next IV, which is predictable, and that predictability is exactly what the BEAST attack exploited in 2011 (CVE-2011-3389). TLS 1.1 restored a fresh random IV, and the modern answer is to move to authenticated encryption entirely [@src-cve2011, @src-imperialviolet].

A CTR or GCM nonce, by contrast, needs only to be unique; unpredictability buys nothing. But uniqueness is absolute: reuse a GCM nonce under one key even once and you immediately leak the XOR of the two plaintexts, and the reused authentication tags give a polynomial equation whose roots recover the GHASH subkey $H$ (Joux's forbidden attack), enabling universal forgery. That failure was measured across live TLS servers in 2016 under the name "Nonce-Disrespecting Adversaries" and captured for IBM Domino as CVE-2016-0270 [@src-cve2016].

Note: GCM's security collapses the instant a nonce repeats under a given key. Two messages encrypted with the same key and nonce leak the XOR of their plaintexts and, worse, give up the polynomial equation that recovers the GHASH subkey $H$, after which an attacker can forge arbitrary messages that pass authentication [@src-cve2016]. There is no partial failure here and no recovery: one repeat is game over for that key. Use a counter, or if you cannot guarantee uniqueness across senders, use a nonce-misuse-resistant mode (Section 7).

flowchart TD V["A value in the IV or nonce slot"] --> Q{"Which mode?"} Q -->|"CBC"| CBC["Must be unpredictable AND unique. A predictable IV enabled BEAST"] Q -->|"CTR or GCM"| CTR["Must be unique only. Reuse leaks the authentication key"]

The last role, the salt, is where a different myth does the damage.

A *salt* is a unique, random value added to a password before hashing, and it is *not secret*: it is stored in plaintext right next to the resulting hash. Its only job is uniqueness, so that identical passwords hash to different values and one precomputed table cannot attack many accounts at once. A salt needs to be unique and random; it does not need to be unpredictable or hidden.

Believing a salt must be secret, or reusing one global salt across every password, is a common and wrong model. A per-password random salt of 16 bytes, stored openly, does its entire job; hiding it adds nothing, and sharing it across users throws the job away, because then one precomputed table works against every account again [@src-nist-63b].The same reuse math retired WEP: a short per-packet IV space made keystream reuse inevitable, which broke the confidentiality of the whole scheme [@src-bgw2001]. That story belongs to cipher agility and is told in the SChannel post.

{` const crypto = require('crypto');

// KEY: secret + unpredictable + high-entropy. Straight from the OS CSPRNG. const key = crypto.randomBytes(32); // 256 bits, for AES-256 or ChaCha20

// GCM NONCE: unique only. A monotonic counter guarantees uniqueness by construction. let counter = 0n; function nextNonce() { const n = Buffer.alloc(12); // 96-bit GCM nonce n.writeBigUInt64BE(counter, 4); // 64-bit counter in the low bytes counter += 1n; // never repeats under this key return n; }

// SALT: unique + random, stored in the clear next to the password hash. const salt = crypto.randomBytes(16); console.log('salt is PUBLIC, stored with the hash:', salt.toString('hex'));

// The WRONG lines, for contrast: // const nonce = Buffer.alloc(12); // reused -> repeated knob, in a role // const salt = Buffer.from(String(Math.random())); // Math.random is not a CSPRNG -> predictable

console.log('key bytes:', key.length, 'nonce bytes:', nextNonce().length); console.log('same generator, three different disciplines'); `}

Key idea: A perfect generator poured into the wrong role is as fatal as a broken generator. The key must be secret, unpredictable, and high-entropy; the CBC IV unpredictable and unique; the CTR or GCM nonce unique and nothing more; the salt unique, random, and public. Four roles, one generator, four different disciplines. Learn which mix each role owes and most of the Failure Catalog stops being possible.

Now the reader knows what each role demands. But which generator should manufacture the bits, and is a hardware RNG better than a software one? The honest answer overturns the question.

7. CTR_DRBG, Fortuna, and ChaCha, and Hardware Versus Software

"Which cipher makes the best RNG?" is the wrong question. The real axis is architecture: how you source entropy and how you expand it. Get that framing right and the "competitors" turn out to be solving different halves of the same problem.

Start with a category correction. Fortuna is largely an accumulator, the sourcing half: its contribution is how it collects and schedules entropy. CTR_DRBG and ChaCha20 are expanders, the expansion half: their contribution is how they stretch a seed. A real system runs an accumulator front-end feeding an expander core, so "CTR_DRBG versus Fortuna" is partly a comparison between a fuel tank and an engine.

Table 3: Deployed generators, head to head.

Property	CTR_DRBG	HMAC_DRBG	Fortuna	ChaCha20
Output cost	~1 AES per 128 bits	~1 HMAC per block	cipher core per block	1 ChaCha permutation per 512 bits
State size	Key + 128-bit V	two hash-length values	32 pools + generator key	256-bit key, per CPU
Forward secrecy	Update re-derives (Key, V)	Update re-derives (Key, V)	frequent generator rekey	fast key erasure
Side channel	AES-table lookups can leak [@src-cohney2020]	HMAC, low risk	depends on core	constant-time by design [@src-chacha]
Entropy philosophy	assumes a 90B seed	assumes a 90B seed	accumulates, no estimate	assumes a pool seed
Reseed	up to 2^48 requests	up to 2^48 requests	32-pool staggered	continuous, per CPU
FIPS 140	yes, validated	yes	no	not yet
Concurrency	per instance	per instance	single system RNG	per CPU since Linux 2022
Best suited for	FIPS boundaries, AES-NI	deterministic signatures	accumulator front-end	modern software default

Two 2026 differences decide most real choices. First, ChaCha20 is constant-time by design, with no secret-dependent branches or table lookups,Constant-time means the code's execution path and memory-access pattern do not depend on secret values, so an attacker watching timing or cache behavior learns nothing about the state. so it sidesteps the cache-timing state-recovery that Cohney et al. demonstrated against real CTR_DRBG deployments in 2020 [@src-cohney2020, @src-chacha]. Second, CTR_DRBG holds FIPS 140 validation, which is exactly why it still dominates inside compliance boundaries and on AES-NI hardware despite the side-channel result [@src-sp80090a]. Linux's 2022 move to per-CPU ChaCha instances closed the historic concurrency gap that once favored other designs [@src-donenfeld2022].

Two honest philosophies for the sourcing half. *Estimation* (NIST SP 800-90B) models the noise source, computes a min-entropy estimate, and runs health tests to catch degradation [@src-sp80090b]. *Accumulation* (Fortuna) refuses to estimate at all: it spreads incoming events across many pools and drains them on a schedule that guarantees at least one pool eventually holds enough entropy, whatever the true rate [@src-fortuna2003, @src-cryptoeng]. One measures; the other structures itself so that measurement is unnecessary. flowchart TD EV["Entropy events arrive"] --> RR["Round-robin into pools P0 through P31"] RR --> P0["P0 drains at every reseed"] RR --> PI["Pi drains only when 2 to the i divides the reseed number"] RR --> P31["P31 fills rarely but very deeply"] P0 --> RK["Reseed the generator key"] PI --> RK P31 --> RK

The hardware-versus-software debate resolves the same way: not by choosing, but by mixing.

Table 4: Hardware RNG versus software DRBG.

	Hardware (RDRAND/RDSEED, TPM)	Software DRBG (CTR/ChaCha)
Source of unpredictability	physical noise on the die	deterministic expansion of a seed
Auditability	opaque, you cannot inspect silicon	open, testable, formally analyzable
Failure mode	silent bias or back door (the Dual_EC lesson) [@src-shumow2007]	bad seed, state clone, side channel
Forward secrecy	vendor-dependent	explicit (key erasure or Update)
Verdict	seed-grade input only	auditable expansion + forward secrecy

Hardware supplies physical unpredictability but is a black box you cannot audit; software supplies auditable, forward-secret expansion but only stretches a seed. The field's resolution is to fold hardware output into the pool rather than trust it directly [@src-donenfeld2022]. "Trust RDRAND alone" fell out of favor precisely because Dual_EC proved silicon and standards can both be compromised [@src-shumow2007].

Note: This article cross-references the Windows CSPRNG rather than duplicating it. How CNG assembles a per-processor CTR_DRBG tree, seeds it, and defends against VM cloning is covered in full there.

On the consumer side, the same "which construction" question has its own honest table, this time about how much uniqueness burden you are willing to carry.

Table 5: Plain GCM versus GCM-SIV versus deterministic.

	AES-GCM (counter nonce)	AES-GCM (random nonce)	AES-GCM-SIV	RFC 6979 (signatures)
Uniqueness burden	on the caller (counter)	birthday cap ~2^32 per key	tolerates repeats	none (deterministic)
Cost vs GCM	1x	1x	~2x	not applicable
Catastrophic on reuse?	yes	yes	no	not applicable
Use when	you control a counter	low message volume	uniqueness not guaranteed	ECDSA/DSA nonces

AES-GCM-SIV (RFC 8452) derives its internal inputs from a synthetic value computed over the nonce and the plaintext, so a repeated nonce with different messages no longer leaks the authentication subkey [@src-rfc8452]. In the RFC's own words, such schemes are built so that they

"...do not fail catastrophically if a nonce is repeated." -- RFC 8452, on AES-GCM-SIV [@src-rfc8452]

It costs roughly twice a plain GCM encryption and is the right answer when you cannot guarantee unique nonces, for example across many independent senders. RFC 6979 is the other escape hatch, for signatures: derive the nonce deterministically and the uniqueness problem disappears entirely [@src-rfc6979].

It is tempting to declare a winner between NIST's estimation and Fortuna's accumulation, but both ship in 2026 and neither is wrong. Estimation gives you a number you can put in a validation report and a health test that fires when the source degrades [@src-sp80090b]. Accumulation gives you robustness without ever having to trust a number, at the cost of absorbing a burst of fresh entropy more slowly, since high-index pools reseed rarely [@src-fortuna2003]. The mature view is that they are different risk trades over the same unmeasurable quantity, which is the subject of the next section.

The engineering looks won: mix a validated source into a constant-time, forward-secret DRBG behind an un-misusable syscall. So why does the field still call randomness an open problem? Because underneath the engineering sit limits no code can cross.

8. What You Cannot Know or Prove

Everything so far was engineering, and engineering can be improved. This section is about the floor beneath it: things you fundamentally cannot do, no matter how good your code is. This is where confidence turns to humility.

Min-entropy is unmeasurable. You cannot measure the min-entropy of an unknown physical source from its output; you can only estimate it under a model of how the source behaves. SP 800-90B's entire apparatus, its estimators and its health tests, is a disciplined estimate, not a proof [@src-sp80090b]. The whole tower we built in Sections 5 through 7 rests on this one estimate, and if the model is wrong, everything above it is quietly weaker than its paperwork claims.

Statistical tests can falsify, never certify. SP 800-22 is explicitly hypothesis testing with P-values: a suite can reject a generator, but it can never prove unpredictability [@src-sp80022]. The proof by counterexample is the Mersenne Twister from Section 3: it passes the standard batteries and is fully broken by 624 outputs [@src-mersenne1998].The named suites, SP 800-22, Dieharder, TestU01, are useful for catching gross defects and nothing more. Running more of them does not raise your security; it only lowers the chance you shipped something obviously broken. "More tests" is not "more secure."

Every deployed computational CSPRNG rests on an unproven assumption. The best a deterministic generator achieves is the next-bit guarantee, but that guarantee is conditional: cryptographically secure generators exist if and only if one-way functions exist, an equivalence whose hard direction (any one-way function yields a generator) was proved by Hastad, Impagliazzo, Levin, and Luby [@src-hill1999, @src-katzlindell]. The existence of one-way functions is itself unproven, since it would imply that $P \neq NP$. There is no unconditionally secure pseudorandom generator. Every CSPRNG you have ever used is secure only relative to a hardness assumption no one has proved.

For an $m$-bit random value drawn repeatedly, collisions become likely after roughly $2^{m/2}$ draws, not $2^m$, because the chance is dominated by pairs. For a 96-bit GCM nonce, the 50% collision point sits near $2^{48}$ draws. This is a *provable ceiling*, not an implementation defect. It is why SP 800-38D caps random 96-bit nonces well below that point, at about $2^{32}$ messages per key, to keep the repeat probability negligibly small [@src-sp80038d].

The birthday bound is a hard uniqueness ceiling. Randomness cannot buy its way past its own birthday bound. The only escapes are to stop drawing randomly, using a counter whose uniqueness is structural, or to tolerate repeats with a nonce-misuse-resistant mode. There is no third option in which random draws stay unique forever.

{` // Birthday bound: for an m-bit value, collisions get likely near 2^(m/2). const m = 96; // GCM nonce size in bits

const fiftyPercentPoint = Math.pow(2, m / 2); // ~2^48 draws for 96 bits console.log('nonce size:', m, 'bits'); console.log('~50% collision near 2^' + (m / 2) + ' =', fiftyPercentPoint.toExponential(3), 'draws');

// Birthday approximation for n draws into a 2^nBits space: function collisionProb(nBits, n) { const space = Math.pow(2, nBits); return 1 - Math.exp(-(n * (n - 1)) / (2 * space)); }

// SP 800-38D caps random 96-bit nonces at ~2^32 messages per key. // Why 2^32 and not 2^48? Because the cap targets a TINY probability, not 50%: const cap = Math.pow(2, 32); console.log('at 2^32 draws, P(collision) =', collisionProb(96, cap).toExponential(3)); console.log('that is the safety margin SP 800-38D buys by capping at 2^32'); `}

Back doors are undetectable by construction. Dual_EC is the proof once more: a standardized generator can pass every statistical test and still be fully predictable to whoever chose its constants $P$ and $Q$ [@src-shumow2007]. You cannot test your way out of this, which is exactly why the field moved to verifiable constants and architected mixing rather than after-the-fact detection.

Clone defense is mitigation, not elimination. fork() and VM-snapshot cloning duplicate a good generator [@src-ristenpart2010, @src-everspaugh2014]. VM Generation ID counters, library fork detection, and forced reseeds shrink the window but do not close it; Ferguson's 2019 Windows RNG whitepaper is explicit that a guest cannot fully solve the snapshot problem on its own, because it may not even know it was cloned until it has already emitted duplicate output [@src-ferguson2019win].

And beneath all of it, the permanent gap Shannon left us in Section 2. His one-time pad is unconditionally secure but unscalable, a fresh truly-random key as long as every message. The CSPRNG is scalable but assumption-dependent. No cryptography closes that gap; we simply chose the scalable side and spend the rest of our effort defending it.

flowchart TD START["A randomness bug"] --> K{"Which property failed?"} K -->|"predictable"| P{"Where did it fail?"} K -->|"repeated"| R{"Where did it fail?"} P -->|"generator"| PG["Netscape, Debian, Dual EC, DUHK, CTR_DRBG cache"] P -->|"role"| PR["BEAST (CBC IV), PuTTY (biased nonce)"] R -->|"generator"| RG["VM-snapshot clone"] R -->|"role"| RR["PS3, Bitcoin, GCM nonce reuse"]

Key idea: You cannot certify unpredictability; you can only fail to falsify it. Min-entropy is estimated, not measured; statistical tests reject but never prove; the whole construction rests on an unproven hardness assumption; and back doors leave no trace in the output. The entire discipline of cryptographic randomness is the management of a risk you cannot directly measure. The surprise is not that randomness sometimes fails. It is that it works as well as it does.

If entropy is unmeasurable and unpredictability uncertifiable, where is randomness still actively failing today?

9. Where Randomness Is Still Failing

The architecture is settled; the frontier is not. Here are six places where cryptographic randomness is still an open engineering or standards problem in 2026, honestly contested rather than adjudicated.

Early-boot entropy on embedded devices, IoT, and VMs. A device that must generate a key seconds after first power-on, before its pool has filled, is the exact condition Mining Your Ps and Qs measured in 2012, and it still recurs in modern IoT field scans [@src-factorable]. Partial fixes exist: getrandom blocking once until seeded [@src-getrandom], saved-seed files such as FreeBSD's /boot/entropy [@src-freebsd-random], and mixing in RDSEED or jitter-based entropy at boot. None fully solves a cold device with no stored seed and no timing history.

Validating entropy sources at fleet scale. SP 800-90B health tests run per device, but proving that a noise-source model holds across millions of heterogeneous units, over years, across temperature swings and silicon aging, is unsolved [@src-sp80090b]. Fortuna's accumulation sidesteps estimation but not validation: you still have to argue the events carry entropy at all.

Making nonce-misuse resistance the default. Plain AES-GCM fails catastrophically on a single nonce repeat [@src-rfc8452], yet plain AES-GCM, not AES-GCM-SIV, remains the default AEAD offered by most general-purpose libraries. This is an adoption and standards gap, not a research one. TLS 1.3's fixed-IV construction and the pending SP 800-38D revision help at the protocol layer [@src-sp80038d-news], but general-purpose libraries still hand developers the sharp tool by default.

Post-quantum's larger draws and wider side-channel surface. ML-DSA and its siblings consume more randomness and add rejection-sampling and secret-dependent code paths, which means more surface for a weak generator or a timing leak to do damage [@src-fips204]. The post-quantum migration is an opportunity to get seeding right and a risk if it is not.

Trusting hardware RNGs after Dual_EC. "Never trust a single hardware source" is settled practice, but a general, auditable way to earn trust in opaque silicon is open [@src-shumow2007]. Cohney's cache attack showed that even a correct-on-paper CTR_DRBG can leak through microarchitectural side channels, so "the math is right" is not the end of the story [@src-cohney2020].

Formally verifying RNG code end to end. Proofs typically assume "the implementation does not leak," but real code leaks through caches, forks, and uninitialized memory. Individual primitives have been verified, but a whole-pipeline proof under a realistic leakage model, from entropy source through DRBG to syscall, is not yet routine.

Note: Notice the pattern across all six. The expansion problem, how to stretch a good seed into unlimited unpredictable output, is essentially solved: constant-time cores, forward secrecy, validated constructions. What remains open is sourcing (getting and validating real entropy, especially at boot and at fleet scale) and trust (how much to believe an opaque hardware source, and how to prove a whole implementation does not leak). The hard part was never the arithmetic. It is the physics and the epistemics around it.

Physical noise is quietly back in fashion, incidentally.RDSEED, on-chip ring-oscillator sources, quantum RNGs, and TPMs are all seeing renewed use as entropy inputs. The difference from the pre-Dual_EC era is that they are mixed in, never trusted raw. The physics returned; the blind trust did not. These are the field's problems. But you have to ship code tomorrow. What are the rules, concretely, per role, that keep you out of the Failure Catalog?

10. The Field Guide, Made Operational

Everything collapses to a short set of rules of the form "use X with these parameters in case Y." This is the two-knobs thesis turned into a checklist, and its mirror, the Common Misuse catalog, is simply the Failure Catalog seen from the developer's chair.

Rule zero for the generator: never roll your own, and never hand-seed. Always call the operating system's CSPRNG.

Table 6: Generator, call this, not this.

Platform	Call this	Never this
Linux	`getrandom(2)`, `/dev/urandom` [@src-getrandom]	a hand-seeded userspace PRNG, blocking on `/dev/random`
BSD, macOS	`getentropy(3)`, `arc4random(3)` [@src-arc4random]	`rand()`, `random()`
Windows	`BCryptGenRandom`, `ProcessPrng`	anything seeded by hand (see the CNG post)
Language stdlib	Node `crypto.randomBytes`, Python `secrets` / `os.urandom`, Go `crypto/rand`, Java `SecureRandom`	`Math.random()`, Python `random`, Mersenne Twister, `java.util.Random`, `System.Random`

Then, per role, the decision rules:

Key. Draw from the OS CSPRNG at the primitive's exact key length: 32 bytes for AES-256 or ChaCha20. Nothing else.
CTR/GCM nonce. Prefer a 96-bit monotonic counter (uniqueness by construction). If you must draw randomly, cap usage at fewer than $2^{32}$ messages per key. Never reuse a nonce under one key. If uniqueness cannot be guaranteed across distributed senders, use AES-GCM-SIV [@src-rfc8452].
CBC IV. A fresh unpredictable value per message from the CSPRNG, never a counter and never the previous ciphertext block, or better, migrate to authenticated encryption.
Salt. At least 16 bytes from the CSPRNG, unique per password, stored in plaintext. Never a global salt.
Signature nonce (k). Use RFC 6979 deterministic k, or a hedged scheme; never a bare draw whose bias or repetition leaks the private key [@src-rfc6979].
Fork or VM clone. Rely on kernel reseed (VM Generation ID) plus library fork detection, and force a reseed after any clone or snapshot before emitting security-critical output [@src-ferguson2019win].

Table 7: The Common Misuse catalog (the mirror of Table 1).

Misuse	Knob and place broken	Named break
Seeding from `time()` or a PID	predictable, generator	Netscape [@src-netscape1996]
Removing or starving entropy	predictable, generator	Debian, Ps and Qs [@src-debian2008]
Reusing a GCM nonce under one key	repeated, role	GCM in TLS 2016 [@src-cve2016]
Predictable or chained CBC IV	predictable, role	BEAST [@src-cve2011]
Static or biased signature k	repeated or predictable, role	PS3, PuTTY [@src-putty2024]
Secret, short, or global salt	repeated, role	shared precomputed tables
Hand-seeding a userspace PRNG	predictable, generator	interface misuse
Trusting `RDRAND` alone	predictable, generator	the Dual_EC lesson [@src-shumow2007]
Mersenne Twister or `Math.random` for tokens	predictable, generator	statistical PRNG used for crypto [@src-mersenne1998]
No reseed after `fork()` or snapshot	repeated, generator	VM-reset [@src-ristenpart2010]
UUIDv4 as a security token	predictable, role	guessable token [@src-rfc9562]

The meta-lesson runs through every row: historically the interface, not the algorithm, is the bug. Blocking /dev/random, seeding a userspace PRNG, forgetting to reseed after a fork; these are misuses of how you reach randomness, not weaknesses in the math. That is exactly why getrandom and getentropy were designed to be un-misusable.

Note: If you are managing entropy in application code, mixing your own sources, maintaining a userspace pool, reseeding on a timer, you have almost certainly introduced a bug the OS already solved. The correct amount of RNG plumbing in an application is zero. Call getrandom, getentropy, BCryptGenRandom, or your language's CSPRNG wrapper, and stop [@src-getrandom, @src-arc4random].

Note: A version-4 UUID is 122 random bits formatted for uniqueness, not unpredictability, and its specification never promised it would be unguessable or drawn from a CSPRNG [@src-rfc9562]. Using one as a password-reset token, session ID, or API key is betting your security on an implementation detail the standard does not guarantee. For anything security-sensitive, draw CSPRNG bytes directly [@src-rfc4086].

Draw every random value from the OS CSPRNG (`getrandom` / `getentropy` / `BCryptGenRandom` / `secrets` / `crypto/rand`), never a language `random()` or Mersenne Twister. Keys: exact key length from the CSPRNG. GCM nonces: 96-bit counter, or random with a hard cap below $2^{32}$ per key, and if senders are distributed use AES-GCM-SIV. CBC IVs: fresh unpredictable per message, or move to AEAD. Salts: at least 16 bytes, unique per password, stored in the clear. Signature nonces: RFC 6979 deterministic. After any `fork()` or VM snapshot, force a reseed before emitting keys or nonces. Reject any hand-rolled entropy pool.

The rules are short because the thesis is short: for every value you draw, name the property the role owes, and confirm the bytes came from the OS CSPRNG. Answer both and you are out of the catalog. Before the closing, here are the misconceptions that send good engineers back into it.

11. Frequently Asked Questions

The most expensive randomness bugs start as reasonable-sounding beliefs. Here are eight, corrected.

No. After the CSPRNG is seeded once at first boot, both devices draw from the same ChaCha-based generator and are cryptographically identical in the quality of their output; the only remaining difference is that `/dev/random` blocks until that first seeding while `/dev/urandom` does not [@src-donenfeld2022]. The old advice to prefer `/dev/random` for "more secure" keys was based on an entropy-depletion model that does not hold for a modern CSPRNG: a properly seeded generator does not run out of unpredictability by producing output. Use `getrandom()` and stop worrying about which device node to open [@src-random4man]. No, only once. `getrandom()` blocks a single time at first boot until the pool is initially seeded, and then never blocks again for the life of the system [@src-getrandom]. Code that polls an entropy estimate before every draw, or loops waiting for `/dev/random`, is solving a problem that the blocking-once design already solved at the interface. It depends on the mode, and this is the most common confusion in the field. A CTR or GCM nonce must only be *unique*; unpredictability buys nothing there, and a counter is a fine, often safer, choice [@src-sp80038d]. The role that must be *unpredictable* is the CBC IV, whose predictability is exactly what BEAST exploited [@src-cve2011]. Same-looking value, different requirement, set by the mode. No. A salt is unique and random but stored in plaintext right next to the password hash. Its only job is to make identical passwords hash differently so one precomputed table cannot attack many accounts. Treating it as a secret, or reusing one global salt, misunderstands the role: uniqueness is what matters, not secrecy. No. Random 96-bit nonces are bounded by the birthday problem, so a single key should encrypt fewer than about $2^{32}$ messages to keep the repeat probability negligible [@src-sp80038d]. Beyond that, use a monotonic counter, which cannot collide, or AES-GCM-SIV, which tolerates a repeat without catastrophic failure [@src-rfc8452]. Neither extreme is right. Do not trust `RDRAND` *alone*, because it is opaque silicon you cannot audit, but do not refuse it either. The correct posture, the one modern kernels take, is to mix its output into a pool alongside other sources so that no single component is the whole answer [@src-intel-drng]. That is the discipline Dual_EC taught the field [@src-shumow2007]. No. A version-4 UUID is built for uniqueness, and its specification does not require the bits to be unguessable or drawn from a CSPRNG [@src-rfc9562]. For session IDs, reset tokens, and API keys, draw CSPRNG bytes directly instead of relying on a UUID's format [@src-rfc4086]. No. Statistical suites can falsify a generator but never certify one. The Mersenne Twister passes the standard batteries and is completely broken after 624 outputs [@src-mersenne1998]. Test suites catch gross defects; they say nothing about whether an adversary can predict the next bit, which is the only property that matters for cryptography [@src-sp80022].

12. Two Knobs, Two Places

Go back to where we started. Netscape, 1996: the RC4 and RSA math was flawless, and the keys were guessable because the seed was the clock and a couple of process IDs [@src-netscape1996]. Debian, 2008: the algorithm was fine, and roughly two years of keys collapsed to about 32,768 possibilities because one entropy input was removed [@src-debian2008]. You can now name both on sight: predictable, in the generator. That is the whole diagnosis, and it is the same diagnosis for every break in this article.

By now the two knobs and two places should lock together into a single picture. Every value you draw owes one of two properties, unpredictability or uniqueness, and either can be squandered in one of two places: the generator that mints the bits, or the role that spends them (key, nonce, IV, salt). That product, two properties across two places, is the entire fault space, and nothing in this article fell outside it.

What makes randomness uniquely treacherous is that none of those faults trips an alarm. Hand a cipher the wrong key and it errors; forge a MAC and the receiver rejects it. A predictable or repeated value sets off nothing at all: it clears every statistical test and validates cleanly, yet it is already broken for anyone who thought to recompute it. Each disaster we catalogued was one of those four faults, found only in hindsight.

Snap the catalog into the grid one last time. Netscape and Debian: predictable, generator. The PS3's static nonce and the Bitcoin wallets' repeated nonce: repeated, role [@src-fail0verflow2010, @src-android2013]. Dual_EC: predictable, generator, by design [@src-shumow2007]. GCM reuse in TLS: repeated, role [@src-cve2016]. PuTTY's biased P-521 nonce: predictable, role [@src-putty2024]. Four boxes, and every disaster in four decades fits in one of them.

Mastering randomness is not about finding a better source of magic. It is about knowing, for every value you draw, which of the two properties it owes and which of the two places can betray it.

That is the discipline. For every value you draw, name the property the role owes (unique? unpredictable? secret?) and confirm the generator is the OS CSPRNG. The generator half is essentially solved engineering; the failures that remain live in sourcing, in trust, and above all in the roles, where a perfect byte stream still gets you owned if you pour it into the wrong one.

This was Part 2 of the field guide. Part 1 established what "secure" means and why the definitions demand randomized encryption in the first place; later parts take the disciplined bytes you now know how to produce and build the modes, key-encapsulation mechanisms, and signatures that consume them. For the platform-specific instance of everything here, how Windows assembles its CSPRNG and defends it against cloning, the Windows CSPRNG companion article is waiting. Every one of those constructions will hand you a value to generate. Now you know the only two questions to ask of it.

A Key Is Only as Unguessable as the Dice That Made It: Inside the Windows CSPRNG

noreply@paragmali.com (Parag Mali) — Thu, 02 Jul 2026 00:00:00 GMT

Every software secret Windows generates -- DPAPI master keys, BitLocker volume keys, TLS session keys, machine-account passwords -- is drawn from one cryptographic random number generator: a NIST SP 800-90A AES `CTR_DRBG` seeded from many mixed entropy sources and reseeded on a clock schedule [@src-win10rng-pdf]. It is not "true" randomness. It is a deterministic generator whose output is only as unguessable as the entropy behind its seed. Windows learned this the hard way -- its first generator, `CryptGenRandom`, was broken for forward secrecy in 2007 [@src-cryptgenrandom2007], and the industry's `Dual_EC_DRBG` scare proved that an algorithm's own constants can be a back door [@src-shumowferguson2007]. The modern design answers both failures: a kernel-resident root `CTR_DRBG` seeds a strict chain of per-processor generators, mixing enough sources that no single one -- not even Intel's `RDRAND` -- can own the pool, delivered to your process through `ProcessPrng` and `BCryptGenRandom` [@src-processprng; @src-bcryptgenrandom]. The one boundary: keys born inside a TPM or a smart card come from the device's own hardware RNG, not this software CSPRNG.

1. Two Lines of Code That Never Touched the Cipher

In 1996, two Berkeley graduate students broke the encryption on every Netscape SSL session without laying a finger on the cipher. Ian Goldberg and David Wagner never factored a modulus or attacked RC4. They reverse-engineered the browser and found that the "random" seed feeding each session key depended on just three quantities: the time of day, the process ID, and the parent process ID [@src-netscape1996]. Guess those three numbers -- and on a shared Unix host you very nearly could -- and you reconstruct the key directly.

Twelve years later, a change to Debian's OpenSSL did the same thing to a large slice of the internet at once. A well-meaning patch commented out the code that mixed extra data into the key generator's entropy pool, so the private keys a machine produced were drawn from little more than its process ID [@src-debian2008]. Every SSH host key, TLS certificate, and OpenVPN key generated on an affected system fell into a tiny, enumerable set, and the flaw sat in shipping code from September 2006 until its disclosure in May 2008 [@src-cve20080166].

Notice what did not fail in either case. RSA was fine. RC4 was fine. The math was flawless and the keys were still guessable, because a key is only as unguessable as the randomness underneath it. That is the single idea this article is built on, and it is not a story about Netscape or Debian. It is the story of every secret your operating system makes.

On Windows, that surface is enormous. DPAPI master keys, BitLocker volume keys, TLS session keys, and machine-account passwords are all drawn -- when they are generated in software -- from a single cryptographic random number generator buried in the kernel. Their security bottoms out on how well Windows rolls the dice. Get that generator right and a thousand higher-level protocols inherit unpredictability for free. Get it wrong, once, and every one of them silently weakens at the same time.

Goldberg and Wagner's 1996 write-up derives the figure directly: with only the wall-clock second known (from a packet sniffer) but the microseconds, process ID, and parent process ID unknown, the seed retains "at most, 47 bits of randomness in the secret key," and in practice often far fewer [@src-netscape1996].

The Debian break is usually summarized as collapsing keys to "about 32,768 possibilities." That number is a derived consequence, not text from the advisory: the change commented out two MD_Update calls that fed the pool, leaving process-ID as effectively the only varying input, and a 15-bit PID space is $2^{15}$, or 32,768 values [@src-debian2008; @src-cve20080166].

So the questions that organize the rest of this piece almost ask themselves. What would it actually take to build randomness an attacker cannot guess? Has Windows ever failed at it? And when it rebuilt, what design did it land on -- and where does that design stop?

timeline title From "looks random" to "is unpredictable" 1982 : Blum and Micali introduce the unpredictability criterion and first provable PRG 1982 : Yao proves unpredictability = indistinguishability 1996 : Netscape SSL seed reconstructed 2006 to 2008 : Debian OpenSSL entropy stripped 2007 : CryptGenRandom forward-security break 2007 : Dual_EC_DRBG back door demonstrated 2012 : VM Generation ID ships for clone detection 2014 : NIST removes Dual_EC_DRBG 2019 : Windows CTR_DRBG tree documented 2025 : NIST finalizes SP 800-90C

2. What "Random" Has to Mean

Here is a claim that sounds wrong the first time you hear it: passing every statistical randomness test in existence is not good enough for keys. A sequence can be perfectly balanced, survive every chi-squared and spectral test you throw at it, and still be catastrophic to build a secret on.

The Mersenne Twister makes the point. It is a superb general-purpose generator with a period of $2^{19937}-1$ and excellent statistical properties, and it is the default rand-style source in countless languages. Its own authors are blunt about the limit: "Mersenne Twister is basically for Monte-Carlo simulations. It is not cryptographically secure as is" [@src-mt]. The reason is that its internal state is a linear function of its output, held in a working area of just 624 words [@src-mtpaper]. Observe 624 consecutive 32-bit outputs and you can solve for the entire state, then predict every future value. It looks random to a statistician and is transparent to a cryptanalyst.

That gap forces a three-way distinction that the rest of this article leans on constantly.

A physical process that produces genuine unpredictability -- thermal noise, ring-oscillator jitter, the timing of hardware interrupts. A true random number generator (TRNG) samples such a process. It is slow, sometimes biased, and cannot be reproduced from a formula, which is exactly why it is trusted as a source of fresh unpredictability. An algorithm that stretches a short seed into a long stream of output bits. Given the same seed it always produces the same stream, so it creates no new unpredictability; it spreads out the unpredictability already present in the seed. NIST SP 800-90A defines the DRBG mechanisms Windows uses [@src-sp80090a]. A DRBG whose output no efficient adversary can distinguish from uniformly random bits, even after seeing any feasible, polynomially bounded amount of prior output. The Mersenne Twister is a PRNG but not a CSPRNG; a `CTR_DRBG` is designed to be one.

A real system needs both halves: an entropy source to supply unpredictability, and a DRBG to turn a trickle of it into all the fast, uniform bytes applications demand. Confusing the two is how you ship a generator that benchmarks beautifully and leaks keys.

Property	Entropy source (TRNG)	CSPRNG (secure DRBG)	Non-crypto PRNG
Origin of bits	physical noise	a seed plus an algorithm	a seed plus an algorithm
Reproducible from state?	no	yes	yes
Speed	slow	fast	fast
Safe for keys?	yes, but rate-limited	yes	no
Example	RDSEED, interrupt jitter	AES `CTR_DRBG`, ChaCha20	Mersenne Twister, C `rand()`

Note: rand(), random(), and the Mersenne Twister are built for simulations and games, not keys. Their state is recoverable from their output [@src-mt]. Anything that must be unpredictable to an adversary needs a CSPRNG, never a general-purpose PRNG.

The bar that replaced "looks random"

What separates a CSPRNG from a Mersenne Twister was pinned down theoretically before either Windows generator existed. In 1982, Manuel Blum and Silvio Micali introduced the next-bit unpredictability criterion: a generator is cryptographically strong if no efficient adversary, given any prefix of the output, can predict the next bit with advantage better than negligible. They did more than state the bar -- they showed it was reachable, constructing a PRG whose output meets it as long as a specific hard problem (the discrete logarithm) stays hard, via a hardcore predicate that is provably as difficult to guess as inverting a one-way function [@src-blummicali1984]. It was the first pseudorandom generator with a security proof rather than a hope.

That same year, Andrew Yao proved why the next-bit test is the right bar: a generator passes it if and only if its output is computationally indistinguishable from a uniform random string -- no efficient statistical test of any kind can tell them apart [@src-yao1982]. Unpredictability and indistinguishability are the same property. Yao's theorem generalized the Blum-Micali criterion into the definition of "cryptographically random," replacing the vague "looks random" with something you can reason about. Every DRBG since, including Windows' CTR_DRBG, is a descendant of that idea.

The worst-case measure of unpredictability. For a source $X$, the min-entropy is $H_\infty(X) = -\log_2 \max_x \Pr[X = x]$ -- it counts only the single most likely outcome. If the likeliest value has probability one in a thousand, the source has just under 10 bits of min-entropy, no matter how the rest of the distribution looks. Min-entropy upper-bounds the security of everything drawn from a seed.

Two derived properties matter so much that the entire modern design is organized around them, and every generator in this article is graded on both.

If an attacker compromises the generator's state right now, they still cannot recover the output it produced in the past. The state update must be a one-way step. In NIST's vocabulary this is "backtracking resistance"; the academic literature usually calls the same property "forward security." If an attacker learns the state now, fresh entropy mixed in afterward makes future output unpredictable again. Prediction resistance is what lets a generator *recover* from a compromise, and it is the entire reason a generator reseeds rather than running forever on its first seed.

You can watch why a weak seed is fatal in a few lines. When the seed comes from a small space, an attacker does not attack the cipher; they enumerate the seeds and derive the key directly, exactly as in the Debian case.

{` // A toy key derivation. Pretend the hex output is a real 256-bit key. function keyFromSeed(seed) { let h = seed >>> 0; h = Math.imul(h, 2654435761) >>> 0; // a deterministic mix h = (h ^ (h >>> 15)) >>> 0; return h.toString(16).padStart(8, "0"); }

// The Debian OpenSSL bug effectively drew the seed from the PID space: // 2^15 = 32768 possibilities per key type, not 2^256. const PID_SPACE = 32768; const victimSeed = 20443; // the victim's unknown PID const targetKey = keyFromSeed(victimSeed);

let guesses = 0, recovered = null; for (let pid = 0; pid < PID_SPACE && recovered === null; pid++) { guesses++; if (keyFromSeed(pid) === targetKey) recovered = pid; }

console.log("target key:", targetKey); console.log("recovered the seed in", guesses, "guesses"); console.log("keyspace searched: 2^15 =", PID_SPACE, "-- trivially enumerable"); `}

Windows built a generator on exactly these terms, CryptGenRandom, the generator it shipped in the CryptoAPI. Three researchers later took the Windows 2000 build of it apart -- and found it failed the first property outright.

3. The First Windows Generator, and How It Broke

In 2007, Leo Dorrendorf, Zvi Gutterman, and Benny Pinkas did something Microsoft had never published: they reconstructed the algorithm behind Windows' random number generator by reverse-engineering a Windows 2000 binary, with no help from the vendor. Then they broke it [@src-cryptgenrandom2007]. The target was CryptGenRandom, the generator that at the time sat under essentially every Windows secret, and the flaws they found were structural, not arithmetic.

Three design choices did the damage. First, the generator ran entirely in user mode, with a separate copy of its state living inside each process's own address space. Second, part of that state at startup was simply whatever happened to be sitting on the stack. Third, and most damaging, the generator pulled fresh system entropy into its state only after it had produced 128 KB of output. Between those refreshes, the output was a pure deterministic function of a state that never changed its unpredictability.

With the algorithm in hand, the attack followed. Given the generator's current internal state, the researchers showed the previous state could be recovered in about $O(2^{23})$ work -- a break of forward security -- while running the generator forward to predict future output was trivial, $O(1)$ [@src-cryptgenrandom2007]. Because state was per-process and reseeded so rarely, a single state leak was not a local event. It reached backward and forward across the whole 128 KB window.

"Learning a single state may reveal 128 Kbytes of the past and future output of the generator." -- Dorrendorf, Gutterman, and Pinkas, 2007 [@src-cryptgenrandom2007]

For a process terminating a TLS connection, 128 KB of predictable output is more than enough to expose the session keys it just generated, or is about to. The cipher suite did not matter. The break was in the dice.

flowchart TD A["CryptGenRandom runs in user mode, one state per process"] --> B["Generator state lives in the process address space"] B --> C["System entropy mixed in only after 128 KB of output"] C --> D["Attacker leaks a single internal state"] D --> E["Recover the previous state in about 2 to the 23 work"] D --> F["Run forward to predict future output in constant work"] E --> G["Reconstruct the process's SSL and session keys"] F --> G

The asymmetry is worth savoring: predicting future output from a known state was $O(1)$, because that is just running the generator, while recovering past output cost $O(2^{23})$ -- the work of inverting one step. A truly forward-secure design makes the second number astronomically large. CryptGenRandom made it a rounding error [@src-cryptgenrandom2007].

Two points of discipline before we move on. This break is strictly a property of the legacy CryptGenRandom, the generator Windows shipped in its CryptoAPI, analyzed here in its Windows 2000 build. It is not the modern CTR_DRBG design that replaced it, and nothing here should be read as a live vulnerability in a current Windows system.

The value of the story is that it names, concretely, the four things a redesign had to fix: get the state out of user-mode process memory, reseed far more often than every 128 KB, stop seeding from uninitialized stack data, and make the state update genuinely one-way so a leak cannot reach into the past.

The fix looked obvious on paper. Move the state into the kernel, reseed on a schedule, make it forward-secure. But at the very moment Microsoft was redesigning, a deeper and more unsettling fear surfaced across the whole field. What if the weak point was not the code at all -- what if the algorithm itself, blessed by a standards body, was the trap?

4. The Dual_EC_DRBG Shadow

In 2006, NIST standardized four DRBG mechanisms in Special Publication 800-90: Hash_DRBG, HMAC_DRBG, CTR_DRBG, and a fourth built on elliptic curves called Dual_EC_DRBG [@src-sp80090-2006; @src-nistremoval2014]. Three of them were ordinary constructions built from hash functions and block ciphers. The fourth carried a landmine, and in August 2007 two Microsoft cryptographers walked up to the CRYPTO rump session and pointed at it.

Dan Shumow and Niels Ferguson showed that Dual_EC_DRBG is defined by two elliptic-curve points, $P$ and $Q$, whose relationship is a secret. If anyone knows a scalar $d$ with $d\cdot P = Q$, that number is a skeleton key. In their experiments, "32 bytes of output was sufficient to uniquely identify the internal state" -- after which every future output is predictable [@src-shumowferguson2007]. The constants shipped in the standard, and no one outside their authors could say how $P$ and $Q$ had been chosen. The generator could be perfect for everyone except the one party holding $d$.

They were scrupulous about what they were and were not claiming, and their exact wording is a model of how to raise an alarm honestly.

"WHAT WE ARE NOT SAYING: NIST intentionally put a back door in this PRNG. WHAT WE ARE SAYING: The prediction resistance of this PRNG (...) is dependent on solving one instance of the elliptic curve discrete log problem." -- Shumow and Ferguson, 2007 [@src-shumowferguson2007]

For years this stayed a theoretical worry. Then in 2013, reporting by Joseph Menn at Reuters, drawing on the Snowden documents, alleged that RSA Security had accepted a secret $10 million contract that set Dual_EC_DRBG as the default generator in its widely used BSAFE toolkit [@src-reuters2013]. The theoretical trapdoor now had a deployment path into real products.

NIST reopened the standard for comment in September 2013 and, in 2014, formally removed Dual_EC_DRBG, keeping "three of the four previously available options" and urging users to "transition (...) as quickly as possible" in response to "the lack of public confidence" [@src-nistremoval2014]. A standards body had withdrawn one of its own algorithms because it could no longer vouch for it.

Where did Windows sit in this? The precise, defensible statement is this: Windows shipped Dual_EC_DRBG as a non-default SP 800-90 option -- available if an application explicitly asked for it, but never the system default -- and later removed it [@src-msdualec]. That is a materially different posture from BSAFE, where the reporting alleges it was the default. Naming this accurately matters more than scoring a point: the lesson of Dual_EC is not "vendor X was careless," it is that trust in a generator bottoms out on its algorithm and its constants, not merely on whether the code has bugs.

Niels Ferguson is not a bystander in this story; he is the thread that ties it together. He co-presented the Dual_EC back-door result in 2007. Years earlier he co-designed Fortuna, the multi-pool reseeding generator whose pattern Windows would adopt [@src-fortuna]. And in 2019 he authored the whitepaper documenting the modern Windows generator [@src-win10rng-pdf]. The person who showed most vividly that a standardized DRBG could betray you is the same person who later wrote down how Windows arranges never to trust any single one. That is not a coincidence -- it is the design philosophy made personal.

So the field learned the same lesson twice in the span of a few years, from two directions. CryptGenRandom proved that a generator's structure could betray it. Dual_EC proved that a generator's algorithm and constants could betray it. When Microsoft rebuilt from scratch, it had to answer both at once: which mechanism do you pick, and how do you arrange the whole system so that no single component -- no algorithm, no constant, no hardware chip -- can quietly own the result?

5. The Modern Architecture: One Root, a Strict Chain of Generators

The redesign that answers both failures fits in a single sentence, and it is worth stating before the diagram. Ferguson's 2019 whitepaper on the Windows generator [@src-win10rng] puts it flatly:

"All PRNGs in the system are SP800-90 AES_CTR_DRBG with 256-bit security strength using the df() function." -- Niels Ferguson, The Windows 10 random number generation infrastructure, 2019 [@src-win10rng-pdf]

Every generator in Windows is the same mechanism, an AES CTR_DRBG at the maximum 256-bit strength. What differs is how they are wired together. Before the wiring, here is the road that led to it.

Generation	Representative design	Why it was superseded
G0 -- non-crypto PRNG	C `rand()`, Mersenne Twister	Linear state recoverable from output [@src-mt]
G1 -- ad-hoc app CSPRNG	Netscape SSL seed from clock and PID	Too little entropy; seeds enumerable [@src-netscape1996]
G2 -- legacy `CryptGenRandom`	User-mode, per-process DRBG	Forward-security break; reseed only per 128 KB [@src-cryptgenrandom2007]
G3 -- SP 800-90 DRBG menu	Standardized `CTR_DRBG` and siblings	A menu is not an architecture; Dual_EC withdrawn [@src-nistremoval2014]
G4 -- modern Windows tree	Root `CTR_DRBG` seeding a strict chain of per-processor DRBGs	Current design [@src-win10rng-pdf]

The wiring is a strict, one-way chain. At the top sits a single root generator that lives in kernel mode, maintained by the CNG.SYS driver, whose primary job is to seed other generators -- in the rare case a per-processor state cannot be allocated, a kernel-mode request is served directly from the root [@src-win10rng-pdf]; it never hands bytes to an application. Ferguson's whitepaper is unambiguous about its reach: "All random bytes in the system are derived in some way from this PRNG" [@src-win10rng-pdf]. Below the root are the kernel per-processor generators, also in CNG.SYS, allocated on demand and seeded from the root.

Each user-mode process then gets a process-base generator, maintained by BCryptPrimitives.dll; when that DLL loads it "requests a random seed from kernel mode, where it is produced by the per-CPU states" [@src-win10rng-pdf], so it is seeded from the kernel per-processor generators, not directly from the root. Finally, the user-mode per-processor generators that actually service your calls are created on demand and seeded from the process-base generator.

So the seeding lineage runs in exactly one direction, top to bottom, and only that last layer hands bytes to your code. A request for randomness draws from the bottom of the chain; fresh seed material only ever flows downward from the top. There is no diamond and no shortcut -- a user-mode generator can never read the root or the kernel state directly.

flowchart TD ES["Mixed entropy sources"] --> ROOT["Root CTR_DRBG in CNG.SYS, seeds the generators below it"] ROOT --> KP["Kernel per-processor CTR_DRBGs, also in CNG.SYS"] KP --> PB["Process-base CTR_DRBG in BCryptPrimitives.dll"] PB --> UP["User-mode per-processor CTR_DRBGs"] UP --> APP["ProcessPrng hands bytes to your process"]

Why per-processor, and why a root that only seeds? Three reasons, each a direct answer to a past failure. A per-processor generator needs no lock on the hot path, so thousands of threads can draw bytes at once without contending. Each processor's state is isolated from the others, so leaking one tells you nothing about the rest. And because each layer is seeded from the one above rather than sharing its state, a compromise of a user-mode generator on one core cannot walk back up to the kernel generator or across to another core.

The reachability that let one CryptGenRandom state expose 128 KB of a process's keys is designed out.

Note: The two structural moves -- a root generator whose main job is to seed the generators below it, and a separate CTR_DRBG per processor -- are not performance tricks that happen to help security. They are the security. They ensure no single leaked state, and no single hot lock, sits on the path between your key and everyone else's [@src-win10rng-pdf].

How a CTR_DRBG actually works

The SP 800-90A DRBG built from a block cipher run in counter mode. Its state is a cipher key $K$ and a counter $V$. To produce output it encrypts successive counter values under $K$; after each request it runs an update step that replaces both $K$ and $V$. Windows uses AES with a 256-bit key, giving a combined seed length of 384 bits [@src-sp80090a-pdf].

Mechanically it is simpler than its reputation. The state is a key $K$ and a counter block $V$. To generate output, the DRBG increments the counter before each block and encrypts the result under AES with key $K$: the first output block is $\text{AES}(K, V+1)$, the next is $\text{AES}(K, V+2)$, and so on, exactly like running AES in counter mode. Because the increment comes first, the block for the current $V$ is never emitted. For AES-256 the seed length -- the size of $K$ and $V$ together -- is 384 bits: a 256-bit key plus a 128-bit counter block [@src-sp80090a-pdf].

The step that earns the "cryptographically secure" label comes after the bytes are handed back. The DRBG runs an update that derives fresh values for $K$ and $V$ and overwrites the old ones. Once that happens, the state that produced your bytes no longer exists anywhere. Recovering it would mean inverting AES, which is exactly the work the cipher is built to make infeasible. That single overwrite is what gives the whole chain its backtracking resistance -- the property CryptGenRandom lacked.

sequenceDiagram participant App as Caller participant D as CTR_DRBG state K and V App->>D: Request random bytes D->>D: Increment the counter, then encrypt under AES to produce each output block D-->>App: Return the output bytes D->>D: Update step derives and overwrites a fresh K and V Note over D: The old K and V are destroyed, so past output cannot be recomputed

Before those raw entropy bytes ever become a key $K$, they pass through a conditioning step the standard calls the derivation function.

The conditioning step that turns raw entropy of uneven quality into a seed of exactly the length and distribution the DRBG needs. It absorbs more input bits than it emits, spreading whatever unpredictability arrived across every output bit, so no structure in the raw source survives into the seed [@src-sp80090a].

You can feel the forward-secrecy property in a few lines. The key move is that the update overwrites the state with the output of a one-way step, so a later leak cannot walk backward.

{` // A toy generator with a one-way update, mirroring the CTR_DRBG idea. // Real Windows uses AES; here a simple one-way mix stands in for it. function mix(x) { let h = x >>> 0; h = Math.imul(h ^ 0x9e3779b9, 2246822519) >>> 0; h = (h ^ (h >>> 13)) >>> 0; return h >>> 0; }

let state = 123456789; // the secret internal state

function generate() { const output = mix(state ^ 0x0000abcd); // the bytes we hand out state = mix(state); // update: overwrite the state return output >>> 0; }

const out1 = generate(); const out2 = generate(); const leakedNow = state; // attacker compromises the state here

console.log("output 1:", out1.toString(16)); console.log("output 2:", out2.toString(16)); console.log("state leaked after two draws:", leakedNow.toString(16)); console.log("to recover out1 the attacker must invert the update -- that is forward secrecy"); `}

The implementation behind all of this is SymCrypt, which the project describes as "the primary crypto library for all algorithms" in Windows since the Windows 10 1703 release, engineered to "support FIPS 140 certification" and to "provide high assurance" [@src-symcrypt]. The generator is not a bespoke one-off; it is part of the same audited library that implements the rest of Windows cryptography.

This chain-of-generators shape now has a standardized name. NIST's SP 800-90C, finalized on 25 September 2025, calls a chain of RBGs on one platform -- each an RBG (a DRBG mechanism plus its seeding interface), one feeding the next -- an RBGC construction, the standardized shape that the Windows root-to-per-processor arrangement instantiates as CTR_DRBGs [@src-sp80090c; @src-nist90cnews2025]. That standard was finalized six years after Ferguson's 2019 whitepaper documented the Windows tree, so the correspondence is a retrospective analogy rather than a certified conformance to SP 800-90C. We return to the full SP 800-90 construction family, and what it can and cannot promise, in Section 10.

The architecture facts in this article -- the chain, the 256-bit CTR_DRBG, the df() seeding, and the reseed numbers in the next section -- are quoted from Ferguson's whitepaper, which is a Windows 10 document published in October 2019. They are accurate as documented in 2019; Microsoft has not published a newer primary of comparable detail, so treat the exact figures as of that vintage [@src-win10rng-pdf].

Line the redesign up against the two failures. CryptGenRandom ran in user mode; the modern root and kernel generators live in the kernel, out of any process's reach. CryptGenRandom reseeded only every 128 KB; the modern chain reseeds on a clock schedule, which the next section unpacks. CryptGenRandom let a leaked state expose the past; the CTR_DRBG update overwrites $K$ and $V$ so the past is gone. And against Dual_EC, the mechanism itself is AES in counter mode, whose security rests on the block cipher rather than on two mysterious curve points nobody can audit.

Key idea: A DRBG cannot create unpredictability. It can only stretch a seed. So a Windows key is only as unguessable as the entropy behind that seed, which is why the entire architecture is built to protect and diversify the seed rather than to strengthen the cipher.

A CTR_DRBG is deterministic: feed it the same seed and it produces the same "random" stream forever. Everything, then, rests on one question the whole design has been circling. Where does the unpredictability in that seed actually come from?

6. Where the Entropy Comes From

A deterministic generator cannot manufacture unpredictability. It can only spend what it is given. So the design problem is not "how do we make randomness" -- the CTR_DRBG does the stretching -- it is "how do we collect genuine unpredictability, from sources diverse enough that no one of them can quietly poison the well." Windows answers by gathering entropy from everywhere it can reach and trusting no single source in particular.

The whitepaper enumerates the sources, and the list is deliberately not exhaustive [@src-win10rng-pdf]. The primary source is the timing jitter of hardware interrupts, sampled with the CPU's cycle counter via the RDTSC instruction: the exact cycle at which each interrupt fires is influenced by physical processes an outside attacker cannot observe or steer.

Alongside it, Windows pulls bytes from the TPM (documented as 40 bytes at boot and 64 bytes per reseed, at most once every 40 minutes or so), from Intel's on-die RDRAND and RDSEED instructions, from a seed file kept in the registry and rewritten on each boot to carry entropy forward across restarts, from UEFI and firmware seeds, and on virtual machines from the Hyper-V ACPI OEM0 table [@src-win10rng-pdf].

Source	Type	Cadence (as documented in 2019)	Trust note
Interrupt timing via `RDTSC`	timing jitter	continuous; the primary source	Hard to observe or steer remotely [@src-win10rng-pdf]
TPM	hardware RNG	40 bytes at boot, 64 bytes per reseed, at most once per ~40 min	Separate chip, independent of the CPU [@src-win10rng-pdf]
`RDRAND` / `RDSEED`	on-die hardware RNG	on demand	`RDRAND` capped at 128-bit security; `RDSEED` preferred; never trusted alone [@src-win10rng-pdf]
Registry seed file	stored entropy	read at boot, rewritten for next boot	Carries entropy across reboots [@src-win10rng-pdf]
UEFI / firmware seed	firmware-provided	at boot	Platform-dependent [@src-win10rng-pdf]
Hyper-V ACPI OEM0 table	hypervisor-provided	at boot on guests	Present for virtualized machines [@src-win10rng-pdf]

Mix many, trust none

This is the direct, engineered answer to the Dual_EC fear. Consider Intel's RDRAND: it is fast, on-die, and convenient, and a lazier design would simply use it as the system's randomness. Windows does not. The whitepaper notes that "the RDRAND instruction only provides random numbers with a 128-bit security level," so Windows uses RDSEED "in preference to RDRAND" and, more importantly, folds it in as one input among many rather than relying on it alone [@src-win10rng-pdf].

The underlying Intel design is itself an entropy source feeding a conditioner and a CTR_DRBG [@src-inteldrng] -- a whole pipeline sealed inside a chip you cannot audit. Mixing it with five other independent sources means that even if RDRAND were compromised or backdoored, it could not by itself determine the seed.

The 128-bit ceiling is the tell. Windows targets 256-bit security throughout, so a source that tops out at 128 bits can never be the whole seed without halving the system's strength. That is a concrete, non-conspiratorial reason to prefer RDSEED and to always blend -- the mathematics forces diversification before trust ever enters the picture [@src-win10rng-pdf].

flowchart LR A["Interrupt and RDTSC timing jitter (primary)"] --> P["SHA-512 entropy pools, up to 8"] B["TPM random bytes"] --> P C["RDRAND and RDSEED"] --> P D["Boot seed file from the registry"] --> P E["UEFI and firmware seed"] --> P F["Hyper-V ACPI OEM0 table"] --> P P --> R["Seed for the root CTR_DRBG"]

The mixing itself is a hash. Sources are folded with SHA-512 into as many as 8 entropy pools, and the very first seeding happens early, in the boot loader. During Winload, Windows hashes the available sources with SHA-512, uses the result to seed an AES CTR_DRBG, and hands 48 bytes to CNG so the kernel generator is already seeded before any user code runs [@src-win10rng-pdf].

There is no window in which Windows serves keys from an unseeded generator -- the boot-time hole that broke so many Unix devices. The design of these entropy sources, their health tests and min-entropy estimates, is governed by NIST SP 800-90B, the companion standard to the DRBG document [@src-sp80090b].

That completes the second shift in how to think about this machine: security does not come from finding one perfect source of randomness. It comes from combining many imperfect ones so that trusting any single component is never necessary. Distrust is the feature.

Collecting entropy once, though, is not enough. A generator that seeds at boot and never refreshes slowly drifts back toward the failure that killed CryptGenRandom -- a long-lived state that, once leaked, stays leaked. So when, and how often, does Windows reseed? And what happens the moment two machines start life from the exact same state?

7. Reseeding, Forward Secrecy, and the VM-Clone Problem

Reseeding is easy to misunderstand as "topping up" a tank of randomness that slowly drains. It is not. A CTR_DRBG never runs out of output. Reseeding exists for a different reason: it is how a generator recovers from a compromise it may never know occurred. If an attacker somehow learns the state, mixing in fresh entropy afterward restores unpredictability going forward. That is prediction resistance, and it is why reseeding is on a schedule rather than an afterthought.

The schedule, as documented in the 2019 whitepaper, is descended from Fortuna -- the multi-pool accumulator Ferguson co-designed as a successor to Yarrow [@src-yarrow], which itself grew out of a 1998 taxonomy of how real pseudorandom generators get broken in the field [@src-prngattacks1998]. The first reseed is scheduled about 1 second after boot. Each subsequent interval is tripled, up to a cap of 3600 seconds -- one hour -- with roughly 33% jitter so the timing is not perfectly regular [@src-win10rng-pdf].

Underneath sits a bank of up to 8 SHA-512 entropy pools, and pool $k$ is drained into a reseed only every $3^k$-th time. Pool 0 contributes to every reseed; pool 1 to every third; pool 7 only very rarely. The effect of that geometric schedule is subtle and clever: a fast, low-rate attacker who is quietly injecting predictable "entropy" cannot keep all pools poisoned, because the high-numbered pools accumulate real entropy over long stretches before they are ever used [@src-win10rng-pdf].

Map this onto the two properties from Section 2. The CTR_DRBG update gives backtracking resistance: a leaked state cannot reveal past output. Reseeding gives prediction resistance: a leaked state cannot predict output past the next reseed. Together they bound the blast radius of a state compromise in both directions of time. The standard also caps a single CTR_DRBG at $2^{48}$ generate requests before a reseed is mandatory, though Windows' clock schedule reseeds far more often than that ceiling would ever require [@src-sp80090a-pdf].

That $2^{48}$ figure is a hard limit in SP 800-90A, not a Windows tuning choice. At any realistic request rate the one-hour clock reseed fires enormously sooner, so the ceiling is a safety backstop rather than an operational parameter [@src-sp80090a-pdf].

The failure reseeding cannot fully fix

There is one deployment scenario that defeats even a perfect reseed schedule, and it is the sharpest residual edge in the whole design. If you clone a virtual machine, or revert one to a snapshot, you duplicate its memory -- including the generator's state. Two machines that believe they are independent now hold the identical $K$ and $V$, and they will produce the identical "random" stream. They roll the same dice.

This is not hypothetical. Thomas Ristenpart and Scott Yilek demonstrated in 2010 that resuming a VM from a snapshot replays RNG state and causes servers to emit the same "random" TLS and DSA values twice, leaking keys [@src-ristenpart2010; @src-ristenpart2010-pdf]. Everspaugh and colleagues extended it to the Linux system RNG in 2014, measuring generators on Xen, VMware, and EC2 that would "output the exact same sequence of bits each time it is resumed from the same snapshot" [@src-whirlwind2014].

A 128-bit value supplied by the hypervisor that changes whenever a virtual machine experiences a time-shift event -- a snapshot restore, a clone, or a backup restore. Guest software reads it, and a change signals that the machine may be a duplicate that must reseed. Introduced with Windows 8 and Windows Server 2012 [@src-vmgenid].

Windows' defense is to listen for exactly that event. The VM Generation ID is a 128-bit identifier the hypervisor changes on any time-shift [@src-vmgenid]. The whitepaper's "virtual machine rewind" logic detects the change, retrieves "a unique (not random) value from the hypervisor," and forces the root generator to reseed so the two instances diverge [@src-win10rng-pdf]. Crucially, Ferguson is candid that this "does not eliminate the vulnerability" [@src-win10rng-pdf] -- it narrows it.

flowchart TD A["VM is cloned or reverted to a snapshot"] --> B["Both instances resume with identical generator state"] B --> C{"Did the VM Generation ID change?"} C -->|Yes| D["Root generator reseeds, the two states diverge"] C -->|No| E["Both instances roll identical dice"] E --> F["Residual window: any secret made here may repeat on the twin"]

Where does the residual risk live? In two gaps. First, in the sliver of time after a clone but before the reseed fires, any secret generated draws on duplicated state. Second, on hypervisors that expose no Generation ID at all, the signal never arrives and the duplication is silent. Precisely quantifying that window for current Windows is not something any primary source pins down -- this is a reasoned consequence of the reseed-on-rewind mechanism and the reset results above, not a measured figure. The honest summary is that the VM-clone problem is mitigated, not solved.

Note: A virtual machine that is cloned or rolled back on a hypervisor that does not expose a VM Generation ID can emit the same "random" values more than once -- a direct route to duplicated TLS, SSH, or signing keys. If you snapshot and clone Windows VMs, confirm your hypervisor surfaces a Generation ID [@src-whirlwind2014; @src-win10rng-pdf].

All of this machinery lives in the kernel and the boot loader, far below anything an application sees. So how does ordinary code -- your code -- actually reach down and pull bytes out of it?

8. The User-Mode Path: ProcessPrng and BCryptGenRandom

Everything so far has been under the floorboards. Here is the single line of code that touches it -- and, just as important, the three that you must never write.

The modern entry point is ProcessPrng, exported from bcryptprimitives.dll through the CngRngExt API set. Microsoft's documentation is refreshingly terse: it "retrieves a specified number of random bytes from the user-mode per-processor random number generator," and it "always returns TRUE" [@src-processprng]. There is no failure path to check and no entropy to supply, because the generator it reads from is one of the user-mode per-processor CTR_DRBGs from Section 5, seeded during your process's startup from the kernel chain (the process-base generator requests a kernel seed when bcryptprimitives.dll loads, and the kernel chain itself was seeded at boot, before any process ran). You ask for bytes; you get unpredictable bytes.

Most code should call BCryptGenRandom, the recommended CNG randomness API. Two flags shape its behavior, and one of them is a trap. Passing BCRYPT_USE_SYSTEM_PREFERRED_RNG selects the system's preferred generator, and when you use it the algorithm handle must be NULL [@src-bcryptgenrandom]. The trap is BCRYPT_RNG_USE_ENTROPY_IN_BUFFER, which once let a caller stir its own bytes into the request: the documentation states plainly that "this flag is ignored in Windows 8 and later" [@src-bcryptgenrandom]. Your hand-supplied entropy does nothing, and the API quietly stopped pretending otherwise.

The older names still work, because they were rerouted rather than reinvented. RtlGenRandom -- exported from advapi32.dll as SystemFunction036 -- now carries a Microsoft note telling callers to "use the BCryptGenRandom or ProcessPrng functions" instead [@src-rtlgenrandom], and Ferguson's whitepaper states outright that "RtlGenRandom uses the ProcessPrng function" [@src-win10rng-pdf]. The legacy CryptGenRandom and the C runtime's rand() are deprecated for anything security-sensitive -- the first for its history, the second because it was never a CSPRNG at all.

On .NET, System.Security.Cryptography.RandomNumberGenerator wraps this same machinery: on Windows its implementation calls BCryptGenRandom(IntPtr.Zero, ..., BCRYPT_USE_SYSTEM_PREFERRED_RNG), so managed code inherits the identical guarantees without touching a P/Invoke [@src-dotnet-rng; @src-bcryptgenrandom].

Windows is not alone in converging on a two-layer, forward-secure system RNG. Linux exposes `getrandom(2)`, which draws from the kernel urandom source and blocks until the pool is initialized unless `GRND_NONBLOCK` is set [@src-getrandom]. OpenBSD's `arc4random` family "was replaced with the ChaCha20 cipher" in OpenBSD 5.5 and is "re-seeded from the kernel random(4) subsystem using getentropy(2) on a regular basis, and also upon fork(2)"; its `arc4random_uniform` avoids the modulo bias that trips up naive `% n` reductions [@src-arc4random]. Both lean on the fast-key-erasure construction Daniel J. Bernstein describes, which overwrites the key immediately after use -- "in NIST terminology, it is a failure of backtracking resistance" that erasure prevents [@src-djbrandom]. Different cipher, same shape: collect entropy, key a fast generator, erase forward.

The head-to-head is worth seeing in one place, because it shows that the interesting differences are architectural, not about who has the better cipher.

Dimension	Windows CNG chain	Linux `getrandom`	OpenBSD/FreeBSD `arc4random`	Fortuna (pattern)
Output core	AES `CTR_DRBG`, 256-bit	ChaCha20	ChaCha20	block cipher
Forward secrecy	DRBG update step	fast-key-erasure	fast-key-erasure	DRBG update
Concurrency	per-processor state	per-CPU state	per-process pool	not specified
VM-reset defense	VM Generation ID reseed	improving over time	reseed on `fork()`	not specified
Primary API	`BCryptGenRandom` / `ProcessPrng`	`getrandom(2)`	`arc4random_buf`	not applicable

Sources for the table: the Windows column from Ferguson's whitepaper and the CNG docs [@src-win10rng-pdf; @src-processprng]; Linux from getrandom(2) [@src-getrandom]; OpenBSD/FreeBSD from arc4random(3) [@src-arc4random; @src-arc4random-freebsd]; Fortuna from its design page [@src-fortuna]. The standout row is VM-reset defense: Windows is unusual in having an explicit hypervisor-signaled reseed, a direct consequence of the clone problem in the last section.

One API, one per-processor CTR_DRBG, one shared foundation. Which means we can finally close the loop: every secret Windows makes in software is drawing from the same well. Let us follow the pipes and see exactly which secrets those are -- and the one place the pipes do not reach.

9. How Every Windows Secret Draws on This -- and Where It Doesn't

Now the loop closes. Trace almost any Windows secret back far enough and you arrive at the same per-processor CTR_DRBG from Section 5. The generator is not one feature among many; it is the shared root of the whole key hierarchy.

Here is the claim stated precisely, because precision is what makes it defensible rather than a slogan. BCryptGenRandom and ProcessPrng are the CNG software CSPRNG -- Cryptography API: Next Generation, the subject of the companion post on CNG architecture, has no second random source hiding behind them. And the whitepaper is explicit that the root generator's reach is total: "All random bytes in the system are derived in some way from this PRNG" [@src-win10rng-pdf; @src-processprng].

So the linkage from any subsystem to the Section 5 chain is architectural, not a claim that each component calls BCryptGenRandom at some named line: on modern Windows, CNG is the sole software CSPRNG, so any key or nonce generated in software bottoms out in that chain by construction.

With that framing, the dependencies fan out, and each one has a primary source confirming its key material is randomly generated.

DPAPI and DPAPI-NG, the credential vault under nearly every stored Windows secret: classic DPAPI builds on a MasterKey that Microsoft documents as "512 bits of random data," and each protection operation derives a session key from that MasterKey plus "16 bytes of random data" [@src-dpapi]. DPAPI-NG's key hierarchy differs, but it likewise draws its key material from the same CNG CSPRNG. Either way, that randomness is CNG's.
BitLocker generates its Volume Master Key and Full Volume Encryption Key when a volume is first encrypted in software, wrapping the FVEK under the VMK in the key hierarchy Microsoft documents [@src-bitlocker]; that key material, like all software randomness on the system, is drawn from the CNG CSPRNG [@src-win10rng-pdf].
Schannel, the Windows TLS stack [@src-schannel], pulls per-handshake randomness and ephemeral (EC)DHE secrets on every connection through the same CryptoAPI/CNG plumbing [@src-win10rng-pdf].
Machine-account passwords and computer-object secrets bottom out in the same place. Randomly-generated (version-4) GUIDs, when produced through CNG, inherit its randomness, but GUIDs are not in general guaranteed to be unpredictable and should not be relied on as security tokens [@src-rfc4122].

Break the generator and you do not break one of these -- you weaken all of them at once, which is precisely why the design invests so heavily in protecting the seed. The DPAPI, BitLocker, and Schannel companion posts trace each of these key hierarchies in detail.

That is the thesis, and it would be an overstatement if it stopped there. So here is the boundary that keeps it honest, and naming it is what makes the universal claim true rather than sloppy.

Key idea: Every software secret Windows generates draws on one CSPRNG. But keys born inside a TPM or a smart card are generated by that device's own hardware random number generator -- the CNG software CTR_DRBG is not in that path. That boundary is exactly where "the OS rolls the dice" stops and the hardware rolls its own.

When you generate a key through the Platform Crypto Provider -- the TPM key storage provider -- or through a smart-card provider, the private key can be created and kept on the device and never exist as software-accessible bytes. The randomness for that key comes from the TPM's or the card's on-chip RNG, governed by its own certification, not from the Windows CTR_DRBG; the software chain the whitepaper describes simply is not on that path [@src-win10rng-pdf]. The companion post on the TPM in Windows follows it in detail.

The distinction is not academic: a TPM-resident key does not inherit the VM-clone caveat from Section 7 the way a software key does, because its generation never touched the cloned software state. Conversely, it inherits whatever assurance -- or opacity -- the device's own RNG carries.

This is why the thesis is scoped to software secrets. It is not a hedge; it is a map. The set of things that draw on the CNG generator is enormous and includes essentially everything an application, a protocol stack, or the OS itself produces in memory. The set that does not is small, specific, and deliberate: the keys you asked the hardware to make and keep. A precise claim tells you both where to look when you reason about randomness and where that reasoning hands off to a different chip.

So the OS rolls the dice for everything it makes in software, and -- as the last several sections argued -- it rolls them well: kernel-resident, forward-secure, diversely seeded, clock-reseeded, clone-aware. That is a genuinely strong position. But there is a limit no amount of good engineering can cross, and it is not a bug to be patched. It is a fact about information itself.

10. Theoretical Limits: You Cannot Conjure Entropy

Here is the uncomfortable truth beneath all of it. A CTR_DRBG cannot create a single bit of unpredictability. It can only spread out what it was seeded with. Run AES a billion times and the output is exactly as unpredictable as the entropy in its seed, and never beyond its 256-bit security strength -- no more. The generator is a magnificent amplifier of entropy and a producer of none.

That has a hard consequence. The min-entropy of the seed is an upper bound on the security of everything drawn from it. A 256-bit key generated from a seed carrying only 30 bits of real min-entropy has 30 bits of security, not 256, no matter how flawless the cipher is. The attacker does not fight AES; they guess among $2^{30}$ possible seeds. This is the same failure as Netscape and Debian, stated as a theorem rather than a bug: unpredictability out cannot exceed unpredictability in.

The theory takes this seriously by splitting a secure generator into two phases with different characters. The first, entropy extraction, is information-theoretic -- it is about genuinely accumulating unpredictability. The second, output generation, is computational -- it stretches the accumulated seed using a cipher. Barak and Halevi made that separation rigorous in 2005, showing the extraction step "is information-theoretic in nature" while the generation step can be built from any standard cryptographic PRG [@src-barakhalevi2005].

The modern security goal for a generator with input. A generator meeting this goal must keep output unpredictable, recover its security after a state compromise once enough fresh entropy is absorbed (prediction resistance), and protect past output (backtracking resistance) -- all at once, even against an adversary who partly controls the entropy source. Formalized by Dodis and colleagues in 2013 [@src-dodis2013].

That model, robustness, is now "the standard security goal for PRNGs" [@src-hoangshen2020]. It folds resilience, prediction resistance, and backtracking resistance into one game an adversary plays against the whole generator, entropy source included. And the good news is real: the mechanisms Windows relies on have been analyzed against it.

Mechanism	Built from	Meets the robustness goal?	Known footgun
`CTR_DRBG`	AES in counter mode	Yes, patched (Hoang and Shen, 2020) [@src-hoangshen2020]	Implementation flexibility enables cache side-channels [@src-cohney2019]
`HMAC_DRBG`	HMAC over a hash	In the random-oracle model, with a caveat [@src-woodageshumow2018]	No forward security if the optional input is omitted [@src-woodageshumow2018]
`Hash_DRBG`	a hash function	In the random-oracle model, with a caveat [@src-woodageshumow2018]	An over-flexible standard

Read the table honestly, though, and the caveats are the point. Hoang and Shen proved the patched CTR_DRBG satisfies robustness, and only under the assumption that AES behaves as an ideal cipher [@src-hoangshen2020]. Woodage and Shumow proved Hash_DRBG and HMAC_DRBG satisfy robustness in the random-oracle model, and found that HMAC_DRBG loses forward security entirely if an optional input the standard treats as discretionary is omitted [@src-woodageshumow2018]. Every one of these results holds up to an assumption: an idealized primitive and a leak-free, constant-time implementation.

Reality violates that assumption. Cohney and colleagues turned CTR_DRBG's implementation flexibility into practical cache side-channel attacks on deployed code, recovering state that the security proofs assumed was hidden [@src-cohney2019]. The proof says "secure if the code does not leak." The attack says "the code leaks." Both are true, and the gap between them is where real vulnerabilities live.

It is tempting to think you can validate a generator by running its output through Dieharder or the NIST statistical test suite. You cannot, at least not for the property that matters. Those suites detect gross bias and obvious structure -- a generator that is broken in a way a statistician would notice. They say nothing about cryptographic unpredictability. `Dual_EC_DRBG` would sail through every one of them, because its output passes standard statistical test batteries; the *catastrophic* weakness is a trapdoor, not the small, known output bias [@src-dualecbias]. Passing the tests is necessary and nowhere near sufficient.

The construction-level standard meant to tie entropy sources to DRBGs, SP 800-90C, is now finished. NIST finalized it on 25 September 2025, calling it "the final document in the SP 800-90 series," and it specifies four RBG constructions: RBG1, RBG2, RBG3, and the chained RBGC [@src-sp80090c; @src-sp80090c-doi; @src-nist90cnews2025].

RBG3 constructions target full-entropy output, the continuous-fresh-entropy ideal; RBGC names the chain-of-RBGs shape -- each RBG (a DRBG mechanism plus its seeding interface) on one platform seeding the next -- that the Windows root-to-per-processor arrangement instantiates as CTR_DRBGs. Beneath it, SP 800-90B governs the design and health testing of the entropy sources feeding the whole construction [@src-sp80090b]. The framework for reasoning about the full stack, in other words, is now complete on paper -- which throws the remaining gap into sharper relief.

So the ceiling is the seed's min-entropy, and there is no way to run a tape measure over a live source and read off its true entropy. Every security proof in this article is conditioned on a "sufficiently seeded" premise that can be assumed but never fully verified. That is not a flaw in Windows; it is the shape of the problem. Which raises the obvious question: if you cannot measure entropy and cannot prove code leak-free, what exactly is still open -- and how much of it should keep you up at night?

11. Open Problems and Live Concerns

The generator is, for practical purposes, solved. The things around it are not. Five honest frontiers remain, and knowing them tells you exactly where to be careful.

Trusting hardware entropy you cannot audit. RDRAND and RDSEED are sealed pipelines inside a chip: an entropy source, a conditioner, and a CTR_DRBG, none of which you can inspect [@src-inteldrng]. Windows' mix-many-trust-none design means a single compromised hardware source cannot own the seed [@src-win10rng-pdf], which is the right defensive posture. But "cannot dominate" is not "proven honest." No amount of mixing can demonstrate that a hardware source is behaving; it can only ensure that its misbehavior is survivable.

Entropy estimation is essentially unsolvable. There is no sound, general way to measure the true min-entropy of a running source online -- to look at a stream and certify "this carries 200 bits." Fortuna's design philosophy is to avoid estimation entirely, reseeding on a schedule rather than when an estimator declares "enough" [@src-fortuna]. Dodis and colleagues showed that flawed estimators are themselves an attack surface, adding that "it remains unclear if these attacks lead to actual exploitable vulnerabilities in practice" [@src-dodis2013]. SP 800-90B specifies health tests, but a health test detects failure; it does not measure abundance [@src-sp80090b; @src-sp80090b-pdf].

This is why "add your own entropy" is bad advice: you would be trusting an entropy estimate no one can validate.

The boot, headless, container, and VM residual window. The most damaging real-world randomness failures have all happened when a system generated keys before it had gathered enough entropy. "Mining Your Ps and Qs" scanned the internet and found tens of thousands of hosts sharing or exposing factorable keys, tracing the cause to a "boot-time entropy hole" on headless and embedded devices that generated keys at first boot [@src-heninger2012; @src-factorable].

The mitigations -- seed files carried across reboots, Linux's getrandom() blocking until initialized (its random(7) manual warns that early urandom output "may be low entropy and unsuitable") [@src-random7], and Windows' Winload seeding plus VM Generation ID -- have narrowed this dramatically. They have not closed it. A freshly provisioned container or a cloned VM in the wrong instant is still the scenario to watch.

Constant-time, side-channel-free implementations. The Cohney cache attacks from the last section were not breaks of the mathematics; they were breaks of the code [@src-cohney2019]. Keeping every step of a generator constant-time and free of state-dependent memory access is an ongoing engineering discipline, not a solved problem.

End-to-end formal verification. SymCrypt is explicitly engineered to "provide high assurance" and to support FIPS 140 certification [@src-symcrypt], and pieces of the cryptographic stack have been formally analyzed. But a single machine-checked proof covering the entire path -- from interrupt-timing collection through the SHA-512 pools to the per-processor CTR_DRBG and out through ProcessPrng -- is not yet reality.

Enabling FIPS mode does not swap in a different generator. Windows already uses an SP 800-90A `CTR_DRBG` implemented in SymCrypt, which is built for FIPS 140 validation [@src-symcrypt]. What FIPS mode does is constrain the system to the validated set of mechanisms and enforce the associated self-tests and boundaries. The architecture -- the chain, the mixing, the reseed schedule -- is the same with FIPS mode on or off. It is a compliance and configuration control, not a security upgrade to the RNG itself.

A final clarification, because it comes up constantly. The arrival of quantum computing does not threaten the quality of Windows' randomness. Shor's algorithm attacks the hard problems behind RSA and elliptic curves [@src-shor1997]; it does not make a well-seeded CTR_DRBG predictable, and a good CSPRNG needs no post-quantum redesign.

If anything, randomness becomes more foundational in a post-quantum world, because most of the new key-generation algorithms draw more fresh randomness per key than an elliptic-curve key does: ML-KEM consumes 64 bytes of RBG output [@src-fips203] and SLH-DSA between 48 and 96 bytes [@src-fips205], against roughly the 32-byte scalar an elliptic-curve or EdDSA key needs, while ML-DSA draws about the same, a 32-byte seed [@src-fips204].

This is not a blanket claim against all classical schemes -- RSA key generation already rejection-samples large primes and consumes substantial randomness of its own -- but for the elliptic-curve keys these algorithms replace, the fixed draw is as large or larger. The generator does not need to change; it just gets asked for more, more often. And with SP 800-90C now final as of 2025, the remaining standards work is not the constructions themselves but validating the entropy sources that feed them under SP 800-90B [@src-sp80090b].

None of this should scare you off the platform. It should do the opposite: tell you precisely what the OS handles for you, and what small set of things are yours to get right.

12. A Practical Guide

The whole argument reduces to a short list of rules, and most of them are about what not to do. The generator is the OS's job; your job is to call it correctly and stay out of its way.

Platform	Call this	Never for secrets
Windows (native)	`BCryptGenRandom` with `BCRYPT_USE_SYSTEM_PREFERRED_RNG`, or `ProcessPrng` [@src-processprng; @src-bcryptgenrandom]	`rand()`, legacy `CryptGenRandom`
.NET	`System.Security.Cryptography.RandomNumberGenerator` [@src-dotnet-rng]	`System.Random`
Linux	`getrandom()` or `getentropy()` [@src-getrandom]	`/dev/urandom` read before init, `rand()`
BSD / macOS	`arc4random_buf`, `arc4random_uniform` [@src-arc4random]	`rand()`, `random()`

The DO side is short because the right answer is almost always "ask the OS." The DON'T side is where the real bugs live. Never use rand() or the Mersenne Twister for anything an adversary should not predict [@src-mt]. Never reach for legacy CryptGenRandom. Never hand-seed the generator with your own entropy (see the callout below).

And watch three subtler traps: modulo bias when reducing random bytes into a range, generator state inherited across a fork() or a VM clone, and key generation that happens too early in boot.

That first trap -- modulo bias -- is the one people rediscover constantly, so it is worth seeing fixed. Reducing a uniform byte with % n skews the result whenever n does not divide the range evenly. Rejection sampling fixes it by discarding the few values that would skew things.

{` // In real code the bytes come from the OS CSPRNG: // Windows: BCryptGenRandom / ProcessPrng // .NET: RandomNumberGenerator.Fill // Linux: getrandom() BSD/macOS: arc4random_buf // Here we simulate a source of uniform bytes. function secureRandomByte() { return Math.floor(Math.random() * 256); // stand-in for the OS CSPRNG }

// WRONG: 'byte % 6' is biased, because 256 is not a multiple of 6. function rollBiased() { return (secureRandomByte() % 6) + 1; }

// RIGHT: rejection sampling discards the few skewing values. function rollFair() { const limit = 256 - (256 % 6); // 252, the largest multiple of 6 below 256 let b; do { b = secureRandomByte(); } while (b >= limit); return (b % 6) + 1; }

const biased = [0,0,0,0,0,0,0]; const fair = [0,0,0,0,0,0,0]; for (let i = 0; i < 600000; i++) { biased[rollBiased()]++; fair[rollFair()]++; } console.log("biased % 6 :", biased.slice(1)); console.log("fair reject:", fair.slice(1)); console.log("low faces are over-represented in the biased row"); `}

Note: The instinct to "strengthen" a key by stirring in your own randomness is almost always counterproductive. The OS pool is conditioned from many independent sources; app-supplied entropy is usually worse and can only dilute. On Windows 8 and later, the flag that once allowed it is ignored outright [@src-bcryptgenrandom]. Call the system generator and trust the architecture the last eleven sections described.

On Windows, in PowerShell, `[System.Security.Cryptography.RandomNumberGenerator]::GetBytes(32)` returns 32 cryptographically secure bytes through the CNG path [@src-dotnet-rng]. On Linux, a program calling `getrandom(buf, 32, 0)` blocks only if the pool is not yet initialized, then fills the buffer [@src-getrandom]. On OpenBSD or macOS, `arc4random_buf(buf, 32)` never blocks and never fails [@src-arc4random]. In every case you are reaching the same two-layer design: an entropy-fed pool keying a fast, forward-secure generator. No. Windows shipped `Dual_EC_DRBG` only as a non-default SP 800-90 option -- available if an application explicitly requested it, never the system default -- and later removed it [@src-msdualec]. The case where it was reportedly the default is RSA's BSAFE toolkit, per Reuters reporting of a \$10 million contract, and NIST withdrew the algorithm in 2014 citing a lack of public confidence [@src-nistremoval2014; @src-reuters2013]. No. Windows treats `RDRAND` as one input among many, notes that it provides only a 128-bit security level, prefers `RDSEED`, and never relies on any single hardware source alone. Everything is mixed through SHA-512 pools so no one source can determine the seed [@src-win10rng-pdf]. No. Keys generated and held inside a TPM or a smart card come from that device's own hardware random number generator. The CNG software `CTR_DRBG` is not in that path. This is the explicit boundary of the claim that the OS rolls the dice for software secrets [@src-win10rng-pdf]. On native Windows, `BCryptGenRandom` (with `BCRYPT_USE_SYSTEM_PREFERRED_RNG`) or `ProcessPrng`. On .NET, `RandomNumberGenerator`, which wraps `BCryptGenRandom` on Windows. Never `rand()` or legacy `CryptGenRandom` for anything secret [@src-processprng; @src-bcryptgenrandom; @src-dotnet-rng]. You can detect gross failure, but statistical suites cannot prove cryptographic security. `Dual_EC_DRBG` would pass Dieharder and the NIST test suite while remaining predictable to whoever holds its trapdoor. Statistical quality is necessary, not sufficient [@src-mt]. No. Windows seeds its generator in the Winload boot loader before any user code runs, so there is no blocking wait at the API. Contrast Linux `getrandom()`, which blocks until the kernel pool is initialized unless you pass a non-blocking flag [@src-win10rng-pdf; @src-getrandom]. No. See the "Do not add your own entropy" callout above.

Which brings the argument back to where it started, now with the evidence behind it. Netscape and Debian did not lose to better cryptanalysis; they lost because their keys were drawn from dice an attacker could read. Windows lost the same way once, with CryptGenRandom, and the industry nearly lost a third time to a standardized algorithm whose own constants were the weapon.

The answer Windows built is not a better cipher -- AES was never the problem -- but a better way to roll: kernel-resident, forward-secure CTR_DRBGs in a per-processor chain, seeded from many sources so no single one can cheat, reseeded on a clock, and watching for the clone that would make two machines roll alike.

Every software secret the OS makes inherits that. The one place it hands the dice to someone else is the TPM and the smart card, which roll their own. Know where that line is, call the system generator, and the unguessability of your keys takes care of itself.