up:: Foundations MOC

CSPRNG and DRBG

A cryptographically secure pseudorandom number generator (CSPRNG), which NIST calls a deterministic random bit generator (DRBG), is the algorithm that turns a small pool of genuine unpredictability into the long stream of random-looking bits that cryptography needs everywhere. Every key, nonce, salt, and initialization vector has to be unpredictable, and a system cannot draw fresh physical entropy for each one fast enough, so it collects a seed of real entropy once and uses a DRBG to expand it deterministically into as many bits as it needs. NIST SP 800-90A Rev. 1 specifies the approved DRBG mechanisms.

The stakes are high and classical: weak or predictable randomness leaves the math of a cipher perfectly sound and breaks the system anyway, because an attacker can reconstruct the secret directly. This concern is separate from the quantum threat, and it is separate from a hardware entropy source like QRNG.

Source: NIST, “Recommendation for Random Number Generation Using Deterministic Random Bit Generators,” SP 800-90A Rev. 1, June 2015, csrc.nist.gov/pubs/sp/800/90/a/r1/final.

The short version:

• A CSPRNG (NIST’s term is DRBG) stretches a small amount of true entropy into a long, unpredictable stream of bits, because a system needs far more random bits than it can harvest physically in real time.
• The security requirement is that an attacker who sees some of the output still cannot predict any other output, forward or backward, even knowing the algorithm. A general-purpose random generator that is merely “statistically random” fails this and must never seed a key.
• The two pieces work together: an entropy source supplies a genuinely unpredictable seed, and the DRBG deterministically expands that seed. Good output requires both a strong seed and a sound algorithm.
• NIST SP 800-90A Rev. 1 specifies three approved DRBG mechanisms: Hash_DRBG, HMAC_DRBG, and CTR_DRBG, built on hash functions or a block cipher.
• Weak randomness has broken real, mathematically sound systems at scale. Predictable keys and repeated nonces have exposed private keys and plaintext across the internet.
• This is a classical concern, present with or without a quantum computer, and it is distinct from a hardware entropy source such as QRNG, which supplies the seed rather than replacing the generator.

Picture a sealed drum of numbered balls that nobody can see into. A true random source is drawing one ball at a time by hand from a genuinely shuffled drum, which is fair but slow. A CSPRNG is more like a machine that watches the first few hand-drawn balls, then uses them to run a precise, sealed mechanism that spits out a long sequence of further numbers, each one impossible to predict from the ones before it unless you hold the sealed starting state. As long as the first few balls were genuinely unpredictable and the mechanism is sound, the whole long sequence is safe to build secrets from. If either the starting balls were rigged or the mechanism has a peephole, every secret downstream is compromised.

What is a CSPRNG, and how is it different from an ordinary random generator?

A CSPRNG is a random-number generator whose output is not merely statistically well-distributed but computationally unpredictable, meaning that an attacker who observes part of the output and knows the algorithm still cannot predict any other part. NIST formalizes this as a DRBG, and the bar it has to clear is far higher than the bar for the general-purpose random functions built into most programming languages. Two properties separate a CSPRNG from an ordinary generator:

1. Next-bit unpredictability. Given any run of output bits, no efficient attacker can guess the next bit with meaningfully better than even odds. An ordinary generator can look perfectly random to a statistics test and still be trivial to predict once you see enough output, because its internal state is small and its update rule is public.
2. State-compromise resistance (backtracking resistance). Even if an attacker somehow learns the generator’s current internal state, they cannot reconstruct the bits it produced earlier. This limits the blast radius of a one-time state leak.

The distinction is not academic. The default random generators in common languages (the ones behind a plain rand() or Math.random()) are built for speed and even distribution, not for secrecy, and their internal state is often recoverable from a handful of outputs. Using one to generate a key, a token, or a nonce is a classic and catastrophic mistake, because the “random” secret is then predictable to anyone who reverse-engineers the sequence. A CSPRNG exists precisely for the jobs where an adversary is trying to predict the output.

Source: NIST, “Recommendation for Random Number Generation Using Deterministic Random Bit Generators,” SP 800-90A Rev. 1, June 2015, csrc.nist.gov/pubs/sp/800/90/a/r1/final.

How does a DRBG work?

A DRBG works by absorbing a seed of genuine entropy into an internal state, then repeatedly running a deterministic one-way function over that state to produce output bits and advance to the next state. The word “deterministic” is the key to understanding it: given the same seed, a DRBG produces exactly the same stream every time, so all of its unpredictability comes from the seed being unpredictable, and none of it from the algorithm, which is fully public. The lifecycle runs in a fixed sequence:

1. Instantiate. The DRBG is seeded from an entropy source, mixing in the raw entropy plus optional extra inputs to set its initial internal state.
2. Generate. On each request, it runs its underlying primitive (a hash function, HMAC, or a block cipher) over the internal state to produce output bits, then updates the state so the same bits never repeat.
3. Reseed. Periodically, or on demand, it absorbs fresh entropy to refresh the state, which limits how much output depends on any single seed and restores unpredictability if the state was ever at risk.

Two design ideas matter for why this is safe:

• The one-way generation step means seeing the output never reveals the internal state, which is what gives the DRBG its next-bit unpredictability.
• An option called prediction resistance forces a reseed with fresh entropy before generating, so that even an attacker who compromised the state a moment ago cannot predict the bits that come after the reseed.

The whole construction rests on one honest admission: a DRBG creates no new randomness. It faithfully stretches the entropy it was seeded with, so the quality of the seed sets the ceiling on the security of everything the DRBG produces.

Source: NIST, “Recommendation for Random Number Generation Using Deterministic Random Bit Generators,” SP 800-90A Rev. 1, June 2015, csrc.nist.gov/pubs/sp/800/90/a/r1/final.

What DRBG mechanisms does NIST approve?

NIST SP 800-90A Rev. 1 approves three DRBG mechanisms, each built on a primitive a system is likely to already have, so a designer can reuse an existing cryptographic component rather than add a new one. The three approved mechanisms:

Mechanism	Built on	Typical fit
Hash_DRBG	A hash function (the SHA-2 family)	Systems that already lean on a hash primitive
HMAC_DRBG	HMAC over a hash function	A common, well-analyzed choice, used in many protocols
CTR_DRBG	A block cipher in counter mode (AES)	Systems with hardware AES acceleration

The three share the same lifecycle (instantiate, generate, reseed) and differ only in the underlying primitive that drives the one-way step. One piece of history sharpens why the approved list matters. An earlier version of SP 800-90A also included a fourth mechanism, Dual_EC_DRBG, built on elliptic-curve math, which was withdrawn in 2015 after analysis and disclosures indicated it could contain a designed-in backdoor in the constants it used, letting whoever chose those constants predict its output. NIST removed it and told users to move to one of the three remaining mechanisms. The lesson is that a random generator’s design and its constants are load-bearing security choices, and “it passes statistical tests” is not evidence that it is safe.

Source: NIST, “Recommendation for Random Number Generation Using Deterministic Random Bit Generators,” SP 800-90A Rev. 1, June 2015, csrc.nist.gov/pubs/sp/800/90/a/r1/final.

Why does weak randomness break cryptography?

Weak randomness breaks cryptography because every secret a system generates is only as unpredictable as the bits it was drawn from, so predictable randomness hands an attacker the secret directly while the cipher’s math stays perfectly intact. This is one of the most common ways that real, correctly-implemented cryptography fails in the field, and the failures are not hypothetical:

1. Predictable keys from a broken seed. A widely-cited failure came from a code change that crippled a system library’s entropy pool, so it could generate only a tiny set of possible keys. Attackers could enumerate every possible key that library would ever produce and recover private keys wholesale, without touching the underlying algorithm.
2. Repeated nonces exposing keys. Several signature schemes require a fresh, unpredictable random value on every signature, and reusing or predicting that value lets an attacker solve for the long-term private key from just two signatures. High-profile key recoveries have come from exactly this flaw in devices and applications that reused the value.
3. Low-entropy keys generated at first boot. Devices that generate keys immediately on first power-up, before they have gathered enough entropy, have produced keys with predictable or shared factors, which large internet-wide scans have found affecting many thousands of real hosts at once.

The pattern across all of these is the same and worth stating plainly: the cipher was not broken. The random-bit generation feeding it was, and that was enough to lose everything the cipher protected. This is why secure random-bit generation is treated as a foundational primitive in its own right, and why a CSPRNG, a strong entropy source, and correct seeding are all part of a system being secure, entirely apart from which cipher it runs.

Source: NIST, “Recommendation for the Entropy Sources Used for Random Bit Generation,” SP 800-90B, January 2018, csrc.nist.gov/pubs/sp/800/90/b/final.

How does a CSPRNG relate to QRNG and to the quantum threat?

A CSPRNG and a QRNG work at different points in the same pipeline: a QRNG is one kind of entropy source that can supply the seed, and the CSPRNG is the deterministic engine that expands whatever seed it is given. They are complementary rather than competing, and neither one is a post-quantum solution:

1. A QRNG supplies entropy; a CSPRNG stretches it. A QRNG produces raw random bits from a quantum physical process, and those bits can seed a DRBG exactly the way any other validated entropy source can. Swapping in a QRNG changes where the seed comes from, and the DRBG that expands it stays the same.
2. A QRNG is not required for a secure CSPRNG. A well-validated classical entropy source (thermal noise, timing jitter, a hardware generator that passes SP 800-90B) seeds a DRBG just as safely. The requirement is a strong, validated seed, and “quantum” is not the thing that makes it strong.

The relationship to the quantum threat is the point most worth holding: randomness quality is a separate axis from quantum vulnerability. The quantum threat is about specific algorithms, Shor’s algorithm breaking the public-key math behind RSA and ECC, and improving your randomness does nothing to change that, because a perfectly-seeded RSA key is still an RSA key a quantum computer can factor. Weak randomness is a classical failure that has always been dangerous and remains exactly as dangerous after the migration. Strong randomness and post-quantum algorithms are both necessary, and neither one substitutes for the other.

Source: NIST, “Report on Post-Quantum Cryptography,” NISTIR 8105, April 2016, csrc.nist.gov/pubs/ir/8105/final.

Common misconceptions

1. “The random function in my language is fine for keys.” A general-purpose generator is built for even distribution and speed, and its state is often recoverable from a few outputs. Keys, tokens, and nonces need a CSPRNG whose output stays unpredictable to an attacker who knows the algorithm.
2. “A DRBG creates randomness.” It does not. A DRBG deterministically stretches the entropy in its seed, so its output is only as unpredictable as that seed. Real entropy comes from the entropy source, not from the DRBG.
3. “If it passes statistical randomness tests, it is cryptographically secure.” Statistical tests catch bias and patterns rather than predictability. A generator can pass them and still be trivial to predict, which is exactly how several broken generators slipped through.
4. “A quantum computer will break my CSPRNG.” The quantum threat targets public-key algorithms, not random generation. A DRBG built on AES or a hash faces only the same mild Grover pressure as those primitives, so it is not the quantum exposure.
5. “A QRNG replaces the CSPRNG.” A QRNG is an entropy source that seeds a DRBG; it sits before the CSPRNG in the pipeline rather than replacing it. The deterministic generator is still the part that produces the stream of bits.
6. “Randomness only matters for key generation.” Nonces, initialization vectors, salts, and ephemeral values all need unpredictability too, and reusing or predicting a nonce has exposed private keys as surely as a weak key has.

Questions people ask

What is the difference between a CSPRNG and a DRBG? They name the same thing from two angles. CSPRNG is the general term for a cryptographically secure pseudorandom generator; DRBG (deterministic random bit generator) is NIST’s specific term in SP 800-90A for the approved mechanisms. A NIST-approved DRBG is a CSPRNG.

Why does a system expand a seed instead of drawing true randomness for everything? A true entropy source is slow and limited, and cryptography needs far more random bits than one can supply in real time. The standard approach is to gather a strong seed of true entropy once and use a DRBG to expand it deterministically into as many bits as needed.

What makes randomness “cryptographically secure”? The output must be computationally unpredictable: an attacker who sees part of it and knows the algorithm still cannot predict any other part. That is a much higher bar than being statistically well-distributed, which ordinary random generators meet but cryptographic ones must exceed.

Which DRBGs does NIST approve? SP 800-90A Rev. 1 approves Hash_DRBG, HMAC_DRBG, and CTR_DRBG, built on a hash function, HMAC, or a block cipher respectively. An earlier mechanism, Dual_EC_DRBG, was withdrawn over a suspected designed-in weakness.

Does a CSPRNG protect me from a quantum computer? No. Random-bit generation and quantum vulnerability are separate concerns. A quantum computer breaks public-key algorithms regardless of how good your randomness is, so you need both strong randomness and post-quantum algorithms.

Is a QRNG better than a classical CSPRNG? They do different jobs. A QRNG is an entropy source that can seed a DRBG, and a validated classical entropy source seeds one just as safely. The generator that stretches the seed is the CSPRNG either way, and “quantum” is not what makes the seed strong.

How does weak randomness actually break a system? It makes the generated secret predictable, so an attacker reconstructs a private key or guesses a nonce directly, while the cipher’s math stays perfectly sound. Real failures have come from crippled entropy pools, repeated signature nonces, and keys generated before a device had gathered enough entropy.

---

Everything here is the map, given freely. When your team needs its own cryptography sorted into what survives the quantum transition and what has to move, that’s what an alignment briefing is for.

Last verified 2026-07-12 · Maintained by Addie LaMarr, LaMarr Labs.