Earlier this month, Real Random presented at the QSECDEF expert member webinar on exactly this problem. The talk covered a lot of ground — failed entropy at scale, a slot machine that was too honest for casinos, why the gaming industry’s rejection of true randomness turned out to be cryptography’s biggest opportunity, and where the defense community stands right now with two compliance deadlines converging in the next eighteen months. This post captures the key arguments and evidence from that session.
Joerg Fritsch, VP Analyst at Gartner, wrote in the Cool Vendors in Data Security 2025 report that “digital-only defenses no longer suffice” and that physical, non-digital components play an important role in data secrecy. He was right. And the physicist John von Neumann said something similar seventy-five years earlier: “Anyone who considers arithmetical methods of producing random digits is, of course, in a state of sin.”
The reason both statements still matter is the same: the entire cryptographic stack sits on top of a single foundation. Weaken that foundation and everything above it — keys, sessions, signatures, TLS handshakes, VPN tunnels — becomes an illusion of security.
Everything in modern cryptography depends on the same input at the bottom of the stack. From cryptographic keys to nonces and initialization vectors, session and ephemeral material, signature blinding, and TLS / VPN handshakes — all of it rests on one foundation:
Randomness is not a math problem. It’s a supply chain problem. Like any supply chain, it has origin points, intermediaries, failure modes, and adversarial interest. The difference is that most organizations have audited their software supply chains, their hardware vendors, their cloud providers — and almost none of them have audited where their randomness actually comes from.
To understand why this matters in practice, consider three real incidents — not theoretical edge cases, but documented failures that affected millions of systems over periods of months and years.
| 2 Lines removed | 20 Months exposed | 32K Possible keys |
A Debian maintainer removed two lines from OpenSSL while trying to fix a Valgrind warning. Those two lines seeded the random number generator. Without them, the entropy pool collapsed to roughly 32,768 possible keys — the equivalent of a padlock with four digits instead of billions. Every key generated during that twenty-month window was enumerable by any attacker who knew about the bug. Nobody noticed for nearly two years.
Lesson: A single developer decision, invisible to the audit trail, reduced the entire keyspace to something a script could brute-force in minutes.
Official Security Advisory: Debian Security Advisory DSA-1571-1
| 2006 NIST published SP 800-90A | 2007 Backdoor identified | 7 yrs Traffic harvested |
NIST published SP 800-90A in 2006, including Dual_EC_DRBG as one of four approved random bit generators. In 2007, researchers Shumow and Ferguson demonstrated that the algorithm’s constants could enable a backdoor. In 2013, Snowden documents revealed that the NSA had paid RSA $10 million to make Dual_EC the default in the BSAFE library. By 2014, when NIST formally withdrew the algorithm, seven years of harvested traffic were already sitting in storage.
Lesson: Dual_EC’s output was statistically indistinguishable from random. Every test battery passed. The backdoor was undetectable from the output alone — it lived in the design. You cannot test for randomness you don’t have.
Official NIST Withdrawal: NIST Removes Dual_EC_DRBG from Random Number Generator Guidelines
| RDSEED Instruction affected | Silent Reported success | Millions Processors exposed |
AMD’s Zen 5 architecture introduced a silicon-level flaw in the RDSEED instruction — the hardware entropy source that every modern cryptographic library calls first, before any software-level seeding. Under specific conditions, RDSEED returned predictable values while still reporting success. The CPU said the entropy was good. It wasn’t. A microcode patch has been issued. The traffic collected during the exposure window already exists on someone’s drive.
Lesson: Even the hardware you trust to produce randomness can fail silently, at the silicon level, in ways that standard test suites cannot detect from output alone.
Official AMD Security Bulletin: AMD-SB-7055: RDSEED Failure on AMD “Zen 5” Processors
This is the core problem. The three cases above share one characteristic: the entropy failure was invisible at the output level. Test suites passed. Audits signed off. The flawed keys were indistinguishable from strong ones — until an adversary with the right knowledge looked closer. By that point, the window for remediation had already been closed by time.
During the webinar, we ran a live demonstration: two sequences of bits on the screen, labeled A and B. One was true entropy from Real Random’s hardware. The other was a counter, hashed — a deterministic output dressed up to look random.
| The test you cannot pass Your eye can’t tell. Your test suite can’t tell. Your auditor can’t tell. Statistical indistinguishability is not the same as actual randomness — and the difference matters when an adversary has months or years to harvest, analyze, and exploit. |
This is not a criticism of any particular cryptographic library or RNG standard. CSPRNGs, when properly seeded, are useful tools. The issue is the seeding — the moment of genuine entropy injection — and whether that source is physically real, observable, and sovereign. Most systems never ask the question.
The origin of Real Random is not a cryptography lab. It starts with a slot machine.
In 2002, a patent was granted for US 6,394,901 — the “DICEMASTER,” a slot machine that used physical dice instead of digital reels. The invention was demonstrated to the Delaware Lottery Commission and casino teams at Dover Downs. They were impressed. But they couldn’t use it. The reason: house-edge calculations require a known probability distribution. The machine’s physical dice produced outcomes too chaotic to model. Regulators couldn’t certify expected payout. Operators couldn’t price risk. The machine was disqualified for being too random.
| Disqualified from Gambling | Required by Cryptography | |
| Probability | No closed-form distribution — unpredictable | No closed-form distribution — adversary cannot enumerate keys |
| Modeling | House edge cannot be calculated | Output reveals nothing about the next output |
| Certification | Regulators cannot certify expected payout | Defender prices risk in their favor |
| Risk | Operator cannot price risk | Attacker cannot price attack cost |
That inversion became the foundation of Real Random. The technology that gaming couldn’t use — true, unmodelable physical entropy from tumbling dice in viscous fluid — is precisely what security-critical cryptographic systems need and have largely been unable to get at enterprise scale.
Real Random produces entropy the same way the DICEMASTER did — physical dice suspended in viscous fluid, tumbling chaotically, captured by high-speed computer vision. The Brownian motion of the fluid, the collisions between dice, the rotation trajectories — these are extracted as multiple independent dimensions of entropy and combined into a continuous, verifiable output stream.
The result is not modeled randomness. It is not amplified noise. It is observable, physical, sovereign entropy — independently validated to prove it.
| 0.999996 bits / byte (Fourmilab ENT) | 88% NIST STS entropy strength | 9 U.S. patents granted | 2042 foundational IP through |
Independent testing by Rochester Institute of Technology using NIST Statistical Test Suite methodologies confirmed the 88% entropy strength rating — outperforming all natural physical entropy sources including atmospheric conditions and thermal noise by at least 61 percentage points. Fourmilab ENT testing, validated against Random.org, confirmed entropy quality of 0.999996 bits per byte with near-zero serial correlation of 0.003001.
The hardware is available in 2U rackmount form for data center deployment and portable tabletop form for field-deployed environments — a distinction that matters significantly for defense applications.
Read our blog about how Real Random was named a Gartner cool vendor in data security 2025.
Check out the demo video below of our 2U rack mount true random number generator.
Quantum random number generators are often presented as the gold standard for entropy. The underlying physics is sound. But deployment reality is more complicated.
| Requirement | Real Random (Physical TRNG) | QRNG (e.g. ID Quantique, Quantinuum) |
| Entropy source | Dice tumbling in viscous fluid — observable, macroscopic | Beam splitters, vacuum fluctuations — lab-grade photonic |
| Form factor | 2U rack or portable tabletop — field-deployable | Lab bench, rack-mount with active cooling requirements |
| Ruggedization | Built for vibration, temperature variation, humidity | Sensitive to vibration and temperature — lab-optimized |
| Supply chain | U.S.-built, allied components, auditable chain of custody | Specialty optics manufacturing, Thales-concentrated ecosystem |
| Observability | Physically visible — you can see the entropy being generated | Opaque semiconductor or photonic process — black box |
| Integration | Drop-in via REST API — HSM, KMS, OpenSSL, PKCS#11 compatible | Requires specialized drivers and infrastructure |
Both technologies produce physical randomness. Only one was designed for environments outside the lab. For defense programs operating in vehicles, vessels, and forward-deployed communications environments, that distinction is operational, not theoretical.
A common concern with new entropy infrastructure is integration cost. The question is usually: “Do we have to replace our HSMs? Our KMS? Our PKI?” The answer is no.
Real Random is designed to strengthen existing cryptographic stacks, not replace them. The physical entropy source sits behind a standard API and feeds into whatever key management infrastructure is already deployed — Thales, Utimaco, Crypto4A, AWS KMS, Azure Key Vault, or custom implementations. It can be deployed as the primary entropy source or added to a multi-source entropy pool.
The API surface is minimal by design. Four lines of integration code. NIST SP 800-90B aligned. The goal is not disruption — it is reducing the largest unaudited attack surface in most cryptographic deployments.
For defense programs and national security system operators, two compliance events are converging:
| Sep 21, 2026 FIPS 140-2 sunset — modules cannot be procured for new deployments | Jan 1, 2027 CNSA 2.0 takes effect — NSS mandated to use post-quantum cryptography |
Five months between those two dates. Programs that haven’t begun the migration to FIPS 140-3 compliant modules and post-quantum algorithms are already behind. And every migration requires re-examining the entropy sources feeding new key generation — because PQC algorithms, particularly lattice-based schemes like ML-KEM and ML-DSA, require higher volumes of quality entropy than their classical counterparts.
The window is not speculative. September 21, 2026 is not a soft deadline. CNSA 2.0 alignment applies across Five Eyes allied interoperability requirements. Programs that delay now are not buying time — they are accepting risk in a defined and measurable way.
The harvest-now-decrypt-later threat model means that the exposure window is already open. Keys being generated today — against software RNGs, against potentially compromised silicon, against entropy sources no one has audited — are being stored for future decryption as quantum computing capability improves. The adversary does not need Q-Day to arrive before the collection phase. That phase is already underway.
This leads to the hardest question in any defense program’s cryptographic supply chain review: who makes your randomness, where, and under what jurisdiction? For most programs, the honest answer is “we don’t know.” That gap is what adversaries are betting on.
If a supplier cannot answer all three, that is the gap — and it is the gap that harvest-now-decrypt-later attacks are designed to exploit.
The three failure cases in this piece — Debian’s OpenSSL, Dual_EC_DRBG, AMD Zen 5 — are not anomalies. They are the expected output of a cryptographic ecosystem that has treated entropy as an implementation detail rather than a foundational input. Algorithms get audited. Standards get reviewed. Entropy sources get assumed.
Real Random was built from a physical insight — that true randomness cannot come from algorithms, only from physics — and from the operational reality that physical entropy needs to be deployable in enterprise and defense environments without introducing new complexity or vendor lock-in.
The difference between looking random and being random is the difference between hoping you’re secure and knowing you are. With the FIPS 140-2 sunset and CNSA 2.0 mandate both arriving in the next eighteen months, the time for hoping has passed.
