In development. RVNT is pre-release — not yet security-audited. Source code, public builds, and the iOS / App Store release aren’t available yet. See the roadmap →

The Quantum Clock Just Moved: Google Shrinks the Cost of Breaking ECC

post-quantumelliptic-curveharvest-now-decrypt-laterml-kem-768key-exchange

On 30 March 2026, Google Quantum AI published a paper that made a number of people in cryptography sit up. It estimates that breaking 256-bit elliptic-curve cryptography — the kind that secures the key exchange in most secure messengers, and nearly all cryptocurrency — would require roughly 1,200 logical qubits and under 500,000 physical qubits, with the attack itself completing “in minutes” on a sufficiently advanced machine. The paper frames this as roughly an order-of-magnitude reduction in the resources thought necessary, compared with earlier work.

It would be easy to read that as “the sky is falling.” It would also be wrong. But it would be equally wrong to shrug it off. The accurate reading is more interesting than either, and it has a direct, practical consequence for how encrypted communication should be built today.

What was actually announced

Let’s separate the claim from the fear, because this is exactly the kind of result that gets distorted in both directions.

What Google did not do is build a quantum computer that breaks encryption. The researchers were explicit: a machine at this scale does not yet exist. Today’s quantum hardware is far too small and far too noisy to run this attack against real key sizes. Nobody’s messages are being decrypted by a quantum computer right now.

What Google did do is improve the theoretical accounting — the estimate of how much quantum hardware a future attack would need. And the estimate keeps shrinking. A few years ago, the resource numbers for breaking real-world public-key cryptography were so enormous that “post-quantum” felt like a problem for the 2040s. The newer analyses, of which this paper is one, have driven those estimates down significantly. The target an attacker has to hit is closer than it looked.

Two pieces of jargon worth a quick translation, because the headline numbers don’t mean much without them:

  • Logical qubits are idealized, error-free qubits — the ones an algorithm actually needs.
  • Physical qubits are the real, noisy hardware. Because they make errors, it takes many physical qubits, woven together with error correction, to simulate one reliable logical qubit.

The gap between the two — ~1,200 logical needing under 500,000 physical — is the engineering challenge of quantum computing in one ratio. The paper isn’t saying the machine is easy. It’s saying the bar for the machine is lower than we used to think.

Why an estimate, not a machine, is still news

If the computer doesn’t exist, why should anyone change anything?

Because of an attack that doesn’t care whether the machine exists yet. It only cares whether it will exist eventually. It’s called harvest now, decrypt later (HNDL), and it works like this:

TODAY:    adversary records your encrypted traffic in bulk  →  stores it
                          (can't read it — doesn't need to yet)

LATER:    a capable quantum computer arrives  →  recover the key exchange
                          →  decrypt everything from the archive

A well-resourced adversary — a state intelligence agency, a telecom that can tap a backbone — captures your encrypted traffic now and simply keeps it. Storage is cheap and ciphertext is small. They’re not betting on a flaw in today’s cryptography. They’re betting on tomorrow’s hardware, applied to today’s recordings.

The classical part of an elliptic-curve key exchange is what a quantum computer would eventually unravel, using Shor’s algorithm, to recover the session keys protecting that recorded traffic. So the relevant question was never “does the machine exist today.” It’s: will this still be a secret when the machine arrives, and is someone keeping a copy until then? When the resource estimates drop, the plausible arrival date moves earlier — and every secret with a long shelf life that’s being recorded right now becomes a little more exposed.

We laid out the full HNDL threat model in Harvest Now, Decrypt Later. The Google paper is, in effect, that post’s central warning getting a timestamp. The buffer between “current capability” and “capability that threatens ECC” just got narrower.

Whose secrets actually need to care

The honest answer is: it depends entirely on your shelf life, and most casual conversation has none.

If your messages are about dinner plans, HNDL is irrelevant to you — by the time any quantum computer could read them, no one will care. But some secrets stay dangerous for a decade or more:

  • A journalist’s source whose identity could end their freedom years from now.
  • Legal and medical records whose confidentiality doesn’t expire on a convenient schedule.
  • A dissident’s network under a regime that archives traffic today and may gain decryption capability later — enabling it to map an entire movement retroactively.

For those cases, the decision about quantum protection cannot be made after the fact. You either encrypted the traffic with quantum resistance before it was recorded, or you didn’t. There is no retroactive fix for a recording already sitting in an archive.

The fix is hybrid — not “go all quantum”

The instinctive reaction to a quantum scare is to rip out classical cryptography and replace it with a post-quantum algorithm. That would be a mistake, and it’s worth understanding why the careful answer is both rather than either.

Post-quantum algorithms are newer. They rest on mathematics — for the lattice family, problems like Module-LWE — that the public cryptographic community has studied for far less time than elliptic curves. NIST standardized them after years of open analysis, and they are very likely sound. But “very likely” is not the standard you want for something protecting a source’s life, and a future classical break of a brand-new scheme would leave you with nothing.

So the responsible design is hybrid key exchange: derive the session key from two independent key agreements at once.

  • X25519 — classical elliptic-curve Diffie-Hellman, battle-tested over decades. Strong against every classical attacker, vulnerable eventually to a quantum one.
  • ML-KEM-768 — the lattice-based key encapsulation mechanism standardized as FIPS 203. Strong against quantum attackers, but newer and less weathered.
session_key = KDF( X25519_shared || ML_KEM_768_shared )

To recover the session key, an attacker must break both the elliptic curve and the lattice. Defeating either one alone gains them nothing. You keep decades of confidence in X25519 and you add quantum resistance, and you only lose if both fail simultaneously. That is the right posture for the period we are actually in — where post-quantum algorithms are trustworthy enough to add, but not so weathered that you’d stake everything on them alone.

What this means for RVNT

This is not a feature we’re announcing in response to the paper. It’s how RVNT already works.

RVNT’s handshake is a hybrid X25519 + ML-KEM-768 key agreement, running inside our hybrid X3DH, and it is on by default — there is no toggle to enable quantum resistance, because security that’s opt-in is security most people never get. From there, every message is protected by the Double Ratchet with a unique key per message, deleted immediately after use, giving forward secrecy on top of the quantum-resistant key exchange. The details are in our post-quantum notes.

The reason this is already default, and not a planned upgrade, is precisely the logic of HNDL: protection has to be in place before the traffic is recorded, not after the machine arrives. A paper that moves the estimate earlier is a paper that vindicates having shipped it early.

The honest limit

We won’t sell you fear, so here are the edges:

  • This is a resource estimate, not a working machine. A cryptographically relevant quantum computer still does not exist publicly, and predicting exactly when one will is genuinely uncertain. Treat anyone giving you a confident date — in either direction — with suspicion.
  • Hybrid protects the key exchange and data in transit — not your endpoints. If malware is on your device, no key agreement helps you. See the threat model.
  • It doesn’t protect against the people you talk to, who can screenshot, forward, or be compelled to hand over a device. Cryptography never touches that.

What changed on 30 March is narrow and real: the estimated cost of one day breaking elliptic-curve cryptography dropped again, which means the window to protect long-lived secrets is shorter than it looked. The defense isn’t to panic. It’s to make sure the traffic worth protecting is already wrapped in something a future machine can’t unwrap — today, by default.

Don’t take our word that RVNT does this. It’s open source under AGPLv3. Read the post-quantum docs, find the ML-KEM-768 in the handshake, and verify the hybrid is wired the way this post says.

Keep reading

All posts →