Summary

Implement TLS 1.3 hybrid key exchange support for three hybrid named groups (i.e. key exchange schemes): X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024 as defined in:

• Hybrid key exchange in TLS 1.3
• Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3

These three hybrid named groups combine traditional key exchange schemes such as x25519, secp256r1 and secp384r1 with the post-quantum cryptographic algorithm ML-KEM to form new TLS 1.3 named groups. Applications using javax.net.ssl benefit from these improved algorithms by default without code changes.

Problem

Adversaries can record TLS traffic today and decrypt it later (the "harvest now, decrypt later" threat) when quantum-capable computers become available. Hybrid key exchanges reduce that risk by combining a classical algorithm with a quantum-resistant algorithm.

Solution

During the TLS 1.3 handshake, the client advertises its supported key exchange schemes in the ClientHello message. The order of these key exchange schemes (referred to as named groups in the TLS specifications) is determined by either:

• The default list of supported groups, or
• A custom list specified by the application through the system property jdk.tls.namedGroups or the SSLParameters.setNamedGroups() method. These mechanisms override the default list.

With the introduction of hybrid key exchange, three hybrid schemes will be implemented and one will be added to the top of the default list. The new default list is:

• X25519MLKEM768, x25519, secp256r1, secp384r1, secp521r1, x448, ffdhe2048, ffdhe3072, ffdhe4096, ffdhe6144, and ffdhe8192.

The other two hybrid schemes will be available for users to enable via the aforementioned methods above. The decision to begin with only X25519MLKEM768 in the default set of named groups is based on the conventions adopted by most browsers and libraries that have already delivered support for hybrid schemes.

Specification

First, in src/java.base/share/classes/java/security/spec/NamedParameterSpec.java, add the following lines:

/**
 * The X25519MLKEM768 parameters
 *
 * @since 26
 */
public static final NamedParameterSpec X25519MLKEM768
        = new NamedParameterSpec("X25519MLKEM768");

/**
 * The SecP256r1MLKEM768 parameters
 *
 * @since 26
 */
public static final NamedParameterSpec SecP256r1MLKEM768
        = new NamedParameterSpec("SecP256r1MLKEM768");

/**
 * The SecP384r1MLKEM1024 parameters
 *
 * @since 26
 */
public static final NamedParameterSpec SecP384r1MLKEM1024
        = new NamedParameterSpec("SecP384r1MLKEM1024");

Second, in the Java Security Standard Algorithm Names document:

1. Add the following lines to the NamedParameterSpec section:

   ---

   Name Description

   ---

   SecP256r1MLKEM768 Combining secp256r1 ECDH with ML-KEM-768 Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3 SecP384r1MLKEM1024 Combining secp384r1 ECDH with ML-KEM-1024 Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3 X25519MLKEM768 Combining X25519 ECDH with ML-KEM-768 Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3

2. Add the following lines to the Named Groups section:

   ---

   Name

   ---

   X25519MLKEM768 \ The Post-quantum hybrid ECDHE-MLKEM groups SecP256r1MLKEM768 \ specified in draft-ietf-tls-ecdhe-mlkem. SecP384r1MLKEM1024 \