Entropy and Random Number Generation in Cryptographic Systems

Cryptographic systems depend on unpredictability as a foundational property — without it, keys can be reconstructed, sessions hijacked, and ciphertext reversed. Entropy, the measurable quantity of randomness available to a system, directly determines whether generated keys, nonces, and initialization vectors are computationally infeasible to predict. This page covers the definitions, mechanisms, failure modes, and professional decision points relevant to entropy and random number generation (RNG) across US cryptographic contexts.

Definition and scope

Entropy, in the information-theoretic sense formalized by Claude Shannon in 1948, measures uncertainty in a data source. In cryptographic practice, entropy is quantified in bits: a source yielding 256 bits of entropy produces values that cannot be predicted without exhausting 2²⁵⁶ possibilities. NIST SP 800-90B, Recommendation for the Entropy Sources Used for Random Bit Generation, defines entropy sources and establishes testing requirements for cryptographic modules.

Random number generators in cryptographic systems fall into three recognized classifications:

  1. True Random Number Generators (TRNGs) — draw from physical phenomena (thermal noise, radioactive decay, photon timing). Output is non-deterministic.
  2. Pseudorandom Number Generators (PRNGs) — algorithmic processes that produce statistically random-appearing sequences from a deterministic seed. Predictable if the seed is known.
  3. Cryptographically Secure Pseudorandom Number Generators (CSPRNGs) — a constrained subclass of PRNGs meeting forward secrecy and backtracking resistance requirements. NIST SP 800-90A defines approved CSPRNG constructions including Hash_DRBG, HMAC_DRBG, and CTR_DRBG.

The scope of entropy requirements extends across key management practices, certificate issuance by certificate authorities, and session negotiation in TLS/SSL protocols. Systems subject to FIPS 140 validation must use entropy sources and DRBGs that conform to NIST SP 800-90A and SP 800-90B.

How it works

Entropy generation follows a structured pipeline from raw physical collection through conditioning, health testing, and output seeding.

Phase 1 — Entropy Collection
Hardware sources (ring oscillators, jitter-based circuits, hardware security module internal sensors) sample physical phenomena. Operating systems such as Linux expose this through /dev/random and /dev/urandom interfaces, which pool hardware events including interrupt timing and disk I/O latency. Windows uses the CNG (Cryptography Next Generation) API, which draws from similar hardware event pools.

Phase 2 — Conditioning
Raw entropy samples contain bias and correlation. Conditioning functions — typically hash-based extractors — compress raw bits into a smaller, statistically uniform output. NIST SP 800-90B specifies approved conditioning components and their entropy estimation requirements.

Phase 3 — Health Testing
NIST SP 800-90B mandates two categories of continuous health tests: the Repetition Count Test (RCT) and Adaptive Proportion Test (APT). These detect entropy source failures in real time. Startup tests run before the entropy source is first used.

Phase 4 — DRBG Seeding and Output
The conditioned entropy seeds a Deterministic Random Bit Generator. The DRBG maintains internal state and produces output bitstrings on demand. Reseeding intervals are bounded: NIST SP 800-90A limits CTR_DRBG with AES-256 to 2⁴⁸ generate requests before mandatory reseeding.

Hardware Security Modules (HSMs) typically embed certified TRNGs compliant with FIPS 140-2 or FIPS 140-3, bypassing reliance on OS-level entropy pools for high-assurance applications.

Common scenarios

Key Generation
Asymmetric key pairs for RSA and elliptic curve cryptography require high-quality entropy at generation time. A 2012 research study published by Lenstra, Heninger, and collaborators identified that approximately 0.2% of RSA public keys in a corpus of 7.1 million certificates shared prime factors — a direct consequence of weak entropy during key generation on embedded and network devices.

Session Nonces and Initialization Vectors
TLS handshakes require nonces and random session identifiers. Reuse of nonces in AEAD cipher modes (such as AES-GCM) catastrophically compromises confidentiality. The IETF documents nonce requirements in RFC 5246 and RFC 8446.

Virtual and Cloud Environments
Virtualized guests present a structural entropy starvation problem: virtualized hardware lacks the physical interrupt diversity of bare-metal systems. Cloud providers including those operating under FedRAMP requirements address this through paravirtualized entropy devices (virtio-rng) or by exposing host hardware RNG output to guests. Intel's RDRAND and RDSEED CPU instructions provide hardware entropy accessible inside virtual machines.

Embedded and IoT Devices
Low-power microcontrollers used in IoT deployments frequently lack hardware RNG peripherals, forcing reliance on software entropy pools seeded from predictable boot-time values. NIST IR 8259A identifies entropy quality as a core IoT device cybersecurity baseline capability.

Post-Quantum Cryptography
NIST's post-quantum algorithm selections (CRYSTALS-Kyber, CRYSTALS-Dilithium, SPHINCS+) retain dependence on high-entropy random number generation for key encapsulation and signing. Entropy requirements do not diminish under lattice-based schemes.

Decision boundaries

Practitioners and system architects face defined decision points when specifying RNG components for cryptographic systems:

The NIST cryptographic guidelines and the CMVP, administered jointly by NIST and the Canadian Centre for Cyber Security, define the authoritative conformance framework for entropy and RNG in US-regulated cryptographic contexts.

References

Explore This Site

Regulations & Safety Regulatory References