Why ML-KEM exists, how RSAs future is shaky, and why TLS is slowly mutating into something… hybrid

Harvest Now, Decrypt Later
5 mins

Imagineh2

You’re sending a random message to a friend, maybe a password reset link or a bank OTP or a dump of your production logs because you’re tired. The browser shows the usual lock icon. Everything looks normal. Your encrypted connection feels secure.

But here’s a thought that never gets advertised:

Even if someone can’t decrypt your traffic today, nothing stops them from collecting it and saving it for the day they can.

This isn’t a hypothetical. Hackers, state actors, and well funded groups are intercepting and storing massive volumes of encrypted traffic ; your VPN sessions, secure emails, and financial data.

Storage is cheap, patience is free.

That’s where the trouble starts. Because the encryption we use today mostly RSA, ECDSA, X25519 was designed around the assumption that factoring large numbers or solving discrete log problems is practically impossible.

“Practically impossible” changes meaning once quantum machines enter the story.

The motive is simple: the math behind today’s security (RSA and ECC) is toast once a large scale quantum computer exists. When that day comes, every byte of stored data will be instantly legible. If your data must remain confidential for the next decade, it is already compromised.

Harvest Now Decrypt Later Concept

RSA and “The Hard Problem”h2

RSA survives because of one mathematical assumption that has worked well for four decades:

Given N=p×qN = p \times q (product of two large primes), finding pp and qq is hard. Verifying them is easy.

That’s basically the famous problem structure: hard to solve, trivial to verify. - you can check a factorization instantly, but discovering one from scratch is computationally painful.

So RSA leans on this difficulty. Today, even a 2048-bit RSA modulus takes centuries of classical compute to break. The randomness of prime distribution, some clever padding, and careful math do the rest.

But this “hardness” relies on classical computation limits. Quantum machines flip the table.

Shor’s algorithm turns the “centuries of compute” into something that scales much more attractively. A big enough quantum computer reduces RSA to a physics problem, not a math one.

Nobody has a machine at that scale today. That’s fine. But remember the earlier point:

Your encrypted traffic is being collected today. Your RSA might be broken tomorrow.

That’s why the TLS community started taking post-quantum seriously.

ML-KEMh2

In 2022–2024, NIST ran its big tournament for post-quantum algorithms. Out of the chaos came something called Kyber, now renamed ML-KEM (Module Lattice Key Encapsulation Mechanism).

It’s a mouthful, but the idea is straightforward:

Instead of relying on prime factorization or discrete logs, ML-KEM uses lattice problems—geometric, noisy algebra structures where finding the solution is believed to be quantum-resistant.

The math is weird if you’re seeing it the first time, but the core claim is:

ML-KEM gives you fast key exchange that doesn’t collapse when a large quantum machine shows up. And TLS has already started using it.

Terminal window
openssl s_client -connect google.com:443 -tls1_3
Peer signing digest: SHA256
Peer signature type: ecdsa_secp256r1_sha256
Negotiated TLS1.3 group: X25519MLKEM768
---
SSL handshake has read 6437 bytes and written 1548 bytes
Verification: OK

Your browser and server just negotiated a hybrid key exchange:

  1. X25519 (elliptic curve)
  2. ML-KEM-768 (post-quantum lattice)

Combined. This is the transition era. Not fully PQ yet, but not classical only. Both keys are mixed so even if one breaks in the future, the other still protects the session key.

Security

Why Hybrid?h2

Because the ecosystem doesn’t trust itself yet.

New crypto is scary. Lattice algorithms are bigger, heavier, and sometimes awkward. Instead of switching fully, TLS 1.3 uses a belt-and-suspenders approach:

Classical + PQ → derive shared secret → continue handshake.

You’re basically running two independent key exchanges in parallel. If either survives in the future, your traffic stays safe. This is the first time in decades that the TLS world agreed to carry “extra weight” at the protocol level. And weight brings its own problems.

Packet Size Inflationh2

ML-KEM is good, but it isn’t free.

PQ key shares are huge compared to X25519. Instead of a few dozen bytes, you’re sending kilobytes.

  • X25519 public key: 32 bytes
  • ML-KEM-768: 1184 bytes
  • ML-KEM-1024: 1568 bytes

On real networks — especially mobile — this matters

More fragmentation on real networks If a single ML-KEM keyshare doesn’t fit inside the path MTU (common on mobile networks), fragmentation kicks in. A TLS handshake usually fits in a few packets. With ML-KEM-768 or 1024 in the mix, the keyshare becomes large enough that networks start breaking it into fragments.

  • Path MTU is ~1200 bytes.
  • Your keyshare is ~1400 bytes.
  • Result: two fragments.

Lose one fragment and the handshake fails.

PQ crypto isn’t just a “math update.” It’s a networking update. TLS is effectively being forced to handle larger handshake payloads, and networks that were tuned for small, predictable packets now have to deal with these sudden multi-kilobyte structures. Years of optimisation around small classical keyshares don’t fully apply anymore.

Packet Fragmentation Issue

Are We Safe Now?h2

Not exactly. This is a long transition period.

The “hybrid X25519 + ML-KEM768” line in your TLS debug output is basically the security industry saying:

“We’re not ready to fully trust PQ crypto, but we’re even less ready to trust RSA in the long-term.”

TLDRh2

The idea that “your encrypted traffic today might be decrypted tomorrow” isn’t paranoia anymore. It’s engineering reality.

RSA rests on a problem that sits in the NP bucket: easy to verify, hard to solve, until quantum changes the definition of “hard”. ML-KEM is part of the fix. Not perfect, not painless, but necessary.

And the moment you see something like:

Terminal window
Negotiated TLS1.3 group: X25519MLKEM768

in your handshake logs, it means your system has joined the migration whether you asked for it or not.

The cost is higher handshake sizes, more packet fragmentation, and a bit of temporary chaos. But the alternative is handing your future data to anyone patient enough to store your packets today.

Comments