Skip to content
A lattice of points in graphite, with a short path through it picked out in violet

6 min read

The quiet rewrite of the internet's handshake

Browsers and servers are already swapping the cryptography that protects every connection — years before the machine that would break it exists. The cost isn't speed, it's bytes.

SamScience and technology writer
Share this article

The deadline nobody can date

There is no working quantum computer that can break the encryption protecting this page. There may not be one for a decade. The migration away from that encryption is happening anyway, and it is worth understanding why the industry decided not to wait.

The reason is an attack that requires no quantum computer at all: Harvest now, decrypt later. Capturing encrypted traffic is cheap, and storage is cheaper. Anything recorded today can be kept until a machine capable of running Shor's algorithm[4] at scale exists, and read then.

The clock that matters is not when the hardware arrives. It is how long your data needs to stay secret.

That reframing is the whole argument. A session key protecting a video call needs to hold for an hour. A diplomatic cable, a medical record or a source's identity needs to hold for thirty years. If the gap between now and a working quantum computer is shorter than the second number, that traffic is already exposed — it simply has not been read yet.

What replaced what

In August 2024, NIST published three standards that ended a seven-year competition: ML-KEM for key establishment[1], and ML-DSA[2] and SLH-DSA[3] for signatures. The first two rest on lattice problems; the third on nothing more than a hash function, which makes it the conservative choice.

ML-KEM is not a drop-in for Diffie–Hellman, because it is not a Diffie–Hellman. It is a key encapsulation mechanism: one side publishes an encapsulation key, the other generates a secret, wraps it, and sends back a ciphertext. The shape is different, and protocols had to be adjusted for it.

ml_kem_768.py
from kyber_py.ml_kem import ML_KEM_768

# Alice publishes an encapsulation key and keeps the private half.
ek, dk = ML_KEM_768.keygen()
print(f"encapsulation key: {len(ek)} bytes")   # 1184

# Bob wraps a fresh secret against it. He needs nothing but ek.
shared_bob, ciphertext = ML_KEM_768.encaps(ek)
print(f"ciphertext:        {len(ciphertext)} bytes")   # 1088

# Alice unwraps the same secret. Neither value ever crossed the wire.
shared_alice = ML_KEM_768.decaps(dk, ciphertext)
assert shared_alice == shared_bob

# In production this is never used alone — the shared secret is mixed
# with a classical X25519 exchange, so the session survives a break
# in either construction. See "hybrid" below.

Note the last comment. Nobody is deploying ML-KEM on its own. The standard deployment is a Hybrid key exchange, where a classical and a post-quantum exchange both run and the session key is derived from both. The lattice schemes are young; a hybrid means a classical weakness discovered in five years does not retroactively open everything sent in the meantime.

The cost is bytes

The interesting thing about post-quantum cryptography in practice is that the expensive part is not the mathematics. Lattice arithmetic is fast — often faster than the elliptic-curve operations it replaces. What it costs is space, and the numbers are worth looking at directly.

Key and ciphertext sizes as published in FIPS 203, 204 and 205; classical values are the standard encodings. Switch to Signatures to see the harder half, or to Table for the underlying numbers.

For key exchange, the story is better than the proportions suggest. ML-KEM-768 is roughly 35× the bytes of X25519, which sounds alarming until you notice the absolute figure: about 2.2 KB, or two extra network packets, once per connection. Cloudflare and Google turned hybrid post-quantum key agreement on by default for a large share of real traffic and the measured latency cost was small enough to be uninteresting.

Signatures are where it hurts. A TLS handshake does not carry one signature; it carries a certificate chain, each link signed. Swapping Ed25519 for ML-DSA-44 multiplies across every link at once, and the conservative option — SLH-DSA, which assumes least about the underlying mathematics — pays for that caution with a signature of nearly eight kilobytes.

What to actually do

For most people the honest answer is nothing, yet — the migration is happening at the protocol layer, in software you update rather than code you write. If you do operate something with a long secrecy horizon, there are three questions worth asking now.

  • How long must this stay secret? Under five years, the urgency is low. Over twenty, you are already inside the window.
  • Do you have Forward secrecy? If a single long-term key compromise opens years of archived traffic, that is a larger and more immediate problem than quantum computing.
  • Can you enumerate your cryptography? Most organisations cannot say where RSA is used in their own systems. That inventory is the prerequisite for any migration, and it is the part that takes years.

The survey Bernstein and Lange wrote in 2017[5] is still the best short account of how the field got here — written when lattices were one live bet among several, which makes it a useful record of why they won.