NIST SP 800-90A: DRBG Standards

Cryptographic operations need high-quality random numbers: key generation, nonces, IVs, salts, and session tokens. True random number generators (TRNGs) harvest entropy from physical sources (hardware noise, interrupts, thermal noise) but are slow and not always available — especially in virtual machines or early boot. Deterministic Random Bit Generators (DRBGs) solve this: seed a DRBG with a small amount of true entropy and use a cryptographic algorithm to stretch it into a large stream of pseudorandom bits that are computationally indistinguishable from true random. NIST SP 800-90A defines three approved DRBG mechanisms used in virtually all modern cryptographic implementations.

A DRBG operates through three fundamental operations. Instantiate: initialize the DRBG internal state using entropy_input (from an entropy source), a nonce (a one-time value ensuring uniqueness), and optionally a personalization_string (application-specific context). Generate: produce the requested number of pseudorandom bits and update internal state to prevent backtracking. Reseed: inject fresh entropy into the DRBG state to provide prediction resistance — after reseeding, even an adversary who knew the previous state cannot predict future outputs. NIST specifies maximum generate intervals (reseed_interval): 2^48 requests before mandatory reseeding for all three DRBG types.

NIST SP 800-90A defines four security strength levels: 112, 128, 192, and 256 bits. The security strength determines the minimum entropy required at instantiation and the generated output quality. For 128-bit security, the entropy input must provide at least 128 bits of entropy. The relationship: security_strength bits of entropy -> DRBG output computationally indistinguishable from random by an adversary with 2^security_strength operations. Key length choices (AES-128 vs AES-256) and hash choices (SHA-256 vs SHA-512) are constrained to match or exceed the desired security strength. Over-parameterizing (SHA-512 for 128-bit security) is safe but wasteful; under-parameterizing breaks security.

Hash_DRBG maintains two state values: V (a value that generates output) and C (a constant added during generate). Generate: hash_gen produces bits by iterating H(0x01 || V), H(0x01 || V+1), ... until enough output is available; then V is updated with V = V + H(0x03 || V) + C + reseed_counter. Reseed: uses Hash_df (hash derivation function) combining the current V with fresh entropy to produce new V and C. Hash_DRBG is straightforward to implement and has a simple security analysis, making it suitable for constrained environments. NIST recommends SHA-256 or SHA-512 instantiation. Hash_DRBG is used in Java's SHA1PRNG (older) and OpenSSL's legacy DRBG.

HMAC_DRBG maintains state (Key K, Value V). Generate: iterates V = HMAC(K, V) until enough output is produced; then K = HMAC(K, V || 0x00) and V = HMAC(K, V). Update: takes additional_input and reseeds K and V using HMAC operations. HMAC_DRBG has a clean security proof based on HMAC security (PRF assumption on HMAC). It is the most widely recommended DRBG: OpenSSL (since 1.1.1), mbedTLS, wolfSSL, and most TLS stacks use HMAC_DRBG. The HMAC construction provides built-in mixing between successive calls, making backtracking attacks harder to mount even if state is partially exposed.

CTR_DRBG uses a block cipher (AES) in counter mode. State: Key K and counter V. Generate: encrypts successive counter values E(K, V), E(K, V+1), ... and increments V. Update: uses Block_Cipher_df to derive new K and V from additional_input. CTR_DRBG is the fastest DRBG — AES-NI hardware acceleration makes it orders of magnitude faster than hash-based DRBGs on modern processors. It is the default DRBG in Windows CNG (CryptGenRandom uses CTR_DRBG with AES-256), OpenSSL 3.0 (default), and Linux kernel RNG (getrandom syscall). CTR_DRBG security relies on AES being a pseudorandom permutation, which is well-supported by decades of analysis.

Prediction resistance is a property where the DRBG output is unpredictable even to an adversary who previously compromised the DRBG state, provided fresh entropy is mixed in via reseeding. A DRBG with prediction_resistance_flag=true calls the entropy source before each Generate call to inject fresh entropy. Without prediction resistance, state compromise at time T allows computing all future outputs (forward security is broken). Backward security (also called backtracking resistance) means past outputs are unpredictable even if current state is known — HMAC_DRBG and CTR_DRBG achieve this via their update steps that derive a new key from the current state after each Generate.

SP 800-90A specifies the DRBG algorithms but not the entropy source. SP 800-90B defines requirements for entropy sources: hardware noise sources must be characterized and validated, entropy estimates must be conservative, and health tests must detect entropy source failures. SP 800-90C specifies how to combine entropy sources with DRBGs into complete random bit generators. Typical entropy sources: CPU RDRAND/RDSEED (hardware RNG, available on Intel/AMD CPUs since 2012), OS entropy (/dev/urandom on Linux, BCryptGenRandom on Windows), hardware security modules, TPM 2.0 RNG, and environmental noise (disk timing, network jitter). Low-entropy conditions (virtual machines, early boot) require special handling to avoid weak seeds.

FIPS 140-3 (the current standard for cryptographic module validation) mandates NIST SP 800-90A DRBGs for all random number generation within certified modules. The module must: use an approved DRBG (Hash, HMAC, or CTR), seed from an approved entropy source meeting SP 800-90B requirements, perform power-on self-tests (POST) verifying DRBG operation, implement continuous RNG tests (CRNGT) detecting stuck-at-zero or stuck-at-one entropy failures, and support reseed when the entropy source indicates available entropy. HSMs (Thales Luna, AWS CloudHSM, Utimaco), TLS accelerator cards, and network encryption appliances commonly require FIPS 140-3 validated modules, driving adoption of SP 800-90A.

Modern operating systems maintain a kernel-level DRBG seeded from hardware entropy sources. Linux uses a ChaCha20-based DRBG (since kernel 5.17, replacing the older Fortuna-like design) seeded from RDRAND, interrupts, and disk/network events. /dev/urandom returns DRBG output and is non-blocking once initially seeded. /dev/random blocks until sufficient entropy is available (legacy behavior, mostly removed in recent kernels). getrandom(2) syscall is the modern interface, blocking only at early boot before the DRBG is seeded. Windows uses CTR_DRBG (AES-256) in the kernel RNG, seeded from the TPM and hardware events. Applications should use the OS DRBG via high-level APIs rather than seeding their own DRBGs from timestamps or PIDs.

Real-world DRBG vulnerabilities arise from implementation errors rather than algorithm weaknesses. (1) Insufficient seeding: seeding with only the current timestamp or PID gives attackers a guessable seed. (2) Fork blindness: when a process forks, both parent and child share the same DRBG state — they generate identical random numbers. Fix: reseed after fork (pthread_atfork or explicit getrandom call). (3) VM snapshot reuse: if a VM snapshot is restored, the DRBG state returns to the snapshot state, generating previously seen output. Fix: inject unique entropy on VM startup (VIRTIO RNG). (4) Failing health tests silently: a DRBG that continues generating after detecting an entropy failure provides attacker-predictable output. (5) Reusing nonces across DRBG instances.

What property does reseeding a DRBG with fresh entropy provide?

NIST SP 800-90A defines three approved DRBG mechanisms: Hash_DRBG (iterative hash, simple), HMAC_DRBG (HMAC-based, clean security proof, widely deployed), and CTR_DRBG (AES counter mode, fastest via AES-NI, default in Windows/OpenSSL). All share the Instantiate/Generate/Reseed lifecycle with a reseed_interval limit of 2^48. Security strength (112-256 bits) drives entropy requirements. Prediction resistance requires reseeding before each Generate call. FIPS 140-3 mandates SP 800-90A DRBGs with SP 800-90B entropy sources. Fork blindness, VM snapshot reuse, and insufficient seeding are the main real-world implementation pitfalls.