Trust Me, I'm Random: Zero Trust Entropy for PQC

Every key your cloud HSM or KMS generates relies on one assumption nobody in your SOC can verify: that the RNG feeding it is actually random. That assumption has failed before, in certified hardware, silently, for years. Taiwan's national ID smartcards were FIPS 140-2 Level 2 and Common Criteria certified and still shipped factorable RSA keys, found by outside researchers factoring the public keys, not by the devices and not by the auditors. Debian's OpenSSL entropy bug ran undetected for nearly two years. Someone edited a constant in Juniper's ScreenOS ‘Dual_EC’ parameters and nothing alerted. Post-quantum migration sharpens this: an ML-KEM or ML-DSA private key is exactly as strong as the seed behind it, and we are re-keying the internet on top of black-box entropy right now.

Statistical testing cannot save you. A generator whose output an adversary chose in advance passes every SP 800-90B health test and every Dieharder suite, by construction. Certification is a point-in-time snapshot of a device that then runs unobserved in someone else's datacenter for five years. You have no telemetry, no detection, and no forensic trail on the most foundational component in your cryptographic stack.

We have solved this shape of problem before, just never here. Reproducible builds and SLSA replaced ‘trust the build server’ with evidence. Certificate Transparency accepted that misissuance cannot be prevented and made it publicly detectable and replayable instead. Remote attestation did it for workloads. Each was the same move: stop asking operators to be trustworthy, start requiring them to emit artifacts anyone can check. Entropy is the last link in the chain still running on trust-by-assumption, and it is the link everything else is built on.

This talk is about what that move looks like for randomness. I present FQR-CSS, from my peer-reviewed paper in Discover Computing (DOI: 10.1007/s10791-026-09994-y), staying strictly on the part implementable today. The generator is made to prove its own health. Each QRNG node precommits to a seed before the session, then publishes a post-quantum zk-STARK over its classical measurement log asserting that the log satisfies a stated physical predicate: a CHSH score above threshold, a photon-number distribution passing chi-square, measurement bases derived from the pre-committed seed. The raw log never leaves the device. An aggregation layer verifies every proof and runs BFT consensus, so only attested contributions reach the mixer. The client receives randomness plus a Merkle-rooted integrity token it verifies itself and an auditor can replay months later against a transparency log.

No new quantum hardware is required: the proofs are over classical logs that commercial QRNGs already emit, using standard post-quantum ZKPs. I walk through reproducible zk-STARK benchmarks and a full latency budget: roughly 396 ms end-to-end for a conservative CHSH attestation over WAN with HotStuff consensus, of which client verification is sub-millisecond. That fits inside high-assurance key generation and disappears behind a pre-verified randomness buffer. The scope is deliberate and I will state it plainly: this is a cryptographic architecture with benchmarked primitives, not a hardware product. It attests entropy provenance at generation time, not that a key was never exfiltrated afterwards.

Key Takeaways:

1. Why RNG compromise is undetectable in today's cloud HSM/KMS deployments, and why output-side statistical testing structurally cannot catch a chosen-output generator.
2. Why the random number generator is the last implicitly trusted component in a stack where zero trust has already been applied to networks, identities, workloads and machines, and what ``verify explicitly, assume breach'' means when the subject is a physical entropy source rather than a user or a workload.
3. What to do before any of this ships: entropy provenance in key metadata, multi-source mixing so no single vendor dominates, transparency-logged precommits, and fail-closed attestation policy for CA and HSM key generation.