Abstract
Transport Layer Security (TLS) version 1.3 keeps our Internet communications confidential and authentic through elliptic-curve Diffie–Hellman key exchange and digital signatures. But here's the problem: both these operations rely on mathematical puzzles—integer factorisation and discrete logarithms—that quantum algorithms can crack. This creates a ticking time bomb scenario where adversaries can record encrypted traffic today and decrypt it later when cryptographically relevant quantum computers become reality. In this article, we'll explore the nature of this threat, understand how the newly standardised hybrid ML-KEM-768 + X25519 key exchange provides protection, and explain why traditional RSA signatures still work perfectly fine for authenticating TLS 1.3 sessions.
Key Points at a Glance
- Classical cryptography won't survive quantum computing: RSA and elliptic-curve Diffie–Hellman depend on problems that become trivial once we can run Shor's algorithm on sufficiently powerful quantum computers.
- The "harvest now, decrypt later" (HNDL) threat is real: Sophisticated attackers are likely already storing encrypted data, waiting for the day quantum technology catches up. Any data that needs to stay secret beyond the 2030s is potentially at risk.
- Hybrid key exchange offers the best of both worlds: By combining ML-KEM-768 with X25519, we get a system that stays secure as long as either algorithm holds up. It's like having two locks on your door—an attacker needs to break both to get in, as detailed in the IETF draft specification.
- RSA signatures are still fine (for now): Since TLS only uses signatures for authentication during the handshake—not for encrypting data—breaking a captured signature years later won't reveal past session keys. This means RSA and ECDSA certificates remain practical until quantum computers can attack them in real-time.
The Classical Roots of TLS 1.3
Let's start with how TLS 1.3 works today. When your browser connects to a secure website, it performs an elliptic-curve Diffie–Hellman exchange with the server to create a shared secret. Both parties then authenticate this exchange using X.509 certificates, as specified in RFC 8446. The beauty of the Diffie–Hellman operation (often using the X25519 curve) is that it provides forward secrecy—even if someone steals the server's private key tomorrow, they can't decrypt today's conversations. Meanwhile, authentication happens through digital signatures—typically RSA or ECDSA—embedded in the server's certificate, which lets your browser verify it's really talking to the genuine server.
The security of both these mechanisms hinges on mathematical problems we believe are hard to solve. Diffie–Hellman relies on the discrete logarithm problem, while RSA depends on the difficulty of factoring large numbers. Unfortunately, a sufficiently powerful quantum computer running Shor's algorithm will slice through these problems like butter, as NIST's quantum threat assessment makes clear. While such machines don't exist yet, nation-states and sophisticated adversaries aren't waiting—they're capturing encrypted data now, betting they'll be able to decrypt it when "Q-Day" arrives.
Quantum Threats and the Harvest-Now-Decrypt-Later Problem
The HNDL threat sounds like something from a spy thriller, but it's a genuine concern that keeps security professionals up at night. Here's how it works: even though today's quantum computers can't break modern encryption, adversaries can intercept and store encrypted communications or steal entire databases. They're essentially creating a vault of encrypted secrets, waiting for the day when quantum computers become powerful enough to crack them open.
Industry experts warn that once we have quantum computers capable of running Shor's algorithm at scale, attackers will be able to extract private keys from recorded TLS handshakes and decrypt years of archived data, as outlined in this IETF draft on PQC applications.
This threat is particularly worrying for information that needs long-term protection—think financial records that must be kept for decades, trade secrets, medical histories, or classified government documents. If you're protecting data that needs to remain confidential for the next 10-20 years, you need to act now, not when quantum computers arrive.
| Algorithm | Type | Key Size | Classical Security | Quantum Security | Status |
|---|---|---|---|---|---|
| RSA-2048 | Signature/KEM | 256 bytes | ✅ Strong | ❌ Broken by Shor's | Current Standard |
| X25519 | Key Exchange | 32 bytes | ✅ Strong | ❌ Broken by Shor's | Current Standard |
| ML-KEM-768 | KEM | 1,184 bytes | ✅ Strong | ✅ Resistant | NIST FIPS 203 |
| X25519 + ML-KEM-768 | Hybrid KEM | 1,216 bytes | ✅ Strong | ✅ Resistant | Recommended |
| ML-DSA-65 | Signature | 1,952 bytes | ✅ Strong | ✅ Resistant | NIST FIPS 204 |
This urgency explains why the cryptographic community has prioritised quantum-safe key exchange over quantum-safe signatures. The key exchange must protect data long after the connection ends, while signatures only need to work at the moment of verification. If someone breaks a signature ten years from now, it doesn't compromise the confidentiality of data exchanged using a secure key exchange method.
Hybrid Key Exchange with ML-KEM-768 and X25519
Enter post-quantum cryptography (PQC)—a new generation of algorithms designed to withstand attacks from both classical and quantum computers. Among the most promising is ML-KEM (formerly known as Kyber), a lattice-based Key Encapsulation Mechanism that NIST standardised in FIPS 203. Rather than throwing out everything we know and trust, the IETF has wisely proposed a hybrid approach that combines traditional algorithms with PQC methods.
The X25519MLKEM768 group exemplifies this belt-and-suspenders approach. It combines an X25519 public key with an ML-KEM-768 public key, as detailed in the IETF specification. During the handshake, both client and server perform two operations: a traditional elliptic-curve Diffie–Hellman exchange and an ML-KEM encapsulation. They then combine these two secrets (usually with a cryptographic hash) to create the session key. The genius of this approach? If quantum computers eventually break X25519, ML-KEM still protects your data. And if researchers discover a weakness in ML-KEM, X25519 has your back. As security experts point out, you'd need to break both algorithms to compromise the session.
Of course, there's no free lunch in cryptography. Implementing hybrid KEMs comes with practical challenges. According to NIST's FIPS 203, an ML-KEM-768 public key weighs in at 1,184 bytes. Combine that with X25519's modest 32 bytes, and you're looking at roughly 1,216 bytes in the ClientHello message (see our demo page for more details).
This increase can cause headaches—Akamai's research shows it may trigger packet fragmentation or confuse older network equipment that expects smaller handshakes. Despite these growing pains, the industry is moving fast: major cloud providers, CDNs, and TLS libraries are already rolling out support for hybrid groups.
Digital Signatures and Why RSA Remains Adequate
While key exchange protects confidentiality, digital signatures handle authentication in TLS. Here's how it works: the server proves its identity by signing the handshake transcript, and the client verifies this signature using the public key from the server's certificate. Crucially, this all happens during the initial handshake, before any sensitive data changes hands.
This timing matters because, as Cloudflare's analysis shows, even if an attacker factors your RSA key years later, they can't retroactively compromise sessions that used secure key exchange.
This is why post-quantum signatures aren't urgently needed to address the harvest-now-decrypt-later threat. An RSA-2048 or ECDSA-P256 certificate with a reasonable validity period (say, one year) provides plenty of security for today's needs. That said, we can't ignore certificates issued by root Certificate Authorities, which often remain valid for twenty years or more, as noted in this IETF draft. These long-lived certificates present a different challenge: if quantum computers arrive during their validity period, attackers could impersonate the CA and issue fake certificates.
The industry is already exploring post-quantum signature schemes like ML-DSA (Dilithium) and SLH-DSA (SPHINCS+) for these high-stakes scenarios. However, these new schemes come with trade-offs—they produce much larger keys and signatures, and currently impose significant performance penalties. We'll likely see gradual adoption as implementations improve and hardware catches up.
For now, the smart approach is to keep certificate lifetimes short, stay informed about PQC signature developments, and ensure your infrastructure can adapt when new algorithms become practical. By combining hybrid key exchange for long-term confidentiality with traditional signatures for current authentication needs, we get robust protection against quantum threats without sacrificing the performance and compatibility we need today.
📋 Quick Implementation Checklist
- ✅ Enable hybrid key exchange groups (X25519MLKEM768) in your TLS configuration
- ✅ Test for packet fragmentation and middlebox compatibility issues
- ✅ Keep certificate validity periods short (≤1 year for end-entity certificates)
- ✅ Monitor NIST and IETF standardisation progress for PQC signatures
- ✅ Inventory systems storing long-term sensitive data for priority migration
- ✅ Plan infrastructure updates to handle larger handshake messages