-
CSR
-
Resolution: Unresolved
-
P2
-
None
-
source
-
minimal
-
Java API, System or security property
-
SE
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:
The implementation uses a concatenation-based approach and integrates the hybrid ML-KEMs into JSSE as single negotiable TLS 1.3 named groups. Applications using javax.net.ssl
benefit from these improved algorithms by default without code change.
Problem
Adversaries can record TLS traffic today and decrypt it later("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 (named groups) 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 APISSLParameters.setNamedGroups()
. These mechanisms override the default list.
With the introduction of hybrid key exchange, three hybrid schemes are added to the top of the default list. The new default list is:
X25519MLKEM768
,SecP256r1MLKEM768
,SecP384r1MLKEM1024
,x25519
,secp256r1
,secp384r1
,secp521r1
,x448
,ffdhe2048
,ffdhe3072
,ffdhe4096
,ffdhe6144
, andffdhe8192
.
The implementation follows the concatenation-based hybrid approach, which combines a post-quantum ML-KEM with a classical elliptic curve Diffie-Hellman (ECDHE). The resulting hybrid key exchange is treated as a single named group within TLS 1.3 and is transmitted through the existing key share extension format.
Hybrid Key Share Processing
When both client and server support a hybrid algorithm, the key exchange proceeds as follows:
1) Client (KEM Receiver):
Generates a hybrid key pair.
Sends its public key share in the ClientHello
message.
2) Server (KEM Sender):
Performs encapsulation using the client's public key and its own private key.
Produces a ciphertext (encapsulation message) and a shared secret.
Sends the ciphertext back to the client in the ServerHello
message.
3) Client (KEM Receiver):
Performs decapsulation using its private key and the received ciphertext. Derives the same shared secret as the server.
This shared secret is then used in the TLS 1.3 key schedule for subsequent HKDF-based secret derivation.
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](https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem).
SecP384r1MLKEM1024 \
- csr of
-
JDK-8314323 Implement JEP 527: TLS 1.3 Hybrid Key Exchange
-
- In Progress
-