On March 31, 2026, Google’s Quantum AI team published a whitepaper with a finding the cryptocurrency world needed to hear: future quantum computers may be able to break the cryptography protecting blockchain wallets and transactions with significantly fewer resources than anyone previously estimated.
This is not a distant theoretical concern. It is an engineering problem with a timeline.
The elliptic curve cryptography protecting most blockchains — specifically the 256-bit elliptic curve discrete logarithm problem (ECDLP-256) — has long been considered computationally safe against quantum attack. The assumption was that breaking it would require a quantum computer of enormous scale, far beyond anything buildable in the near term.
Google’s new research changes that picture. Their team compiled two quantum circuits implementing Shor’s algorithm against ECDLP-256. One requires fewer than 1,200 logical qubits and 90 million Toffoli gates. The other uses fewer than 1,450 logical qubits and 70 million Toffoli gates. They estimate these circuits could run on a superconducting quantum computer with fewer than 500,000 physical qubits in a matter of minutes.
That represents roughly a 20-fold reduction in the physical qubit count previously believed necessary. The gap between today’s quantum hardware and cryptographically relevant quantum computers (CRQCs) is narrowing faster than most migration timelines anticipated. Google has set an internal migration target of 2029.
Traditional systems can rotate keys and patch cryptographic libraries without the public necessarily knowing. Blockchain does not work that way. Wallet addresses are public. Transactions are permanent. And many wallet addresses are already exposed on-chain, which gives a sufficiently powerful quantum computer a direct target.
Google’s paper specifically calls out the practice of reusing or exposing wallet addresses as an immediate risk, recommending the cryptocurrency community stop this now, before quantum hardware reaches the relevant scale. This is practical advice that does not require waiting for post-quantum cryptography (PQC) standards to roll out.
The deeper issue is coordination. Migrating a decentralized blockchain to new cryptographic standards requires community consensus, protocol upgrades, and user action at scale. That process takes years even when everyone agrees on the solution. As we covered in our post on how weak entropy led to the LuBian Bitcoin theft, the cryptocurrency ecosystem has already seen what happens when foundational security assumptions go unexamined for too long.
Rather than publishing the actual quantum circuits — which would amount to handing attackers a technical blueprint — Google published a zero-knowledge proof. This allows independent researchers to verify the resource estimates without Google revealing the underlying attack details.
This approach borrows from established responsible disclosure norms in traditional security research, including those used by CERT/CC at Carnegie Mellon University and Google’s own Project Zero, and aligns with ISO/IEC 29147:2018. Applying this framework to quantum cryptanalysis, where the stakes include market confidence alongside technical security, is a model the broader research field should adopt.
Most coverage of this story will focus on the algorithm transition: moving from elliptic curve to post-quantum schemes like CRYSTALS-Dilithium or CRYSTALS-Kyber, which NIST finalized as standards in 2024. That conversation is necessary.
But there is a layer underneath it that rarely gets the attention it deserves: the quality of the randomness used to generate cryptographic keys in the first place.
PQC algorithms are only as strong as the entropy that seeds them. If a blockchain migrates from ECDLP-256 to a post-quantum signature scheme but continues generating keys with low-quality, predictable randomness — through a software PRNG on a virtualized server, a boot-time entropy shortcut, or an IoT device with limited entropy sources — the new algorithm provides a false sense of security. The key material is still weak.
This is not a hypothetical failure mode. Research published at USENIX Security demonstrated at internet scale that weak entropy at key generation time produces RSA keys with shared prime factors — keys that appear valid but are trivially breakable. The Debian OpenSSL bug of 2008 is another concrete example: a single code change gutted the entropy pool and made every key generated on affected systems predictable from a space of fewer than 33,000 possibilities. Both failures share the same root cause. The randomness source was not auditable and was not physically grounded.
The same vulnerability class applies to any public-key system, post-quantum or not. For a broader look at where true entropy matters across different systems and industries, see our TRNG use cases guide.
Google’s 2029 migration target is ambitious for centralized organizations. For cryptocurrency projects, the timeline is arguably more urgent because migration requires decentralized coordination rather than a single engineering sprint.
The practical steps are straightforward, even if the execution is not. Audit which wallet operations expose public keys. Begin evaluating PQC signature schemes for protocol-level integration. And audit the entropy sources feeding key generation across your stack.
That last item is the one most commonly skipped. Entropy is frequently treated as a solved problem, especially in cloud-hosted nodes, containerized environments, and embedded signing hardware. It is not. Entropy quality is assumed far more often than it is verified, and that assumption is exactly the kind of gap a future CRQC can exploit.
Software PRNGs, including CSPRNGs, are deterministic algorithms. Given the same seed, they produce the same output. Seed quality is the ceiling for everything built on top of them. Most OS entropy pools mix in hardware events and environmental noise, which is better than nothing. But those sources can be depleted, emulated, or influenced in ways that are difficult to detect and nearly impossible to audit after the fact.
Real Random’s Entropy-as-a-Service generates entropy from physical dice tumbling in viscous fluid, captured via high-speed computer vision across multiple independent sensors. The randomness comes from fluid turbulence, mechanical collisions, and physical variation that cannot be replicated algorithmically. In independent testing by Rochester Institute of Technology, the system scored an 88% NIST entropy strength rating, with 0.999996 bits per byte confirmed by Fourmilab ENT testing — results statistically indistinguishable from Random.org.
Physical entropy also provides something no algorithm can: visibility. You can watch it. That is what “trust but verify” actually looks like when applied to a randomness source: not just a statistical assertion, but an observable physical process that can be audited at the hardware level. Real Random was recognized as a Gartner Cool Vendor in Data Security 2025 for exactly this approach.
Post-quantum cryptography is the right answer to the algorithm problem Google just quantified. But a PQC migration built on weak entropy is still a weak foundation. The algorithm and the entropy source have to be addressed together.
If your organization is working through PQC migration — whether for blockchain infrastructure, financial systems, or any platform relying on long-lived cryptographic keys — Real Random’s EaaS platform integrates directly into your existing cryptographic stack via REST API or on-prem hardware. It gives your key generation pipeline a verifiable physical entropy source from day one.
