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

Implement JEP 527: TLS 1.3 Hybrid Key Exchange

XMLWordPrintable

    • Icon: CSR CSR
    • Resolution: Unresolved
    • Icon: P2 P2
    • tbd
    • security-libs
    • 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 API SSLParameters.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, and ffdhe8192.

      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 \

            hchao Haimay Chao
            jnimeh Jamil Nimeh
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Created:
              Updated: