Entropy & Randomness
Master entropy sources, DRBG mechanisms, and quantum randomness — NIST SP 800-90 standards, entropy testing, TRNG vs QRNG, and combining sources for defense-in-depth.
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.
- 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.
- OS (crypto.getRandomValues, /dev/urandom)
- Hardware (Intel RDRAND, ARM RNDR)
- Continuous health monitoring per SP 800-90B
- 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.
DRBG Mechanisms (SP 800-90A)
SP 800-90A Rev. 1 (2015) defines approved DRBG mechanisms using symmetric primitives. All are quantum-safe — Grover's algorithm at most halves the effective key length, which is addressed by using 256-bit keys to achieve PQC Security Categories 3 and 5.
Most widely deployed. Default in OpenSSL and Linux kernel. Uses AES in counter mode.
Strengths: Fast on hardware with AES-NI. Well-studied. FIPS-validated implementations widely available.
Uses hash functions for state update and output. Simpler construction with larger internal state.
Strengths: No block cipher dependency. Larger state resists state compromise. Good for resource-constrained devices.
Used in deterministic signatures (RFC 6979). Strongest security proof of the three mechanisms.
Strengths: Provable security reduction to HMAC. Used for deterministic ECDSA. Clean extract-then-expand design.
Added in SP 800-90A Rev 2. Uses extendable-output functions (XOFs) for state update and output.
Strengths: Ideal synergy with PQC algorithms (like ML-KEM and ML-DSA) that heavily utilize SHAKE. Highly parallelizable.
Note: SP 800-90A Rev. 2 removes deprecated TDES and SHA-1, and adds XOF_DRBG (SHAKE-based), which synergizes perfectly with the SHAKE-heavy PQC algorithms (ML-KEM, ML-DSA).
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.
Detects stuck-at failures by flagging repeated outputs. If the same value appears more than a threshold number of consecutive times, the source is considered failed.
Detects bias by tracking the frequency of the most common value within a sliding window. Flags the source if any value appears disproportionately often.
- Most Common Value
- Collision
- Markov
- Compression
- t-Tuple
- Longest Repeated Substring
- 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
The Entropy Source Validation (ESV) program, part of NIST's CMVP, provides formal certification of entropy sources used in FIPS-validated cryptographic modules.
- Launched April 2022 as part of NIST's Cryptographic Module Validation Program
- Separate from FIPS 140-3 module validation — entropy sources are validated independently
- Allows reuse of validated entropy sources across multiple module validations
- Automated process via ESV Server web API for submitting samples and receiving results
vs
| Property | TRNG | QRNG |
|---|---|---|
| Physical Source | Thermal noise, shot noise, clock jitter | Photon detection, vacuum fluctuations, beam splitting |
| Randomness Basis | Classical physics (chaotic/unpredictable processes) | Quantum mechanics (Born rule, measurement uncertainty) |
| Common Hardware | Intel RDRAND/RDSEED, ARM RNDR, TPM RNG | ID Quantique Quantis, Toshiba QRNG, ANU vacuum source |
| Throughput | ~1-3 Gbps (Intel RDRAND) | ~1-4 Gbps (commercial devices) |
| Quantum-Safe | Yes — not based on computational assumptions | Yes — guaranteed by quantum physics |
| Availability | Built into most modern CPUs and security chips | Standalone devices or cloud API services |
| Cost | Included in CPU (no additional cost) | $500-5,000+ for hardware; cloud API pricing varies |
| Certification | NIST ESV, FIPS 140-3, Common Criteria | NIST ESV (emerging), BSI AIS 31, proprietary certification |
Combining Sources for PQC
Current TRNG implementations are already quantum-safe because they rely on physical noise processes, not computational assumptions that quantum computers could break.
Combining TRNG and QRNG sources provides additional assurance for post-quantum cryptographic systems:
- Defense-in-depth: If one source is compromised or experiences a failure, the other still provides entropy
- SP 800-90C framework: Provides the standard construction for combining multiple entropy sources into a single RBG
- XOR combination: XORing two independent sources preserves the entropy of the stronger source — an attacker must break both
- Conditioning: HMAC or hash conditioning distributes entropy uniformly across the output, removing any bias from individual sources
FIPS 203 & 204 Seed Requirements
- ML-KEM (FIPS 203): Explicitly requires exactly 32 bytes of full entropy directly from the RBG to generate the
dandzseeds during encapsulation and key generation. - ML-DSA (FIPS 204): Requires exactly 32 bytes of full entropy to derive the
ρ(rho),ρ'(rhoprime), andKseeds. - Strength Match: Per SP 800-131A Rev 3, to achieve PQC Security Category 5 (equivalent to AES-256), your RBG must operate at a 256-bit security strength. Do not feed a 128-bit DRBG into an ML-KEM-1024 keypair generation.