Quality Outreach Heads-up - JDK 27: Post-Quantum Hybrid Key Exchange for TLS 1.3

The OpenJDK Quality Group is promoting the testing of FOSS projects with OpenJDK builds as a way to improve the overall quality of the release. This heads-up is part of a Quality Outreach update sent to the projects involved. To learn more about the program, and how-to join, please check here.

Configure Hybrid Key Exchange Support

JEP 527 has been integrated in JDK 27 early-access builds, bringing hybrid post-quantum key exchange to TLS 1.3. This improves Java’s TLS implementation by combining traditional elliptic-curve key algorithms with quantum-resistant ML-KEM, helping protect against future harvest-now, decrypt-later threats.

Java applications that use the standard javax.net.ssl APIs can benefit by default, without code changes, as long as they do not override the TLS named groups. By default, JDK 27 enables X25519MLKEM768 alongside existing classical key exchange algorithms, so TLS clients offer both a hybrid X25519MLKEM768 key share and a traditional x25519 key share.

JDK 27 adds three hybrid key exchange options through the SunJSSE provider:

  • X25519MLKEM768 is a hybrid scheme combining ECDHE with X25519 and ML-KEM-768.
  • SecP256r1MLKEM768 is a hybrid scheme combining ECDHE using the secp256r1 curve with ML-KEM-768.
  • SecP384r1MLKEM1024 is a hybrid scheme combining ECDHE using the secp384r1 curve with ML-KEM-1024.

You can customize the enabled groups either with the jdk.tls.namedGroups system property or programmatically via SSLParameters::setNamedGroups:

SSLSocket tlsSocket = (SSLSocket) SSLContext.getDefault()
        .getSocketFactory()
        .createSocket();

SSLParameters params = tlsSocket.getSSLParameters();

params.setNamedGroups(new String[] {
        "SecP384r1MLKEM1024",
        "X25519MLKEM768",
        "secp384r1",
        "x25519"
});

tlsSocket.setSSLParameters(params);

Call to Action

As this implementation is still new, we encourage you to download the JDK 27 early-access builds, try this feature, and share your feedback through the security-dev OpenJDK mailing list (registration required).

~