-
JEP
-
Resolution: Unresolved
-
P3
-
None
-
None
-
Feature
-
Open
-
JDK
Summary
Enhance the JDK's implementation of Transport Layer Security (TLS) 1.3 to support Hybrid Key Exchange and implement three schemes that each use quantum-resistant Module-Lattice-Based Key Encapsulation Mechanism (ML-KEM) algorithm as one component. Hybrid key exchange combines multiple algorithms to establish a shared secret and is secure as long as one of the algorithms remains unbroken.
Non-Goals
- It is not a goal to provide a hybrid KEM implementation for use outside TLS 1.3.
- It is not a goal to add support for non-hybrid key exchange schemes that use ML-KEM. We may, however, do that in follow-on work.
Motivation
Establishing a secure connection with TLS involves a handshake, which is performed as part of the process of connecting an SSLSocket
or SSLServerSocket
to its TLS peer. The key exchange step in a TLS handshake establishes a shared secret key from which encryption keys are derived. The key exchange step is based on traditional public key algorithms such as Diffie-Hellman which are vulnerable to attacks mounted by a future, large-scale quantum computer. In particular, TLS sessions today can be recorded and then fed to a quantum computer for decryption at a later date (sometimes referred to as "harvest now, decrypt later").
The Internet Engineering Task Force (IETF) TLS Working Group is addressing this threat by defining hybrid key exchange schemes for TLS 1.3. These schemes combine traditional key exchange algorithms with quantum-resistant ones. This approach provides the benefit of quantum-resistant security while acknowledging that these newer algorithms have not had years of analysis performed on them like traditional algorithms have. Three hybrid key exchange schemes have been defined that combine ML-KEM with traditional elliptic curve Diffie-Hellman. The Java Platform already contains the building blocks for implementing hybrid key exchange schemes with the addition of the KEM API in JDK 21 and the ML-KEM algorithm in JDK 24. Implementing these hybrid key exchange schemes is a necessary next-step in the Java Platform's support of post-quantum cryptography.
Description
We will enhance the TLS 1.3 implementation to support three new hybrid key exchange schemes that combine ML-KEM with the traditional Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) algorithm:
- X25519MLKEM768: Hybrid scheme combining ML-KEM-768 with X25519
- SecP256r1MLKEM768: Hybrid scheme combining ECDHE using the secp256r1 curve with ML-KEM-768
- SecP384r1MLKEM1024: Hybrid scheme combining ECDHE using the secp384r1 curve with ML-KEM-1024
These names will be added to the "Named Groups" section of the Java Security Standard Algorithm Names specification. These new named group String names are consistent with those specified on the IANA TLS Parameters site. No other API changes are proposed as part of this feature.
These hybrid schemes for both client and servers concatenate an ephemeral ECDH public key with the encapsulation key from ML-KEM. Once the key exchange has occurred from both TLS endpoints, the shared secrets for both ECDHE and ML-KEM are derived independently and then concatenated to form the final shared secret value used as input in the TLS 1.3 key scheduler.
Using Hybrid Named Groups
TLS clients communicate the named groups which they support, ordered by preference, in the Supported Groups extension of the ClientHello message. The default set of named groups currently sent by the Java TLS 1.3 client are the following: x25519, secp256r1, secp384r1, secp521r1, x448, ffdhe2048, ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192
.
The hybrid named groups will be added to this list. The preference order has not yet been decided. The default list of named groups can be changed by setting the jdk.tls.namedGroups
system property or by calling the SSLParameters.setNamedGroups
method.
In the following example, the default named group ordering is changed so the client will enable two hybrid and two traditional key exchange schemes:
SSLSocket tlsSock = (SSLSocket)(SSLContext.getDefault().
getSocketFactory().createSocket());
SSLParameters params = tlsSock.getSSLParameters();
// Configure the socket to use two hybrid KEM schemes and
// two traditional ones
params.setNamedGroups(new String[] { "SecP256r1MLKEM768",
"X25519MLKEM768", "secp256r1", "x25519" });
tlsSock.setSSLParameters(params);
Alternatives
We will not deliver pure ML-KEM based key exchange support as part of this JEP. These key exchange schemes are another way to introduce quantum-resistant schemes into the TLS protocol. Hybrid KEMs are in higher demand and give a minimal guarantee of security against both traditional and post-quantum attacks that neither class of algorithm has on its own. We may support these schemes in follow-on work.
Testing
- Unit tests will confirm the proper operation between client and server using the new hybrid key exchange schemes, and also the proper operation when these new named groups are asserted via the
jdk.tls.namedGroups
System property or viaSSLParameters.setNamedGroups()
. - Interoperability testing will be performed against other TLS implementations that support Hybrid and/or ML-KEM based supported groups.
Risks and Assumptions
The Hybrid key exchange in TLS 1.3 and ECDHE/MLKEM Hybrid Internet drafts have not yet reached standardization (promoted to RFCs). Ideally the standards should be finalized before we deliver this feature.
- is blocked by
-
JDK-8314323 TLS 1.3 Hybrid Key Exchange
-
- In Progress
-
-
JDK-8353682 Refactor TLS to use KEM for key exchange
-
- Closed
-