Back to DashboardFoundationsadvanced40 min

Entropy & Randomness

Entropy sources, SP 800-90A DRBGs, SP 800-90B entropy-source validation and SP 800-90C RBG constructions — why output tests are not entropy estimates, why a QRNG is judged by the same rules, and what random inputs ML-KEM, ML-DSA and SLH-DSA require.

Why this matters: Every key this curriculum generates depends on entropy — a weak DRBG or predictable seed makes even a perfect PQC algorithm choice worthless, since the attack moves from 'break the math' to 'guess the seed'.

Start here: Toggle the sources — Web Crypto API, OpenSSL WASM, Math.random() and Timestamp LCG — pick a byte count and press Generate: each source's bytes, frequency histogram and lag plot appear side by side.

For your role

Developer / Engineer: Generate random bytes from Web Crypto and OpenSSL, run the visual checks and SP 800-90B health tests as separate groups, step through HMAC_DRBG, then health-test raw sources before conditioning in the source-combining step: the entropy every key you generate depends on.
Security Architect: The Entropy Source Validation walkthrough and the source-combining step show what evidence a key-generation design needs, and the assumptions under which combining two sources adds assurance.
Researcher / Academic: The SP 800-90B health tests, the HMAC_DRBG known-answer check against NIST vectors and the source-combining counterexamples are all runnable, with the Entropy Testing tool for your own samples.
Certification & Validation Engineer: The Entropy Source Validation walkthrough, the SP 800-90B health tests run apart from the visual checks, and the HMAC_DRBG known-answer check against NIST vectors separate what an entropy source must evidence from what a DRBG must.
Curious Explorer: Every secret key starts as random numbers; the module shows the difference between good randomness and predictable numbers with tests you can run on both.

Practice in the Simulation

Why Entropy Matters

All cryptographic security ultimately depends on the quality of randomness used for key generation, nonces, and initialization vectors. A perfectly designed algorithm with a 4096-bit key is worthless if the underlying random number generator is predictable. The difference between "secure" and "broken" often comes down to — the measure of true unpredictability in the bits that seed your cryptographic operations.

Bad Entropy

Debian OpenSSL bug (2008): PID-only seeding produced ~32,768 possible keys
Predictable seeds lead to key recovery attacks
Hardware failures (stuck-at) can produce constant output
Stateful Signatures (LMS/XMSS): Catastrophic tree security failure during key generation if the RNG repeats a seed or lacks entropy.

Good Entropy

OS (crypto.getRandomValues, /dev/urandom)
Processor RNG instructions: Intel RDRAND and Arm RNDR return DRBG output, Intel RDSEED returns conditioned seed values from the on-chip — none is raw noise
Continuous health monitoring per SP 800-90B

Best Practice

Multiple independent entropy sources
Defense-in-depth per SP 800-90C
Formal validation via NIST ESV program

NIST SP 800-90 Family

NIST's SP 800-90 series provides a complete framework for random number generation, from raw entropy sources to fully constructed Random Bit Generators (RBGs).

Mechanisms: Defines CTR_DRBG, Hash_DRBG, and HMAC_DRBG for stretching seed entropy into arbitrary-length random streams.

Entropy Sources: Methods for validating that physical noise sources provide sufficient entropy. Includes health tests and estimation.

RBG Constructions: How to combine entropy sources with DRBGs into complete Random Bit Generators. Defines RBG1, RBG2, RBG3, and RBGC classes.

Entropy Source

(90B)

Conditioning

HMAC / Hash

DRBG

(90A)

Random Output

RBG construction (90C)

DRBG Mechanisms (SP 800-90A)

SP 800-90A defines approved DRBG mechanisms built on symmetric primitives: hash functions, HMAC and block ciphers. Engineering judgment, not a NIST statement: Shor's algorithm does not apply to these primitives, so a DRBG's resistance to quantum attack depends on the primitive and security strength chosen — Rev. 1 CTR_DRBG still allows three-key TDEA alongside AES.

CTR_DRBGSP 800-90A Rev. 1 §10.2.1

Basis: Block cipher (AES; Rev. 1 also allows TDEA)

Uses an approved block cipher in counter mode for state update and output.

Engineering note: fast where the platform has AES hardware support; widely implemented.

Hash_DRBGSP 800-90A Rev. 1 §10.1.1

Basis: Approved hash function (e.g. SHA-256, SHA-512)

Uses an approved hash function for state update and output.

Engineering note: no block-cipher dependency.

HMAC_DRBGSP 800-90A Rev. 1 §10.1.2

Basis: HMAC with an approved hash function

Uses HMAC for state update and output. RFC 6979 deterministic (EC)DSA derives its per-signature k from HMAC_DRBG.

Engineering note: simple construction built only on HMAC.

SP 800-90A Rev. 2Pre-draft call for comments — not a draft, not a standard

On 2025-09-04 NIST published a pre-draft call for comments on SP 800-90A (comments closed 2025-11-04). NIST has announced that the revision will introduce a DRBG construction based on the SHAKE extendable-output functions of FIPS 202. No draft text has been published, so no such mechanism is specified or approved yet. NIST CSRC page (status checked 2026-09-24).

Note: SP 800-90A Rev. 1 (June 2015) is the current final version. It specifies Hash_DRBG and HMAC_DRBG (§10.1) and CTR_DRBG (§10.2).

Entropy Testing (SP 800-90B)

SP 800-90B (2018) provides methods for validating that entropy sources produce sufficient randomness. Tests fall into two categories: continuous health tests that run during operation, and min-entropy estimators used during formal validation.

Health Tests (Continuous)

Repetition Count Test

Detects a noise source that gets stuck on one value (SP 800-90B §4.4.1). The test signals a failure if a sample is repeated C or more times in a row, where the cutoff C follows from the assessed min-entropy H and the false-positive probability α.

Adaptive Proportion Test

Detects a large loss of entropy (SP 800-90B §4.4.2). It takes one sample, counts how many times that same value occurs within the next W−1 samples, and signals a failure if the count reaches the cutoff C; then it starts a new window with the next sample. W is 1,024 for a binary noise source and 512 otherwise.

Min-Entropy Estimation (Validation)

Key Estimators

Most Common Value
Collision
Markov
Compression
t-Tuple
Longest Repeated Substring

Predictor Tests

MultiMCW
Lag
MultiMMC
LZ78Y

Tool: NIST provides an open-source C++ implementation (SP800-90B_EntropyAssessment) for running these tests on raw noise samples.

NIST ESV Program

SP 800-90B sets the requirements an entropy source must meet. The certificate comes from NIST's Cryptographic Module Validation Program (CMVP): a testing lab accredited for entropy validation submits the source's SP 800-90B conformance justification, and CMVP issues an Entropy Validation Certificate.

Accredited Lab

Prepares evidence

ESV Server

Web API submission

CMVP Review

Is the justification sufficient?

Entropy Validation

Certificate

Separate from a FIPS 140-3 module certificate. Since 7 November 2020 CMVP has required module submissions to include documentation justifying SP 800-90B conformance where applicable.
Each certificate records a reuse status — for example, "Reuse restricted to vendor".
RBG constructions are a separate step: CMVP also issues Random Bit Generator Validation Certificates for SP 800-90C conformance (IG D.T).
NIST publishes no review duration. Do not plan around a fixed number of weeks.

vs

"Quantum" describes a noise source; it is not evidence. A QRNG is judged by the same SP 800-90B requirements as any other entropy source, and SP 800-90B calls the noise source "the root of security for the entropy source and for the RBG as a whole". What matters for either kind is the assessed min-entropy of its raw data and health tests that catch it failing.

Property	TRNG	QRNG
Noise source	A classical physical or non-physical process, e.g. thermal noise, clock or CPU-timing jitter	A quantum process, e.g. photon detection or quantum tunnelling
Validation criteria (FIPS 140-3)	SP 800-90B: noise-source model, entropy estimate from raw data, health tests	The same SP 800-90B requirements — no separate track for quantum sources
Example Entropy Validation Certificates	E19 SUSE Kernel CPU Time Jitter RNG; E280 AWS-LC CPU Jitter RNG Entropy Source	E63 IDQ Quantis IID QRNG (QRNG chips); E145 QuintessenceLabs qStream 100
What security rests on	The noise source really delivering its assessed min-entropy, checked in operation by health tests	The same. Quantum physics describes the ideal process; a real device can still fail or degrade, which is what health tests are for
What output statistics show	Passing statistical tests on output is not an entropy estimate; SP 800-90B estimates come from raw noise-source data	Same — a working CSPRNG passes the same tests, so passing cannot tell the two apart

Certificate numbers from the CMVP entropy-validation search, checked 2026-09-24. A certificate covers the implementation and versions it lists, not a vendor's whole product line.

Combining Sources for PQC

A hardware noise source does not rest on a computational hardness assumption, so a quantum computer does not break it the way it breaks RSA or elliptic-curve keys. That does not make it secure: it is only as good as the entropy it actually delivers, and that has to be assessed and monitored.

Combining sources can add assurance, but only under stated conditions:

Defense-in-depth: A second source helps only if it is independent of the first. If one fails or is compromised, what is left is the entropy the other source actually delivers.
SP 800-90C: Specifies the RBG1, RBG2, RBG3 and RBGC constructions, which build RBGs from SP 800-90A DRBG mechanisms and SP 800-90B entropy sources
XOR combination: XOR of two independent inputs is at least as unpredictable as the stronger one. If the inputs are correlated, or an attacker can influence one of them, that guarantee is gone.
Conditioning: HMAC or hash conditioning can raise the entropy rate of its output, but it cannot add entropy. SP 800-90B assesses conditioned output from the entropy that went in.

Random inputs in FIPS 203, 204 and 205

Random-input length is not security strength. A 32-byte input does not by itself mean 256 bits of entropy or a 256-bit RBG requirement: each standard sets the minimum RBG security strength per parameter set, and signing randomness has no mandatory strength at all.

Operation	Random input	Length	RBG rule	Source
ML-KEM.KeyGen	`dz`	32 bytes each	Approved RBG (SP 800-90A/B/C) with security strength of at least 128 / 192 / 256 bits for ML-KEM-512 / 768 / 1024.Fresh bytes for every invocation. If random bit generation fails, KeyGen returns an error indication. The seed (d, z) can compute the decapsulation key, so it shall be protected like one.	FIPS 203 §3.3FIPS 203 §7.1, Algorithm 19FIPS 203 §7.1FIPS 203 §8, Table 2
ML-KEM.Encaps	`m`	32 bytes	Same rule as KeyGen (FIPS 203 §3.3 covers both algorithms).A fresh m for every call. If random bit generation fails, Encaps returns an error indication.	FIPS 203 §3.3FIPS 203 §7.2, Algorithm 20
ML-DSA.KeyGen	`ξ`	32 bytes	Approved RBG, fresh seed. ML-DSA-65: shall be ≥ 192 bits. ML-DSA-87: shall be ≥ 256 bits. ML-DSA-44: shall be ≥ 128 bits and should be ≥ 192 bits; with a 128–191-bit RBG its claimed strength drops from category 2 to category 1.ρ, ρ′ and K are derived from ξ inside ML-DSA.KeyGen_internal (Algorithm 6); they are not separate random inputs.	FIPS 204 §3.6.1FIPS 204 §6.1, Algorithm 6
ML-DSA.Sign (hedged, the default)	`rnd`	32 bytes	No mandatory RBG strength. rnd should ideally come from an approved RBG; other methods for fresh random values may be used.rnd shall be generated by the cryptographic module that runs ML-DSA.Sign_internal. Its main purpose is side-channel and fault-attack countermeasures.	FIPS 204 §3.6.1FIPS 204 §5.4
ML-DSA.Sign (deterministic variant)	`rnd`	32 bytes, fixed to {0}^32	No fresh randomness: rnd is the all-zero 32-byte string.The hedged variant is the default. FIPS 204 says even a weak RBG may be preferable to the deterministic variant, because rnd exists to support side-channel and fault-attack countermeasures.	FIPS 204 §5.2FIPS 204 §3.6.1
slh_keygen	`SK.seedSK.prfPK.seed`	n bytes each (n = 16, 24 or 32)	Approved RBG, fresh values, security strength of at least 8n bits (128 / 192 / 256 for n = 16 / 24 / 32).n comes from FIPS 205 Table 2: 16 for the -128 sets, 24 for -192, 32 for -256.	FIPS 205 §3.1
slh_sign (hedged / deterministic)	`addrnd (hedged)PK.seed as opt_rand (deterministic)`	n bytes	Hedged: addrnd should ideally come from an approved RBG; other methods may be used. Deterministic: no fresh randomness (opt_rand = PK.seed).addrnd shall be generated by the cryptographic module that runs slh_sign_internal.	FIPS 205 §9.2FIPS 205 §10.2

Errata state checked 2026-09-24: FIPS 203 — Planning note 2025-11-17; errata spreadsheet lists 2 items (Appendix A zeta table, a comment in Algorithm 15). Neither touches the RBG rules. FIPS 204 — Planning note 2026-07-31; errata spreadsheet lists 12 items. None changes an RBG strength rule; one (2025-12-02, Sec. 5) changes the notation for an RBG failure from NULL to ⊥. FIPS 205 — No planning note or errata listed.