What are ML-KEM random number generator requirements?

ML-KEM random number generator requirements are the rules that govern where the secret random seeds for ML-KEM key generation and encapsulation come from. NIST FIPS 203 requires these bytes to come from an approved random bit generator (RBG), built to NIST SP 800-90A, SP 800-90B and SP 800-90C. In an encryption gateway this matters a lot: the strength of the post-quantum session key depends on whether the RNG is unpredictable.

OT and critical infrastructure operators feel this more than most. Their gateways are often headless appliances. They boot in quiet substations or plant networks and may run fully air-gapped. Those conditions make it harder to collect entropy, and they also limit how you can verify it.

Why does ML-KEM need a secure random number generator?

ML-KEM uses fresh secret randomness in key generation and again in every encapsulation. If those values can be predicted, the keys and shared secrets can be predicted too. The standard is explicit: three algorithms in this standard require the generation of randomness: K-PKE.KeyGen, ML-KEM.KeyGen, and ML-KEM.Encaps.

FIPS 203 does not leave the source open to choice. Its notation for random sampling carries the requirement that an array of ℓ random bytes… must be freshly generated using randomness from an approved RBG. The standard also treats the randomness itself as secret material. KEM security depends on the secrecy of several values, including the randomness used by the two parties, the decapsulation key, and the shared secret key itself.

NIST SP 800-227, the companion recommendation for KEMs, spells out where approved randomness comes from: random bits shall be generated using approved techniques, as described in the latest revisions of SP 800-90A, SP 800-90B, and SP 800-90C. The draft NIST SP 800-133 Rev. 3 points the same way. Among its proposed changes, key-encapsulation mechanisms (KEMs) are discussed as a key-establishment option for symmetric key generation, and its text has been reworded to address random number generation in alignment with SP 800-90C.

The security strength has to match the parameter set

An RBG can only supply as much security strength as it was instantiated with. Guidance written for ML-KEM in other protocols makes this concrete: the RBG MUST have a security strength of at least 128 bits for ML-KEM-512, at least 192 bits for ML-KEM-768, and at least 256 bits for ML-KEM-1024. If a gateway runs ML-KEM-1024 on a DRBG seeded at 128 bits, it has quietly given up most of the margin it was deployed for.

Can a weak RNG in an encryption gateway leak information through ML-KEM encapsulation?

Yes. ML-KEM encapsulation is deterministic once its 32-byte random input is fixed, so a guessable input makes the post-quantum shared secret guessable as well. The ciphertext does not reveal the secret directly. The risk is that the space of possible inputs becomes small enough to search.

Here is the mechanism. The encapsulating side takes a random message m and derives the shared key and the encryption randomness from m and a hash of the public encapsulation key. Anyone who sees the handshake also sees that public key and the ciphertext. If m came from a generator with only a few bits of real entropy (for example, one seeded from a boot counter and a clock), an observer can re-run encapsulation for each candidate m. A candidate whose ciphertext matches the one on the wire also gives the shared secret.

Earlier drafts of the algorithm had a safety net for this. The draft FIPS 203 explains that an extra hashing step on m existed and that the purpose of this step was to safeguard against the use of flawed randomness generation processes. As this standard requires the use of NIST-approved randomness generation, this step is unnecessary and is not performed in ML-KEM. In practice, final ML-KEM puts the whole burden on the RBG.

Reuse is the second failure mode. Protocol drafts for ML-KEM state plainly that implementations MUST NOT reuse randomness in the generation of KEM ciphertexts. Reuse can happen without any software bug, for example when a virtual gateway is restored from a snapshot and replays the same DRBG state. Gateways that renew keys often depend on fresh randomness all the time. QPN from Quantum Network, for example, renews both its classical and its ML-KEM handshakes every two minutes. That turns RNG health into a continuous operational property rather than something checked once at installation.

The historical evidence from network devices

Concern about embedded RNGs comes from real measurements, mostly of small network appliances. The 2012 “Mining Your Ps and Qs” study by Heninger, Durumeric, Wustrow and Halderman produced the figures below (as summarised by NIST):

• 0.75% of TLS certificates share keys due to insufficient entropy during key generation (2012).
• Researchers were able to obtain RSA private keys for 0.50% of TLS hosts and DSA private keys for 1.03% of SSH hosts (2012).
• A follow-up study aggregated internet-wide TLS scans from 2010-2016 and computed GCDs for 81.2 million RSA moduli (2016).

A NIST paper on the study notes that almost all vulnerable hosts were headless or embedded network devices like routers or firewalls. Encryption gateways in OT networks fit that description.

How do embedded OT devices get enough entropy for post-quantum key exchange?

They need a physical noise source that is assessed to SP 800-90B and runs health tests. They should also have a boot sequence that refuses to generate keys until the DRBG has been seeded to its full security strength. Workarounds that stretch weak entropy do not replace these two things.

Why OT hardware starts at a disadvantage

Desktop systems collect timing noise from keyboards, mice and disk activity. A DIN-rail gateway or a headless x86 box in a control cabinet has none of these. NIST describes such hosts as ones that often run a pared-down Linux kernel and do not have the usual random events from input devices. The riskiest moment is first boot, when devices generate keys during first boot when an entropy pool is not strong enough to produce unique keys.

Practical measures that hold up

• Use a validated hardware or jitter noise source. Modern x86 processors include an on-die hardware random number instruction. CPU timing-jitter sources are another option and have their own SP 800-90B validations. One CMVP public-use document describes a source that gathers its entropy from the time deltas between memory access operations.
• Block until seeded. Key generation should wait for the kernel or crypto module to report a fully seeded generator. Validated sources often enforce this themselves: there is no output available from the entropy source before successful completion of the start-up tests.
• Combine independent sources. SP 800-133 allows several inputs to be combined, provided that at least one of the methods provides randomness equal to or greater than the randomness required for the resulting key. Mixing in a seed injected at provisioning time can therefore add strength but cannot subtract it.
• Hedge with RFC 8937. RFC 8937 describes how to augment their CSPRNGs using long-term private keys. Its security argument is that if the CSPRNG is broken or controlled by adversary Adv, the output of the proposed construction remains indistinguishable from random provided the private key remains unknown to Adv.
• Treat VM snapshots as an entropy event. Virtual gateways should reseed after a restore or clone, so that two instances never share DRBG state.

Air-gapped deployments cannot use network-delivered entropy. NIST has explored that approach as “Entropy as a Service”, but an isolated plant network has to be self-sufficient. This is why the quality of the local noise source matters even more in sites that are deliberately cut off.

What do NIST SP 800-90A and SP 800-90B require for entropy sources?

SP 800-90B defines how to build and assess the entropy source: the noise source, min-entropy estimation and mandatory health tests. SP 800-90A defines the deterministic generators (DRBGs) that stretch that entropy into key material. SP 800-90C defines how the two are combined into a complete RBG.

The two mandatory health tests

SP 800-90B provides two approved health tests: the Repetition Count test, and the Adaptive Proportion test. The Repetition Count Test catches a source that has become stuck on one value. The Adaptive Proportion Test is designed to detect a large loss of entropy that might occur as a result of some physical failure or environmental change affecting the noise source.

The cutoffs are tuned against false alarms. In NIST’s 2012 design discussion, John Kelsey described choosing the Repetition Count cutoff so that the false-positive probability falls below 2^-30. The trade-off is deliberate: NIST notes the tests can’t tolerate high false positive rate, so tests aren’t too powerful. They catch catastrophic failures. They do not prove a source is good.

Environmental change deserves attention in OT settings. SP 800-90B advises that health tests should place special emphasis on the detection of misbehavior near the boundary between the nominal operating environment and abnormal conditions. Extreme cabinet temperatures, voltage sag and electromagnetic noise near drives are exactly those boundaries.

NIST cryptographer John Kelsey summed up the underlying concept in his overview of SP 800-90B: “Entropy is how we quantify unpredictability.”

How do you check RNG quality on offline or air-gapped hardware?

Test the raw noise source, not the DRBG output. Check the health-test and seeding behaviour of the device. Compare public keys across the fleet for duplicates. All three checks run without internet access.

A workable offline procedure

1. Read the validation documentation first. If the module or entropy source has a CMVP public-use document, it states the min-entropy claim, the conditioning and the health tests. For example, one such document records that the source implements both the approved Repetition Count Test (RCT) and Adaptive Proportion Test (APT).
2. Collect raw noise samples on the isolated device. For SP 800-90B assessment, raw data samples must be collected when the entropy source is in test mode, in which case the health tests are disabled. Export the samples via removable media under your normal media-handling procedure.
3. Run NIST’s SP 800-90B estimators on an offline workstation. NIST publishes reference code for the estimators. Compare the result with the vendor’s claim, and repeat at the temperature extremes of the real installation.
4. Do restart tests. Power-cycle the device repeatedly and capture the first samples after each boot. Similar early outputs across restarts point to the first-boot problem described above.
5. Check fleet-wide uniqueness. Collect ML-KEM encapsulation keys and classical public keys from every gateway and look for duplicates. The existence of duplicate keys or, even worse, RSA public keys with a single common prime factor, is an indication that keys are being generated using insufficient entropy.
6. Monitor health-test failures in operation. Logged entropy-source failures should feed into the local monitoring of the site, not be silently retried.

For gateways that by design send no telemetry and have no cloud dependency, such as QPN from Quantum Network, these checks belong in the site’s own commissioning and maintenance routine. They should not depend on a remote service.

RFC 8937 states the stakes in one sentence: “Weak or predictable “cryptographically secure” pseudorandom number generators (CSPRNGs) can be abused or exploited for malicious purposes.” Moving to ML-KEM does not change this. It adds one more algorithm that depends on the same generator.