Entropy and Random Number Generation in Cryptographic Systems

Entropy and random number generation occupy a foundational position in applied cryptography: without unpredictable, high-quality randomness, even mathematically sound algorithms are reduced to breakable constructs. This page describes how entropy is defined and measured in cryptographic contexts, the mechanisms by which random number generators produce or harvest it, the scenarios where entropy failures cause real security degradation, and the decision criteria governing which generator class is appropriate for a given deployment. The treatment covers both the technical structure and the regulatory expectations set by standards bodies including NIST.

Definition and scope

Entropy, in the cryptographic sense, measures the unpredictability of a data source — specifically, the minimum number of bits an adversary must guess to reproduce a value. NIST Special Publication 800-90A defines entropy as "a measure of the disorder or unpredictability of a system," and quantifies it in bits: a source with 128 bits of entropy requires 2¹²⁸ guesses to exhaust the possibility space. This is distinct from the information-theoretic definition of entropy attributed to Shannon, which measures average information content; cryptographic entropy specifically concerns the minimum entropy (min-entropy) of a source, representing the worst-case unpredictability an attacker faces.

The scope of this topic extends across key generation, nonce production, initialization vector (IV) selection, session token creation, padding schemes, and challenge-response protocols. Wherever a cryptographic operation requires a value that an adversary cannot predict, an entropy source and a compliant random number generator are required components — not optional additions. Failures in entropy have historically enabled mass key recovery attacks against embedded devices and public-key infrastructure, making this one of the highest-consequence components in the encryption service landscape.

Random number generators in cryptographic systems are classified under three primary categories:

1. True Random Number Generators (TRNGs) — harvest entropy from physical phenomena (thermal noise, photoelectric effects, radioactive decay). Output is non-deterministic and cannot be reproduced.
2. Pseudorandom Number Generators (PRNGs) — deterministic algorithms that expand a seed value into a long output stream. Output is entirely reproducible given the same seed; security depends entirely on seed quality and algorithm design.
3. Cryptographically Secure Pseudorandom Number Generators (CSPRNGs) — PRNGs designed to meet specific security properties: forward secrecy (past outputs cannot be derived from future state) and backtracking resistance (future outputs cannot be derived from past state). NIST FIPS 140-3 requires that modules implementing random bit generation use approved CSPRNG constructions.

How it works

A practical cryptographic random number generation system operates in three phases: entropy collection, conditioning, and generation.

Phase 1 — Entropy Collection: An entropy source gathers raw bits from physical or environmental inputs. Operating systems expose this through interfaces such as /dev/urandom on Linux-based systems or the BCryptGenRandom API on Windows. Hardware Security Modules (HSMs) incorporate dedicated TRNGs that sample electrical noise from on-chip analog circuits. NIST SP 800-90B (SP 800-90B) specifies how entropy sources must be tested and validated, including restart tests and sequential tests to confirm that source behavior is not predictable.

Phase 2 — Conditioning: Raw entropy sources often exhibit statistical biases — they are not uniformly distributed. A conditioning function (typically a cryptographic hash or block cipher in a specific mode) transforms the raw bits into an output that more closely approaches uniform distribution. SP 800-90B defines two categories: approved conditioning components (which provide full entropy credit) and vetted conditioning components.

Phase 3 — Generation: A CSPRNG algorithm such as CTR_DRBG (Counter-mode Deterministic Random Bit Generator), HASH_DRBG, or HMAC_DRBG — all defined in NIST SP 800-90A Rev. 1 — uses the conditioned seed to produce a bitstream. CTR_DRBG, which uses AES-256 internally, is the most widely deployed construction in FIPS 140-3 validated modules. Each DRBG must be reseeded after a defined number of requests (the reseed interval for CTR_DRBG with AES-256 is 2⁴⁸ requests per NIST SP 800-90A).

The security model requires that seed material contain at least as much entropy as the targeted security strength. A 256-bit security strength, as required for AES-256 key generation, requires a seed with a minimum of 256 bits of entropy — not merely 256 random-appearing bits.

Common scenarios

Low-entropy boot conditions: Embedded systems and virtual machines frequently generate keys shortly after startup, before sufficient entropy has accumulated. This scenario has caused real-world mass key duplication. Research published in 2012 by Heninger et al. ("Mining Your Ps and Qs") demonstrated that scanning 5.8 million TLS and SSH public keys revealed that 0.2% of TLS keys and 1.03% of SSH keys shared prime factors — a direct consequence of low-entropy key generation in embedded devices. This represents a structural failure mode, not a configuration error.

Virtualized environments: Hypervisors that clone virtual machines — including snapshots and templates — can cause two separate instances to share CSPRNG state, generating identical key material. NIST SP 800-90A addresses this through the requirement for per-instance seeding before any key generation, including a fresh entropy input that cannot be inherited from a cloned state.

Long-running server processes: A CSPRNG seeded at process start and never reseeded accumulates output over time without refreshing entropy. Although CSPRNGs are designed to be computationally secure, NIST-recommended practice, reflected in SP 800-90A, requires periodic reseeding to inject fresh entropy and maintain backtracking resistance.

Post-quantum algorithm parameter generation: Lattice-based algorithms such as CRYSTALS-Kyber and CRYSTALS-Dilithium — both standardized by NIST in FIPS 203 and FIPS 204 respectively — require high-quality randomness for key and signature generation. The parameter spaces involved are significantly larger than classical algorithms, making entropy quality more consequential, not less.

These scenarios connect directly to the broader question of how encryption resources are structured within compliance-driven deployment contexts.

Decision boundaries

Selecting between TRNG, PRNG, and CSPRNG architectures — or combinations — requires resolving four structural questions:

Is FIPS 140-3 validation required? Federal agencies and contractors under FISMA must use cryptographic modules validated under FIPS 140-3 (NIST FIPS 140-3). This mandates use of SP 800-90A DRBG constructions — specifically CTR_DRBG, HASH_DRBG, or HMAC_DRBG — with entropy inputs validated under SP 800-90B. PRNG constructions that do not meet these specifications are non-compliant, regardless of their apparent output quality.

What is the deployment lifecycle and reseed opportunity? Devices that operate for extended periods without network access or system-level entropy refreshes — industrial controllers, smart meters, offline HSMs — must be provisioned with sufficient initial entropy to sustain the full operational period. Devices that can reseed frequently from OS-level entropy pools may tolerate lighter initial seeding.

TRNG vs. CSPRNG trade-off: TRNGs produce non-deterministic output and are suitable for seed generation. However, raw TRNG output cannot be used directly for bulk key material without conditioning: bit rates from hardware TRNGs typically range from a few hundred kilobits per second to low megabits per second, which is insufficient for high-volume cryptographic workloads. The standard architecture — TRNG feeding a CSPRNG — combines unpredictability with throughput. This architecture is described in NIST SP 800-90C (third public draft), which specifies how entropy sources, conditioning functions, and DRBGs compose into complete random bit generation systems.

Continuous health testing: NIST SP 800-90B and FIPS 140-3 require that entropy sources be subjected to continuous health tests during operation — not merely at initialization. The two mandated tests are the Repetition Count Test and the Adaptive Proportion Test. Failure of a health test must cause the module to enter an error state and halt output. This is a hard architectural requirement, not a recommended practice, and distinguishes compliant entropy sources from ad hoc solutions.

The relationship between entropy quality and overall cryptographic posture is described further in the .