
Why You Can’t Patch Bad Entropy away
Crypto-agility has become the rallying cry of the post-quantum migration. The idea is simple and, for most of the cryptographic stack, correct: build systems so that when an algorithm is broken or deprecated, you swap it out via a software or firmware update rather than a hardware redesign. NIST’s ML-KEM and ML-DSA rollouts are being engineered with exactly this philosophy – modular, upgradable, future-proofed. But there is one layer of the stack where crypto-agility quietly breaks down: the entropy source.
The Agility Illusion
Every cryptographic key, nonce, and signature ultimately traces back to a seed of randomness. If that randomness is weak, predictable, or reconstructible, it doesn’t matter how strong the algorithm wrapped around it is – the whole system inherits the weakness. The last few years have made this brutally concrete. The Randstorm flaw exposed roughly 1.4M BTC because a JavaScript library silently fell back to weak Math.random() output. The Milk Sad vulnerability in Libbitcoin Explorer exposed over 120,000 private keys because a PRNG was seeded from a 32-bit system-time value. And most recently, a Coldcard hardware wallet firmware bug bypassed its own dedicated hardware RNG chip, silently falling back to a deterministic software PRNG seeded from non-secret device data – draining over $88M from thousands of wallets.techspot+3
In every case, the cryptography itself was sound. The entropy underneath it was not.
Why “Just Patch It” Doesn’t Work Here
Crypto-agility works when you can swap an algorithm’s mathematical logic while its inputs and interfaces stay the same. A firmware update can replace SHA-256 with SHA-3, or RSA with ML-KEM, because these are deterministic transformations of data you already control. An entropy source is different in kind, not just degree: it is a physical process, not a computation.
- A software or firmware update can change how randomness is processed (extraction, conditioning, DRBG seeding), but it cannot change whether the underlying physical process was ever unpredictable in the first place.
- If a PRNG’s weakness stems from insufficient physical noise, insufficient timing jitter, or a predictable seed source, no patch retroactively injects the missing physical entropy into keys already generated.
- Every key derived from a compromised entropy source remains compromised forever, even after the “fix” ships – this is why Randstorm-era wallets and affected Coldcard seeds require migration to entirely new keys, not a firmware update to the old ones.thehackernews+1
In other words, you can be crypto-agile about the lock. You cannot be crypto-agile about the key blank it was cut from.
The Overlooked Attack Surface in the PQ Transition
This is precisely the blind spot in most PQC migration roadmaps. ML-KEM and ML-DSA are engineered to resist Shor’s algorithm, but they still require a source of high-quality randomness to generate keys and, in some schemes, nonces. If that entropy still comes from a classical PRNG or a naively-implemented TRNG, you’ve placed a quantum-resistant lock on a door with a reconstructible key. Worse, classical entropy-expansion techniques – using a hash function or DRBG to stretch a small entropy pool into a larger keystream – introduce structure that Grover’s algorithm can exploit, cutting the effective security margin roughly in half.cryptalabs+1
The entropy layer, in short, is on track to become the next major weak point once the PQC algorithm transition itself is complete.
Why QRNG Without Expansion Is the Right Foundation
A Quantum Random Number Generator solves this at the physical layer rather than the algorithmic one. QRNGs derive randomness from fundamentally probabilistic quantum phenomena – such as the Heisenberg uncertainty in photon detection – rather than from deterministic algorithms or noisy-but-classical processes like thermal drift or oscillator jitter. There is no seed state to reconstruct and no algorithm to reverse-engineer, because there is no algorithm generating the randomness in the first place.blocventures+1
The “without expansion” part matters just as much as the “quantum” part. Traditional TRNGs are often bandwidth-limited, forcing designers to artificially stretch a small entropy pool using a hash function or DRBG to keep up with demand. That expansion step is exactly where classical structure creeps back in, and exactly where Grover’s algorithm gets its use. A QRNG fast enough to avoid this trade-off entirely – outputting raw, high min-entropy bits at Mbit/s to Gbit/s rates – removes the incentive to expand in the first place, since the physical process itself supplies randomness in abundance rather than scarcity.linkedin+1
This is also why the conditioning step matters: rather than expanding entropy, a well-designed QRNG uses a NIST-approved conditioning component that compresses raw quantum measurements into fewer, higher-quality bits, distilling out residual classical noise while preserving the quantum unpredictability underneath. Feeding that directly into a DRBG seed – or, for high-throughput applications, directly into key generation – closes the exact gap that PRNG-based entropy sources have repeatedly failed at across Randstorm, Milk Sad, ECDSA nonce and the Coldcard incident,
The Bottom Line
Post-quantum cryptography protects against tomorrow’s mathematical attacks, but it inherits yesterday’s entropy problem unless the randomness underneath it is addressed directly. Crypto-agility is the right mental model for algorithms because they are software. It is the wrong mental model for entropy sources because they are physics – you cannot firmware-update your way into a noise source that was never truly unpredictable to begin with. A QRNG that generates genuine quantum randomness at sufficient speed to avoid classical expansion isn’t just a nice-to-have alongside PQC migration; it is the only entropy foundation that doesn’t quietly reintroduce the exact vulnerability class PQC was supposed to eliminate.
