quantum computing encryption

The Quantum Computer Is Coming: Why Today’s Encryption Could Soon Be Useless

ByImran Valiani

Quantum computing threatens RSA, banking, crypto wallets, and global security faster than most people think.

Quantum computing encryption is no longer a distant research problem — it’s an active threat to the systems protecting your money, your data, and your identity right now.

Let me start somewhere weird.

20 million. That’s how many noisy qubits researchers thought you’d need to break RSA-2048 back in 2021 (per Gidney & Ekerå, Quantum Vol. 5, p. 433). A big scary number. Everyone breathed out.

Then in May 2025, the same researcher — Craig Gidney — published a new solo paper (arXiv preprint 2505.15917) saying: actually, under a million. Same job. Less gear. Longer run time — under a week — but still. Twenty million to one million. In four years.

I think that’s the number people should be talking about. They’re not, really. Not enough.

Anyway. Let me back up.

The Basic Bet That Holds the Internet Together

quantum computing encryption
AI-generated illustration. Created using Google Flow

Here’s how it works right now — and I’ll keep this short.

TLS, RSA, ECC, ECDSA. These are the locks on everything. Your bank. Your email. Bitcoin in a cold wallet. The padlock in your browser tab. TLS is the protocol that sets up the connection; RSA and ECC are the public-key math underneath it — RSA leans on factoring being hard, ECC (and ECDSA, the signature version of it) leans on a related but different hard problem, the elliptic-curve discrete log. Different math, same basic bet: some problems are too hard for classical computers to solve in any useful timeframe.

RSA-2048 specifically — widely deployed across banking, health, and government infrastructure — gives you 112 bits of security strength against classical machines, per NIST SP 800-57 Part 1 Rev. 5 (Table 2). In practice, brute force can’t touch it. Not now. Not with anything that runs today.

Key word: classical.

That’s the whole thing. That one word. The moment a fault-tolerant quantum computer capable of running Shor’s algorithm exists, the math breaks.

I know what you’re thinking — “yeah but that’s sci-fi, right?” And I get it. Honestly, three years ago I’d have agreed. But I’ve noticed, working in hardware, that the people most likely to wave this off are the furthest from the silicon. The closer you are to how chips actually get made and shipped and deployed, the less you wave it off.

How Quantum Computing Encryption Works — And Why It Breaks Everything

Classical chips: bits. One or zero. That’s it.

Qubits can be both at once — superposition. Pair that with entanglement and interference and you don’t get a faster chip. You get a different kind of machine. One that can crack specific math problems in ways classical gear just can’t.

The one that matters here: Shor’s Algorithm. Developed by Peter Shor in 1994 at AT&T Bell Labs. Published formally in the SIAM Journal on Computing (Vol. 26, No. 5, 1997). It breaks integer factorization — the math RSA runs on — exponentially faster than the best classical methods we know of. And it breaks the elliptic-curve discrete log problem that ECDSA runs on. Same tool. Two kills.

One algorithm. Two problem classes. Game over for public-key crypto.

Then there’s Grover’s Algorithm — less dramatic but still worth knowing. It doesn’t break symmetric encryption outright, but it roughly halves its effective strength, in terms of the computational effort needed to search the keyspace. AES-128 goes from 128-bit to roughly 64-bit effective security. Breakable. AES-256 drops to roughly 128-bit — still fine. The point: if you’re running AES-128 anywhere, migrating to AES-256 is part of this same process. Not a side task. Part of it.

On the other hand, maybe I’m overstating Grover’s urgency — AES-256 does survive, and most serious systems already run it. But if you’re on 128? Don’t wait.

Where the Hardware Is Right Now — Honestly

Not there yet. I want to be straight about that.

IBM’s Condor crossed 1,000 qubits — 1,121 superconducting qubits, announced at the IBM Quantum Summit on December 4, 2023. Impressive. Also the wrong metric. Fault-tolerant logical qubits are what actually matter, and those need quantum error correction (QEC) at a scale nobody has hit yet. We’re still in the NISQ era — noisy intermediate-scale quantum. Useful for some research. Not for cracking RSA. Not yet.

But the direction of the resource estimates is what I keep coming back to. Twenty million down to one million. In four years. I think if you’re making long-horizon security decisions — and if you work in finance, defense, health, or infrastructure, you are — that trend line is the thing to watch. Not whether we’re there today.

Worth understanding why that number moved so much in four years. Resource estimates like this aren’t hardware measurements — they’re models built on specific assumptions about circuit design and error correction. When those assumptions get refined, the estimated requirement can shrink without a single physical qubit being built. That’s exactly why treating any one number as the “safe until then” threshold is a bad strategy — the model behind it can move again.

The Attack That Doesn’t Need a Quantum Computer Yet

Okay, here’s the part that actually keeps me up.

You don’t need quantum hardware to start the attack. You need it to finish it.

Security agencies are increasingly operating on the assumption that adversaries are already harvesting encrypted traffic right now — storing it, waiting for the hardware to catch up. CISA and the NSA put this in their August 2022 joint advisory “Quantum-Readiness: Migration to Post-Quantum Cryptography.” The name for the strategy: harvest now, decrypt later (HNDL).

Grab the data. Sit on it. Crack it later.

Medical files. Legal docs. M&A talks. State comms. Anything that has to stay secret for the next ten to fifteen years is, in theory, already inside that window. Sitting in an archive. Waiting.

That’s not fearmongering. That’s the formal planning assumption of two major U.S. security agencies. At the end of the day, if CISA and NSA are building their playbooks around this — maybe take it seriously. And it’s worth remembering that most of this traffic travels through 570 submarine cables on the ocean floor — infrastructure that was never designed with quantum-era interception in mind.

What’s Actually at Risk — Let Me Be Real With You

The Whole Web’s Trust Chain

Every publicly trusted HTTPS connection goes through an X.509 cert from a certificate authority. That cert typically relies on RSA or ECDSA for its signature, and the connection’s key exchange typically relies on RSA, ECC, or (increasingly) ECDHE. A quantum computer running Shor’s doesn’t just break one site. It breaks the system that lets you know any site is what it says it is. Code-signing certs. S/MIME email. All of it.

Not a patch. A rebuild. Full stop.

Crypto — And There’s a Nuance Here Most People Miss

In my experience this is the one people get most wrong. Bitcoin and Ethereum both sign transactions with ECDSA on the secp256k1 curve. Yes, Shor’s could derive a private key from an exposed public key — eventually. But take Bitcoin specifically: for the most common legacy and SegWit address types (P2PKH, P2WPKH), a Bitcoin address isn’t the public key itself. It’s a HASH160 digest — RIPEMD-160 of SHA-256 of the public key. If that kind of wallet has never sent funds, its public key isn’t even on-chain yet. It shows up the moment you broadcast a transaction. That’s the exposure window.

One important update to that picture: Taproot (P2TR) addresses — Bitcoin’s newest and increasingly popular format — don’t follow this pattern. They put the full public key on-chain by design — specifically, the tweaked Taproot output key — from the moment funds are received, not just at spend. Researchers have flagged this as an actual step backward for quantum resistance compared to older address types. So the “safe until spend” rule above applies to P2PKH/P2WPKH — not to Taproot.

What’s already exposed on the older address types? Reused addresses. Signed a transaction from that address before? The public key is on-chain. Permanently. That’s the real risk right now — not a theoretical future threat, but current exposure waiting on a future exploit. Use each Bitcoin address once. Done.

(Ethereum’s exposure follows a very similar hashing mechanism — an address is a truncated hash of the public key, hidden until first use — but Ethereum’s account model conventionally reuses the same address for years, which means practical exposure across the network runs much higher than on Bitcoin. Same underlying mechanism, very different real-world exposure. That’s Ethereum’s own problem to unpack, not this one.)

Banking

SWIFT moves trillions of dollars in messages a day, and parts of its messaging security rely on the same public-key math as everything else on this list. The BIS called out the quantum risk to financial-sector cryptography in its 2023 Annual Economic Report. The plumbing of global finance faces the same category of exposure as your browser lock — not an identical system, but the same underlying math problem. Not great.

And it’s not just financial infrastructure. Modern EVs carry the same category of risk in their hardware — ECUs rely on public-key cryptography for things like secure boot and firmware signing, and those functions face the same quantum exposure as everything else here. CAN bus itself is a separate story — it has its own well-documented security gaps that have nothing to do with quantum computing — but the cryptographic functions sitting on top of it are squarely in scope.

Enterprise VPN

IKEv2 — runs most enterprise VPN — uses Diffie-Hellman key exchange. Shor’s breaks both classical DH and ECDH via the discrete log problem. The NSA’s CNSA 2.0 advisory (September 2022) moves classical DH and RSA out for new National Security Systems, in favor of quantum-resistant algorithms. I’ve found that fact moves conversations faster than anything else I can say in a meeting. When the NSA stops using something — draw your own conclusions.

The same vulnerability runs deeper than software. Self-driving cars have hardware security problems in their ECUs and CAN bus architecture that follow the exact same pattern — cryptographic assumptions baked into silicon that no firmware update can fix.

NIST Did Their Part. August 2024.

Three standards. Done.

  • ML-KEM (FIPS 203, formerly CRYSTALS-Kyber) — key encapsulation
  • ML-DSA (FIPS 204, formerly CRYSTALS-Dilithium) — digital signatures
  • SLH-DSA (FIPS 205, formerly SPHINCS+) — stateless hash-based sigs

Not drafts. Ratified. The which-algorithm question is closed. The only open question is why you haven’t started — because standardizing the algorithms is not the same thing as migrating to them.

For migration, hybrid key establishment is the move — run X25519 or ECDH P-384 alongside ML-KEM in the same handshake. One breaks, the other holds. NIST IR 8547 (2024 initial public draft) backs it; NIST SP 800-56C Rev. 2 handles the key derivation underneath.

I keep coming back to Signal. They shipped PQXDH — Post-Quantum Extended Diffie-Hellman — in 2023. A messaging app. Beat most banks to it. If you’re in finance and you don’t have a migration plan yet — I’m not going to say you should feel bad. But. You know.

What to Do — In Order

Here’s what I actually tell people.

Step one: inventory. Not your software stack — your components. Every chip running RSA, ECC, or DH. Every HSM. Every secure enclave. Every embedded device. I go deep on why this gets complicated in Part 2: Your Embedded Hardware Has a Quantum Problem Nobody Is Talking About, because crypto baked into hardware doesn’t get swapped with a patch. Some stuff needs physical replacement. Find out which stuff before you’re at a deadline, not after.

Here’s the mechanism. If the cryptographic function is implemented in fixed-function silicon — logic burned into the chip instead of a flexible software routine — a new algorithm can’t always be introduced through firmware. That turns a standards change into a hardware-lifecycle problem: the device stays physically fine while becoming cryptographically obsolete. Not every device works this way — some run crypto in software, or on programmable accelerators, or through secure elements built for algorithm updates, and those can often migrate in place. Fixed-function silicon usually can’t. Same deadline. Different outcome, depending entirely on how the hardware was architected in the first place.

And here’s the distinction people skip past. A mathematically secure algorithm doesn’t make the device secure. The hardware still has to protect the private keys, execute the algorithm correctly, and keep its boot and update process from being tampered with — none of which changes just because you swapped the math. Migrating the algorithm is one part of the job. Migrating the security architecture that holds the keys is the harder part, and it’s a separate project entirely.

Step two: sort by shelf life. What has to stay secret for a decade or more? That data is already inside the HNDL window. Start there.

Step three: start evaluating ML-KEM and ML-DSA now. Don’t sweat the learning curve — that’s what your team is for. But don’t wait either. RFC 8446 standardized TLS 1.3 back in August 2018, and by most industry accounts broad adoption still took years — for a migration that was simpler than this one. Way simpler. History says start early.

Step four: stop reusing crypto addresses. Free. Takes minutes. Just do it.

No Date. But a Clear Direction.

I think — and I could be wrong — that the people most surprised when this becomes urgent will be the ones who read pieces like this and thought “yeah, eventually.” Eventually has a way of arriving faster than the slide decks suggest.

The NCSC’s March 2025 roadmap sets migration milestones for 2028, 2031, and 2035 — these are UK government migration targets, not predictions of when a quantum computer capable of breaking encryption will exist. NSA’s CNSA 2.0 timeline runs into the 2030s for full National Security System transition. RAND’s 2023 ICS/OT assessment (RR-A2427-1) is a risk assessment concluding that migration is necessary because quantum computing will eventually threaten public-key cryptography across critical infrastructure — it is not a forecast of exactly when that happens. Nobody gives you a date. But nobody serious is saying don’t worry about it either.

Two decades in hardware. Here’s what I know: the harvest may already be running. Standards are on the desk. Every month this sits on the backlog is another month of ciphertext piling up in archives that will one day be readable.

The quantum computer is coming. What’s protecting most of the world’s systems right now wasn’t built with it in mind.

This goes well beyond laptops and servers. Smart city hardware — IoT sensors, 5G nodes, edge computing systems across urban infrastructure — relies on the same category of public-key cryptography, and carries the same quantum exposure, even though the specific implementations vary widely. The attack surface is everywhere.

Start the inventory. This week.

Hardware side of this? Read Part 2: Your Embedded Hardware Has a Quantum Problem Nobody Is Talking About — ML-KEM memory constraints on ARM Cortex-M chips, TPM realities, FPGA bitstream gaps, and what a quantum-aware board design actually takes.

About the Author

Imran Valiani | Sales Director, PCB Electronics Manufacturing

20+ years working with major Bay Area and global tech clients. Founder of Silicon to Software, where I write about the hardware layer — PCB fab, AI gear, autonomous systems, and cyber — the stuff most tech writers have never touched. Literally.

Follow: X @SiToSoftware | LinkedIn

For more analysis of technologies moving from research toward real engineering constraints, explore the Emerging Technologies Resource Hub.

This article was developed with AI assistance and edited, fact-checked, and reviewed by the author. See my full AI disclosure.

Sources & Further Reading

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *