reinkarnation.space / blog

Google Has Set a 2029 Deadline for Quantum-Safe Cryptography. Here Is What That Actually Means.

Published March 30, 2026 | Bhanu Pratap

Back to all posts

On March 31, 2026, Google's Quantum AI team published a technical whitepaper that quietly changed the calculus of modern digital security. The paper, authored by researchers from Google, the Ethereum Foundation, and Stanford University, demonstrates that the elliptic curve cryptography protecting most of the world's digital infrastructure can be broken by a quantum computer using fewer than 500,000 physical qubits—roughly a 20-fold reduction from prior estimates. Alongside this, Google set 2029 as its internal deadline for completing a full migration to post-quantum cryptography, years ahead of the NSA's 2033 target and the broader US government's 2035 guidance.

This is not a theoretical paper about a distant threat. It is a countdown.

What Google Actually Showed

The core of the whitepaper is a set of updated quantum resource estimates for breaking ECDLP-256—the 256-bit Elliptic Curve Discrete Logarithm Problem that underpins elliptic curve cryptography (ECC). ECC is the cryptographic backbone of Bitcoin, Ethereum, most modern SSL/TLS connections, SSH, electronic passports, end-to-end encrypted messaging, secure boot, firmware signing, and cloud infrastructure access.

Google compiled two quantum circuits implementing Shor's algorithm for ECDLP-256:

On a superconducting quantum architecture with standard hardware assumptions consistent with Google's own processors, those circuits could execute in a matter of minutes using fewer than 500,000 physical qubits.

To put that in perspective: in 2019, breaking RSA-2048 was estimated to require approximately 20 million qubits. Recent Google research revised that figure down to 1 million noisy qubits in under a week. Now, for ECC-256 specifically, the number has dropped to under 500,000 qubits in under 10 minutes. The trajectory of these estimates is not reassuring.

Crucially, Google disclosed the resource estimates without disclosing the actual quantum circuits. To prove the validity of their claims without providing a blueprint for attack, they published a zero-knowledge proof—a cryptographic construction allowing any third party to mathematically verify the estimates are correct without receiving the attack details. This is responsible disclosure applied, for the first time, to quantum cryptanalysis.

What Breaks and What Does Not

This is where precision matters enormously, and where most coverage gets it wrong. Not all cryptography is equally vulnerable. The threat is asymmetric.

What is Vulnerable — And Broken by Quantum Computers

What is NOT Broken — Or Significantly Less Threatened

Can Hackers Crack Password Hashes from Old Data Breaches Using Quantum Computers?

The short answer: Not meaningfully, provided the hashing was done correctly.

Bcrypt, scrypt, Argon2id: These are memory-hard password hashing algorithms. Designed to be computationally expensive, Grover's quadratic speedup is dramatically offset by their deliberate memory requirements. A quantum computer doesn't get a free pass on memory constraints against a properly configured modern cost factor.

SHA-256 unsalted hashes: More vulnerable primarily to classical rainbow table attacks. Grover's speedup reduces the search space, but doesn't map well to cracking strong, randomized passwords in practice.

MD5, SHA-1: Already broken classically. Their weakness predates quantum threats.

Quantum computing is not the primary threat to password hashes from legacy breaches. Classical GPU-accelerated cracking remains the dominant real-world threat.

The Three Attack Classes Google Defined

The whitepaper introduces technical distinctions that should inform organizational threat models:

  1. On-Spend Attacks: A quantum computer intercepts a transaction broadcast to the network, derives the private key, and submits a fraudulent transaction before the original confirms. This requires solving ECDLP within block time (400ms for Solana, 12s for Ethereum, ~10m for Bitcoin). Google suggests fast-clock architectures (superconducting) will be capable of on-spend attacks. Attackers don't need to steal stored keys; they can intercept live transactions.
  2. At-Rest Attacks: Targets long-exposed public keys—dormant wallets, reused addresses. Slower quantum computers (ion traps) suffice here. Over 1.7 million BTC locked in P2PK scripts are at risk.
  3. On-Setup Attacks: The most insidious. A CRQC is used once, offline, to recover "toxic waste" from trusted setup ceremonies in zero-knowledge proof systems. This creates a reusable, classical universal exploit. Subsequent attacks require no quantum computer at all.

Harvest Now, Decrypt Later — The Active Threat

Nation-state adversaries are systematically collecting encrypted data today: TLS-protected API calls, corporate VPN traffic, government communications. This data is stored encrypted to be decrypted retroactively once a CRQC is available.

If data transmitted today using RSA or ECC key exchange needs to remain confidential beyond 2029, it is already at risk. Medical records, classified communications, and intellectual property become retrospectively vulnerable on Q-Day.

What Organizations Should Do

  1. Audit your cryptographic inventory: Map every system using RSA, ECDSA, ECDH, or DH key exchange. This is crypto-agility discovery.
  2. Prioritize long-lived sensitive data: Any data that must be confidential past 2029 should be migrated to quantum-safe channels immediately.
  3. Adopt NIST-standardized PQC: ML-KEM (encapsulation) and ML-DSA (signatures) are available in BoringSSL, OpenSSL 3.x via OQS, and major cloud providers.
  4. Retain Symmetric & Hash functions: AES-256 and SHA-256/3 remain quantum-resistant. Limit migration focus to your asymmetric layer.

The timeline has violently shrunk. The transition away from RSA and ECC is the largest coordinated migration in the history of digital infrastructure. The question is no longer whether to migrate. It is whether organizations will choose to do it on their own timeline, or on the attacker's.