The Dependency Most Teams Overlook
Post-quantum cryptographic algorithms are designed to resist attacks from quantum computers. ML-KEM (CRYSTALS-Kyber) and ML-DSA (CRYSTALS-Dilithium), the recently standardized algorithms from NIST, are built on lattice problems that are believed to be hard for both classical and quantum adversaries. But a lattice-based key pair is only as secure as the randomness used to generate it.
This is not an observation unique to post-quantum algorithms. RSA and ECC key generation also depend on random number generators. The difference is that PQC deployment is creating a wave of new key generation operations at organizations that may not have recently audited their entropy sources, and the key generation processes for ML-KEM involve different distributions and sampling procedures than classical algorithms, which can expose weaknesses in RNGs that classical key generation did not stress.
The NIST PQC standards explicitly address randomness requirements. FIPS 203 (ML-KEM) requires the use of an approved deterministic random bit generator (DRBG) as specified in NIST SP 800-90A, seeded with entropy from a source meeting NIST SP 800-90B. These are specific, testable requirements, not general guidance. Teams implementing PQC key generation should verify their RNG stack against these specifications, not assume that any FIPS-compliant RNG is adequate.
Classes of RNG and Their Failure Modes
There are three broad classes of random number generators relevant to cryptographic key generation, with different entropy properties and different failure modes.
Hardware RNGs (HRNGs) draw entropy from physical processes: thermal noise in resistors, shot noise in semiconductor junctions, or radioactive decay. These sources have true randomness in the information-theoretic sense, but they produce entropy at limited rates and must be conditioned (processed through a hash or compression function) before use. The failure mode for HRNGs is typically hardware degradation, manufacturing variation, or environmental interference that reduces the entropy rate without triggering software-visible errors. A HRNG that is producing biased outputs due to temperature or aging looks correct to software-level monitoring.
Pseudorandom number generators (PRNGs) and deterministic RBGs generate a long sequence from a short seed using a deterministic algorithm. NIST-approved DRBGs in SP 800-90A include HMAC-DRBG and CTR-DRBG. These are cryptographically strong algorithms for stretching entropy, but their security is entirely contingent on the seed quality: a DRBG seeded with low-entropy input produces a predictable output, regardless of the algorithm's theoretical security. The failure mode is seed pollution: insufficient entropy at the time of seeding, or reuse of seed material across instances.
Software entropy pools, like Linux's /dev/urandom or /dev/random, aggregate entropy from multiple hardware sources and kernel events. On modern systems, these are generally well-designed and adequately seeded. The known failure mode is at early boot: in virtual machines or containerized environments, the entropy pool may not be adequately seeded at the time of first key generation. This is a well-documented issue for cloud-deployed services that generate keys at startup, and it has caused real-world cryptographic weaknesses in both RSA and ECC key generation.
Post-Quantum Key Generation Under Increased Entropy Demand
ML-KEM key generation requires more random bytes than equivalent RSA or ECC operations. An ML-KEM-768 key pair generation requires 64 bytes of randomness for the key seeds, and the encapsulation operation requires an additional 32 bytes of randomness per encapsulation. At high connection rates, the entropy demand on the key generation path increases accordingly.
For software-based endpoints that generate ML-KEM ephemeral keys inline at TLS session establishment, this entropy demand scales with connection rate. At 10,000 TLS connections per second, the key generation path consumes roughly 640,000 bytes of random seed material per second, over and above the randomness used for other cryptographic operations. In environments where entropy sources have limited throughput, this can create subtle starvation effects: the DRBG reseed events become more frequent, and if the hardware entropy source cannot keep up with the reseed rate, the DRBG begins running in a low-reseed mode with older seed material than the security model assumes.
This is not a theoretical concern. We have seen entropy starvation symptoms in test deployments on constrained hardware. The symptom is not key generation failure, which would be detectable, but imperceptibly reduced entropy in seed material, which requires active monitoring to detect. Standard system entropy pool metrics (entropy_avail on Linux) do not directly measure the health of the DRBG seed pipeline under load; they measure the pool fill level, which can look healthy even when the reseed rate is below the intended threshold.
Quantum Random Number Generation as a Solution
Quantum random number generators (QRNGs) produce randomness from inherently quantum-mechanical processes: photon arrival times, photon beam splitting outcomes, or vacuum fluctuations. The randomness is certified by quantum physics rather than by mathematical assumptions. For PQC key generation, a QRNG provides both the strong randomness quality and the generation rate needed to avoid entropy starvation under high connection loads.
There is a direct architectural connection between satellite QKD operations and QRNG. The quantum optics equipment at a QKD ground station, which detects individual photon arrivals to extract key material from a satellite pass, generates a byproduct of quantum randomness at a rate typically much higher than the extracted key rate. The quantum detection events that are discarded in the key distillation process (events where both parties do not agree on measurement basis, which are discarded in BB84 protocol) still have quantum randomness that can be harvested as QRNG output.
A QKD ground station that is also functioning as a QRNG provides locally trusted, high-entropy randomness for PQC key generation at connected servers. The QRNG output rate is limited by the photon detection rate at the ground station, which is typically in the megabit-per-second range for current satellite QKD optical systems. This is more than adequate for entropy feeding even at high ML-KEM connection rates.
Testing Entropy Quality in Production
The NIST SP 800-90B standard defines a set of entropy estimation tests for validating the statistical quality of entropy sources. These are full-scale validation tests, appropriate for device certification, and not practical for routine production monitoring. NIST SP 800-90C describes how tested entropy sources should be composed into a full RBG, and provides guidance on monitoring in operational environments.
For practical production monitoring, several approaches are useful. The first is entropy rate monitoring: instrumenting the DRBG reseed events and tracking whether the hardware entropy input rate is keeping pace with reseed demand under load. This requires instrumentation at the kernel or cryptographic library layer, not just at the application layer. The second is periodic statistical testing of entropy output samples: running NIST SP 800-22 statistical tests against samples drawn from the production DRBG output periodically, not as a certification test but as a canary for entropy source degradation. The third is hardware health monitoring for HRNGs: vendor-specific interfaces often expose temperature, noise floor, and self-test results that can be tracked over time for anomaly detection.
We are not suggesting that weak entropy sources are the most likely attack vector against PQC deployments. The cryptographic algorithms themselves and their implementation quality are also important. But entropy quality is the dependency that is most commonly under-monitored in production deployments, and for PQC key generation specifically, the increased entropy demand means that assumptions about entropy health that were adequate for classical key generation need to be revisited.
