Post-Quantum Cryptography Has an Entropy Problem

Post-quantum cryptography is moving from strategy decks into production environments. Organisations are inventorying cryptography, testing hybrid deployments, planning certificate changes, updating firmware, and preparing for ML-KEM and ML-DSA adoption.

But one dependency is often treated as infrastructure plumbing rather than a security control: entropy.

That is a mistake.

PQC does not change the mathematics of entropy. Shannon entropy is still Shannon entropy. What changes is the operational consequence of getting randomness wrong. In a post-quantum stack, random-bit generation affects key generation, signature generation, lattice-noise sampling, side-channel resistance, fault resilience, compliance posture, and the security strength an organisation can legitimately claim.

The result is simple: a quantum-safe algorithm running on weak, poorly governed, or unvalidated randomness is not a quantum-safe implementation.

The standards already make this clear

NIST FIPS 204, which standardises the Module-Lattice-Based Digital Signature Algorithm, ML-DSA, includes explicit requirements for random-bit generators used in key generation and signing.

For ML-DSA-65, the RBG must provide at least 192 bits of security strength. For ML-DSA-87, the requirement is at least 256 bits. For ML-DSA-44, NIST requires at least 128 bits, while recommending 192 bits. Critically, FIPS 204 states that using an approved RBG with 128-bit but less than 192-bit security strength reduces the claimed security strength of ML-DSA-44 from NIST Category 2 to Category 1.nvlpubs.nist+1

This is not an implementation preference. It is a security and compliance boundary.

An organisation can deploy an approved PQC algorithm and still undermine its target assurance level if the supporting random-bit generation is not matched to the selected parameter set.

Why ML-DSA signing needs fresh randomness

ML-DSA supports a default hedged signing mode. That mode incorporates fresh random data during the signing operation alongside secret material already held in the private key.

The IETF security considerations for ML-DSA make the risk explicit: if an attacker recovers the random bits used during signing, they may be able to recover the signing key. The same guidance warns that deterministic signing can create a fault-injection opportunity. If an adversary obtains a valid and a faulted signature for the same message, comparison of the outputs can potentially expose the private key.ietf

Fresh signing randomness helps break the repeatability that such attacks exploit. The purpose is not only cryptographic unpredictability in the abstract. It is practical resilience against side-channel leakage, faulty implementations, hostile hardware conditions, and active fault attacks.ietf+1

That distinction matters for embedded devices, hardware security modules, secure elements, industrial control systems, connected products, and long-lived signing services. These are exactly the environments where entropy starvation, poor reseeding, shared RNG state, and physical fault attacks can become realistic operational risks.

Lattice security depends on correct sampling

PQC is not one algorithm family. However, lattice-based schemes such as ML-DSA rely heavily on carefully defined sampling processes.

Implementations must produce values according to the distributions specified by the algorithm. Bias, correlations, predictable state, repeated samples, or implementation errors in the randomness path can mean that the samples no longer resemble the distribution assumed by the security analysis.

That is not a cosmetic deviation.

The security arguments behind module-lattice constructions rely on the hardness of problems such as Module-LWE and Module-SIS under their stated assumptions. If an implementation produces structured, biased, or correlated values where the algorithm expects properly sampled randomness, an attacker may gain information that the security proof assumes is unavailable.

The important operational lesson is that randomness is not only an input to PQC. It is part of the algorithm’s security boundary.

Post-quantum-grade entropy

“Post-quantum-grade entropy” is a useful assurance concept. It does not mean that every system needs a quantum random-number generator. PQC does not require quantum randomness.

It means the entropy subsystem must be engineered, validated, and governed to the same level of care as the PQC algorithms it supports.

A post-quantum-grade entropy programme should address:

• An approved RBG with security strength appropriate to the selected PQC parameter set

• Reliable fresh randomness for hedged ML-DSA signing operations

• Adequate capacity for concurrent workloads, reseeding, and repeated sampling operations

• Controls against reuse, bias, correlation, state compromise, and entropy starvation

• Evidence that entropy sources are health-tested at startup and during operation

• Clear ownership, telemetry, documentation, and audit trails across hardware, firmware, operating systems, cryptographic libraries, and cloud services

NIST SP 800-90B provides a useful operational benchmark. It requires health tests on entropy sources, including startup and continuous testing, and requires those tests to operate on noise-source samples before conditioning.nvlpubs.nist

This is the level at which PQC migration becomes real. The cryptographic algorithm is only one component. The entropy source, conditioning function, DRBG, reseed policy, implementation environment, and monitoring controls all influence the security outcome.

The entropy questions every PQC programme should ask

Before declaring a system quantum-safe, security teams should be able to answer a few basic questions.

What entropy source supplies each PQC implementation?

What is its assessed security strength and how does that map to ML-DSA-44, ML-DSA-65, or ML-DSA-87?

Is the system using hedged signing where fault or side-channel risks exist?

How does the platform detect entropy-source degradation, hardware failure, or unexpected output patterns?

Can the system sustain peak signing, key-generation, and sampling demand without reusing state or reducing assurance?

Are firmware, secure elements, HSMs, containers, virtual machines, and cloud workloads drawing from an entropy architecture that has actually been tested?

If those questions cannot be answered with evidence, then the organisation has not completed a PQC migration. It has only deployed PQC software.

The real PQC failure mode

The first serious PQC implementation failures may not come from a breakthrough attack against ML-DSA or ML-KEM. They may come from ordinary engineering weaknesses that have always existed: weak random-number generation, insufficient health testing, incorrect integration, state reuse, poorly managed devices, or assurance claims that exceed what the implementation can support.

PQC raises the cost of ignoring those weaknesses.

Key sizes, certificates, hybrid protocols, and algorithm agility all matter. But none can compensate for an entropy substrate that is weak, unmonitored, or mismatched to the cryptography above it.

If your RBG is weak, your PQC stack is weak.

If entropy governance is missing, your migration is compromised.

If entropy validation is superficial, “quantum-safe” is only a label.

Fix the entropy substrate first. The rest of the PQC roadmap depends on it.

Clauden Higgsbottom - SITG-Consulting

PQC Readiness Assessment | Sitg-Consulting