Qubits, timelines, and keys we use today.

I’ll be honest, I am not a quantum physicist. I write JavaScript and Python for a living, and most of what I know about qubits comes from reading way too many Hacker News threads. This year though, a couple of those threads were different enough that I wanted to write about them, mostly because they actually affect the code people like me write.

The running joke was that quantum computers have been “10 years away” for about 30 years. That joke is starting to age badly.

Qubits, But Which Ones?

Quick bit of vocabulary first, because almost every headline I’ve seen mixes these up.

• Physical qubits are the actual hardware. They are noisy, and they lose their state if you so much as look at them wrong.
• Logical qubits are what the algorithms actually run on. Error correction bundles a bunch of physical qubits together so they act like one reliable qubit.

So when a company says their chip has some number of qubits, that number on its own doesn’t tell you a lot. The question that matters is how many physical qubits it takes to get enough logical qubits to run something useful. Like, actually useful. Not a demo.

That ratio is the thing that moved this year.

Well…

In the span of about a week this spring, two papers dropped.

The first was from Google. They found a much cheaper way to run Shor’s algorithm against 256-bit elliptic curves, which is the math behind P-256 and secp256k1 (the curve Bitcoin uses). The weird part? They didn’t publish the circuit. They “published” a zero-knowledge proof that the circuit exists, so people could verify the claim without getting a recipe. I had never seen a result announced like that before, and apparently neither had Scott Aaronson, who wrote about both papers (HN discussion).

The second was on the hardware side. Better error correction means you need way fewer physical qubits per logical one. A Caltech group estimated around 25,000 physical qubits might be enough to go after that kind of crypto, and a separate paper from Oratomic put it as low as 10,000 on neutral-atom hardware.

A year earlier, the best estimates were in the millions.

Millions. To ten thousand. In a year.

To be fair, a lot of people in the comments pushed back on how many assumptions both papers make, and those are worth reading too. Nobody actually knows the date. But every estimate is moving in the same direction, and it isn’t the comfortable one.

The Bet

Filippo Valsorda, a cryptography engineer and the author of the age encryption tool, wrote A Cryptography Engineer’s Perspective on Quantum Computing Timelines (HN discussion) right after, and one line really stuck with me:

“are you 100% sure a CRQC will NOT exist in 2030?”

A CRQC is a cryptographically relevant quantum computer. Basically, one big enough to break real keys, not just factor 21 for a press release. Google’s own security leads have set 2029 as their deadline for being ready. That is not very far away.

What I like about how he frames it is that it flips the question around. It isn’t “will it happen?” It’s “can you promise it won’t?” I can’t. I don’t think anyone can.

Not Everything Is On Fire

Now for the good news! Not all crypto is affected equally.

Kind of crypto	Examples	Quantum threat
Public-key	RSA, ECDSA, ECDH, Ed25519	Broken by Shor’s algorithm
Symmetric and hashing	AES-128, AES-256, SHA-256, HMAC	Effectively safe

Filippo did a follow-up, Quantum Computers Are Not a Threat to 128-Bit Symmetric Keys (HN discussion), where he actually does the math on attacking AES-128 with Grover’s algorithm. The answer is roughly 140 trillion quantum circuits, each with 724 logical qubits, all running in parallel for 10 years. Yeah… I think AES is fine.

AES-128 is safe against quantum computers. SHA-256 is safe against quantum computers. No symmetric key sizes have to change as part of the post-quantum transition.

So there’s no need to double every key size in a panic. Please don’t.

My Take!

As someone who mostly works in JS and Python, this mostly comes down to knowing where public-key crypto is hiding in my own stuff. For me, that is:

• TLS between services
• Signed tokens, e.g. JWTs using RS256 or ES256 (both of those are public-key)
• SSH keys and code signing
• Anything encrypted today that still needs to be secret years from now, since someone could save it now and decrypt it later

The replacements already exist and are standardized: ML-KEM for key exchange and ML-DSA for signatures. For most of us, the move isn’t to go implement lattice crypto by hand (please don’t do that either). It’s to keep runtimes, TLS libraries, and platforms up to date, and to pick ones that already support post-quantum key exchange when you have the choice.

Quantum computing is still one of the coolest fields to watch, and I’m genuinely excited to see where the hardware goes. I’d just rather my keys not be part of the demo. :’)