Java 27 Adds Hybrid Post-Quantum Key Exchange to TLS 1.3
Oracle released Java 27 on September 15, 2026, which incorporated hybrid post-quantum key exchange for TLS 1.3. This feature, labeled JEP 527 in the OpenJDK release notes, combines a quantum-resistant algorithm with a classical one during the TLS handshake. Clients offer this mechanism by default without requiring code changes. It serves as a migration strategy for one aspect of the protocol.
Key Additions in Java 27
Specifically, JEP 527 implements hybrid key exchange for TLS 1.3, as described in RFC 9954. This construction pairs a traditional scheme with a quantum-resistant one, ensuring session protection if either algorithm remains secure. According to Oracle’s JDK 27 release notes, applications utilizing the javax.net.ssl APIs automatically benefit from these improved algorithms, without requiring modifications to existing code.
The named group used is X25519MLKEM768, which combines the classical X25519 curve with ML-KEM-768. ML-KEM is the key-encapsulation mechanism standardized by NIST as FIPS 203. As noted in the OpenJDK Quality Group’s May 2026 heads-up, JDK 27 clients transmit a hybrid share alongside a classical X25519 share during the handshake. Named groups can be configured via the jdk.tls.namedGroups system property or SSLParameters::setNamedGroups.
Oracle also released Jipher 20, which supports ML-KEM and ML-DSA for FIPS 140-3 environments, as detailed in the Oracle Java 27 announcement.
Considerations for Users
The default behavior applies to clients. Server-side handling of the hybrid group is not explicitly detailed in the available documentation. For negotiation, both endpoints must have compatible support. If a server does not recognize the hybrid group, the handshake will revert to a classical-only key exchange, offering no post-quantum protection.
Oracle and OpenJDK have not published data on handshake size, CPU cost, latency, or memory impact for the hybrid group. Developers should conduct their own measurements in test environments rather than assuming parity with the classical baseline.
Furthermore, there are no published interoperability results with non-Java servers, older JDK versions, or cloud endpoints. This information pertains specifically to Oracle and OpenJDK builds, not third-party distributions like Temurin or Corretto.
Though JDK 27 is a feature release with confirmed general availability according to Oracle’s blog, enterprises should independently verify long-term support timelines.
A Migration Tool, Not a Complete Defense
JEP 527’s stated non-goals exclude other APIs and TLS versions, meaning it exclusively addresses key exchange. Certificates, digital signatures, stored data, and non-TLS systems require separate efforts, and the JDK currently lacks a documented timeline for post-quantum certificates or signatures.
This feature protects against “harvest now, decrypt later” interception of session keys, but only when the hybrid group is successfully negotiated.
This implementation utilizes standardized post-quantum cryptography based on NIST’s FIPS 203, which distinguishes it from QKD or proprietary “unbreakable” claims. Currently, no cryptographically relevant quantum computer exists that can break classical schemes.
No independent cryptographic assessment is provided in the available evidence, thus the standards documents serve as the primary reference. Developers should confirm interoperability, fallback logging, and handshake behavior prior to deployment.