Skip to main content

JEP 527: Post-Quantum Hybrid Key Exchange for TLS 1.3

Introduction​

Cryptographic security has never been a static promise; it is an ongoing race against computing power. Encryption that is unbreakable today may become fragile after some technological inflection point. Quantum computing is exactly such an inflection point. JEP 527 prepares Java's TLS implementation for that race ahead of time, and it does so in a remarkably pragmatic way: enabled by default, with no application code changes.

The threat model: harvest now, decrypt later​

To understand this JEP, you first have to understand the threat it defends against.

Today's TLS key exchange rests on elliptic-curve Diffie-Hellman (ECDH). That mathematical foundation is secure enough against current classical computers; even the most powerful supercomputer cannot break it in any reasonable amount of time.

Quantum computers are different. A sufficiently capable quantum computer, using Shor's algorithm, could efficiently break the mathematical hard problems that elliptic-curve cryptography depends on. No such machine exists yet, but that does not make the threat distant. The reason is an attack pattern known as "harvest now, decrypt later":

  • An adversary records and stores your encrypted traffic today, exactly as it is.
  • They are in no hurry to break it now; they simply wait patiently.
  • Once a sufficiently capable quantum computer arrives, they take out the traffic they stored years ago and decrypt it in bulk.

In other words, traffic captured today can be decrypted in the future. If your data needs to remain confidential for ten or twenty years, think medical records, state secrets, long-lived commercial contracts, then the threat is already real now, even though quantum computers have not arrived. You have to protect that long-lived data before the threat actually materializes.

What JEP 527 adds​

JEP 527 adds hybrid key exchange to the JDK's TLS 1.3 implementation:

  • It adds new hybrid key exchange named groups for TLS 1.3.
  • Specifically, it combines ML-KEM (the NIST-standardized, Kyber-based post-quantum key encapsulation mechanism) with traditional X25519 or ECDH.
  • The crucial point: it is enabled by default in the JDK's TLS implementation.
  • Of the three hybrid groups, X25519MLKEM768 is enabled by default; SecP256r1MLKEM768 and SecP384r1MLKEM1024 can be enabled through TLS configuration.
  • It builds on the foundational ML-KEM support already added in several earlier JDK releases, one step in a gradually advancing roadmap.

What does enabled by default mean? It means that once you upgrade to Java 27, as long as the peer also supports it, your TLS connections automatically negotiate post-quantum protection. You do not have to write any code, and you do not even have to know it exists.

Why hybrid, not post-quantum alone​

A natural question: if we already have post-quantum algorithms, why not simply switch entirely to them, instead of mixing them with traditional algorithms?

The answer comes down to trust and maturity:

  • Post-quantum algorithms are still young. Although ML-KEM has been through the NIST standardization process, it has undergone far less real-world attack scrutiny than elliptic-curve cryptography, which has been in use for decades. If a classical (non-quantum) attack against it were discovered in the future, relying on it alone would be risky.
  • A hybrid approach puts two locks on the same key. The shared secret is derived from both algorithms at once, the traditional one and the post-quantum one. An attacker must break both to recover the key.
  • Security holds as long as either algorithm remains unbroken. This is a belt-and-suspenders insurance: the traditional algorithm guards against known attacks today, the post-quantum one guards against future quantum attacks. If either falls, the other still holds the line.
  • The hybrid design preserves security if either component remains secure.

Impact: what you get and what to watch​

What you get:

  • Protection against harvest-now, decrypt-later attacks. This is the core value.
  • Negotiated automatically when the peer supports it. The TLS handshake upgrades itself, no manual intervention needed.
  • No application code changes for standard TLS clients and servers. The upgrade happens at the handshake layer and is completely transparent to the application.

What to watch:

  • Handshake messages get larger. Post-quantum keys are inherently much bigger than traditional ones, which makes ClientHello messages and key shares noticeably larger.
  • Some middleboxes dislike oversized handshakes. Older firewalls, load balancers, or deep-packet-inspection devices may mishandle, or even drop, handshakes larger than they expect.
  • You can constrain which named groups are offered using the usual TLS properties. If your network path genuinely has such problems, standard TLS configuration lets you restrict or adjust the negotiated named groups without touching application logic.

Conclusion​

Java 27 gives your TLS connections post-quantum protection by default. Harvest-now, decrypt-later is not a hypothetical threat in some distant future but a practical risk that deserves serious attention right now, especially for data that must stay confidential for the long term. And all it takes to respond to it is upgrading the JDK. The security improvement is hidden inside an ordinary version bump.