Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8358541

Post-Quantum Hybrid Key Exchange for TLS 1.3

XMLWordPrintable

    • Icon: JEP JEP
    • Resolution: Unresolved
    • Icon: P3 P3
    • None
    • security-libs
    • 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

      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 via SSLParameters.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.

            jnimeh Jamil Nimeh
            jnimeh Jamil Nimeh
            Jamil Nimeh Jamil Nimeh
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: