Hadamard Get the app

RFC 10024 Explained: X25519MLKEM768 Is Now a TLS 1.3 Standard

RFC 10024 Explained: X25519MLKEM768 Is Now a TLS 1.3 Standard — Hadamard

X25519MLKEM768 is a hybrid key exchange group for TLS 1.3. It combines the classical X25519 elliptic-curve exchange with ML-KEM-768, the post-quantum key encapsulation mechanism NIST standardized in 2024. Since August 2026 it has been an official IETF Proposed Standard, published as RFC 10024.

Major TLS stacks were shipping it before the RFC appeared. This article covers what the RFC defines, how many bytes the group adds to a handshake, why the ML-KEM part comes first, which software turns it on by default, and how to check whether your server negotiates it.

What RFC 10024 standardizes

RFC 10024 is titled “Post-Quantum Traditional (PQ/T) Hybrid Key Agreement Mechanisms for TLS 1.3”. It is a Standards Track document (Proposed Standard) from the IETF stream, approved by the IESG. Before publication it was the working group draft draft-ietf-tls-ecdhe-mlkem, and the last revision listed on the Datatracker is -05.

The authors are K. Kwiatkowski (PQShield), P. Kampanakis (AWS), B. E. Westerbaan (Cloudflare) and D. Stebila (University of Waterloo). The RFC defines three hybrid groups that pair ML-KEM with ECDHE. All three use the general framework set out in RFC 9954.

The standard arrived after much of the deployment had already happened. These are the dates in the record:

  • August 13, 2024: NIST publishes FIPS 203, the ML-KEM standard.
  • September 2024: Google announces that Chrome 131 will move to the ML-KEM codepoint 0x11EC.
  • April 8, 2025: OpenSSL 3.5.0 ships with X25519MLKEM768 in its default key shares.
  • July 2026: RFC 9954 publishes the general hybrid design for TLS 1.3, with Informational status.
  • August 2026: RFC 10024 standardizes the concrete groups.

Why hybrid? The idea behind RFC 9954

RFC 9954, “Hybrid Key Exchange in TLS 1.3”, was written by D. Stebila (Waterloo), S. Fluhrer (Cisco) and S. Gueron (University of Haifa and Meta). Its goal is a shared secret that “remains secure as long as one of the component key exchange mechanisms remains unbroken.”

The construction is simple. Component key shares are “directly concatenated, without any additional encoding or length fields.” On the secret side, “the two shared secrets are concatenated together” and take the place of the (EC)DHE secret in the normal TLS 1.3 key schedule.

Hybrid gets you two kinds of protection at once. X25519 is well studied, but a large enough quantum computer could break it. According to FIPS 203, “the security of ML-KEM is related to the computational difficulty of the Module Learning with Errors problem”. That problem is believed to resist quantum attacks, but ML-KEM has far less deployment history. A connection protected by both should stay secure even if one of them fails.

The main reason to deploy it now is “harvest now, decrypt later”: an attacker records encrypted traffic today and decrypts it once a quantum computer exists. JEP 527 names this threat directly. Cloudflare’s roadmap puts it this way: “HNDL attacks are the primary threat when Q-Day is far away.” For the regulatory timeline that pushes classical algorithms out, see our explainer on NIST IR 8547’s RSA and ECC deprecation deadlines.

Inside X25519MLKEM768: codepoint, key share sizes and shared secret

X25519MLKEM768 has the TLS named-group codepoint 4588 (0x11EC). The client sends an ML-KEM-768 encapsulation key plus an X25519 public key. The server replies with an ML-KEM-768 ciphertext plus its own X25519 public key.

Group Codepoint Client key share Server key share Shared secret
X25519MLKEM768 4588 (0x11EC) 1,216 bytes (1,184 + 32) 1,120 bytes (1,088 + 32) 64 bytes
SecP256r1MLKEM768 4587 (0x11EB) 1,249 bytes (65 + 1,184) 1,153 bytes (65 + 1,088) 64 bytes
SecP384r1MLKEM1024 4589 (0x11ED) 1,665 bytes (97 + 1,568) 1,665 bytes (97 + 1,568) 80 bytes

A plain X25519 exchange uses 32 bytes in each direction. Most of the extra cost comes from ML-KEM: 1,184 bytes for the ML-KEM-768 encapsulation key and 1,088 bytes for the ciphertext. In X25519MLKEM768 the two component secrets are 32 bytes each, so the combined secret is 64 bytes. That secret goes into the standard TLS 1.3 key schedule.

Checks the RFC makes mandatory

  • The server must run the FIPS 203 encapsulation key check and abort with illegal_parameter if it fails.
  • The client must check the ciphertext length and abort with illegal_parameter if it is wrong. Other decapsulation failures abort with internal_error.
  • Both sides must validate the ECDHE share and check for an all-zero X25519 shared secret.

Why ML-KEM comes first in X25519MLKEM768

The name lists X25519 first, but on the wire the ML-KEM value comes first, followed by the X25519 value. The shared secret uses the same order. RFC 10024 notes that this reverses RFC 9954’s naming convention “due to historical reasons.” In the two NIST-curve groups the ECDHE share comes first.

The order matters because of FIPS certification. Section 5 of the RFC explains that NIST SP 800-56Cr2 approves HKDF over two concatenated secrets if the first one comes from a FIPS-approved scheme. In practice that means:

  • SecP256r1MLKEM768 and SecP384r1MLKEM1024: the ECDHE secret is first, so only the ECDHE implementation needs certification.
  • X25519MLKEM768: the ML-KEM secret is first, so the ML-KEM implementation must be certified.

This matters to anyone building products for regulated buyers. Choosing a group also determines which cryptographic module has to go through validation.

The two other groups

SecP256r1MLKEM768 pairs the NIST P-256 curve with ML-KEM-768. SecP384r1MLKEM1024 pairs P-384 with ML-KEM-1024, the strongest of the three FIPS 203 parameter sets. FIPS 203 lists them as ML-KEM-512, ML-KEM-768 and ML-KEM-1024, in order of increasing security strength and decreasing performance. For the NIST curves, the ECDHE part of the shared secret is the x-coordinate of the shared point. That explains the 80-byte secret (48 + 32) for the P-384 group. Organizations working toward the NSA’s CNSA 2.0 requirements will find SecP384r1MLKEM1024 the most relevant of the three.

Who uses X25519MLKEM768 by default

Several of the most widely deployed TLS stacks were already set up to offer the group before it was standardized.

  • Chrome: In September 2024, Google said that Chrome 131, expected in early November 2024, would switch its hybrid codepoint from 0x6399 (Kyber768+X25519) to 0x11EC (ML-KEM768+X25519). Google explained that “the changes to the final version of ML-KEM make it incompatible with the previously deployed version of Kyber,” and the Chrome team stated: “Chrome will offer a key share prediction for hybrid ML-KEM (codepoint 0x11EC).”
  • OpenSSL 3.5: Released on April 8, 2025, it adds “Support for PQC algorithms (ML-KEM, ML-DSA and SLH-DSA)”. According to the release notes, the default TLS groups now include and prefer hybrid PQ KEM groups, and the default key shares were changed to “offer X25519MLKEM768” plus X25519.
  • JDK 27: JEP 527, “Post-Quantum Hybrid Key Exchange for TLS 1.3”, was delivered in JDK 27 and adds all three groups to javax.net.ssl. X25519MLKEM768 is enabled by default and first in the preference list. “The hybrid groups SecP256r1MLKEM768 and SecP384r1MLKEM1024 are not enabled by default.” You can change the defaults with the jdk.tls.namedGroups system property or SSLParameters::setNamedGroups. Pure (non-hybrid) ML-KEM is out of scope.
  • Cloudflare: In its April 2026 roadmap, Cloudflare reported that over 65% of human traffic to its network was post-quantum encrypted at that time.

We track the status of browsers, libraries and protocols in our Post-Quantum Migration Tracker.

What X25519MLKEM768 doesn’t fix

X25519MLKEM768 protects key exchange only. The server still proves its identity with a classical certificate and signature. A quantum computer could not use that to decrypt recorded traffic, but it could be used to impersonate a server in real time once such a machine exists. Cloudflare’s roadmap sums up the change in priorities: “An imminent Q-Day flips the script: data leaks are severe, but broken authentication is catastrophic.”

Cloudflare targets full post-quantum security, including authentication, by 2029. Its published milestones are:

  1. Mid-2026: ML-DSA authentication from Cloudflare to origin servers.
  2. Mid-2027: post-quantum authentication for visitor-to-Cloudflare connections, using Merkle Tree Certificates.
  3. Early 2028: the Cloudflare One SASE suite.
  4. 2029: full post-quantum security across the company.

Caveats from the RFC’s security considerations

  • Protocol-specific: “The security analysis relies crucially on the TLS 1.3 message transcript.” The RFC warns against assuming the same hybrid construction is secure in other protocols.
  • Side channels: “Implementers are encouraged to use implementations resistant to side-channel attacks.”
  • Randomness exposure: The client recovers the ML-KEM encapsulation randomness m, so anything m reveals about the random number generator’s other outputs is exposed to the peer. The RFC cites Dual EC as the cautionary example.
  • ECDH scalars: “The ECDH ephemeral scalars taken from the RNG are never directly disclosed to the peer,” but a quantum computer could recover them from observed public values.

The same split between key exchange and signatures exists outside TLS. Blockchains, for example, rely on ECDSA signatures to authorize transactions. At Hadamard we build BB84, an Ethereum Layer 2 that does not use ECDSA at all. Its accounts are one-time addresses based on hash commitments.

How to check whether your server negotiates X25519MLKEM768

The simplest test uses openssl s_client. Your local OpenSSL must be version 3.5 or later, because older versions cannot offer the group. If the client never offers it, the test tells you nothing about the server.

  1. Check your client version: openssl version
  2. Connect and filter the handshake output: openssl s_client -connect example.com:443 </dev/null 2>&1 | grep -i x25519
  3. Read the result.

This method comes from a GnuTLS bug report from March 2026, where the reporter ran the same command against a local server. If the hybrid group is negotiated, the output includes:

Negotiated TLS1.3 group: X25519MLKEM768

If the server falls back to classical key exchange, you will see something like:

Peer Temp Key: X25519, 253 bits

If you see the fallback line, check the TLS library your server uses and its configured groups. For Java services on JDK 27, check that jdk.tls.namedGroups has not been set in a way that removes the group.

FAQ

Is X25519MLKEM768 an official standard now, or still a draft?

It is an official standard. RFC 10024 was published in August 2026 as a Proposed Standard on the Standards Track, approved by the IESG. It replaces the working draft draft-ietf-tls-ecdhe-mlkem.

Does X25519MLKEM768 make my TLS certificates quantum-safe?

No. It only protects key exchange, which defends against harvest-now-decrypt-later attacks. Certificates and signatures are a separate migration. Cloudflare, for example, plans post-quantum authentication for visitor connections by mid-2027 and full post-quantum security by 2029.

How much bigger is the TLS handshake with X25519MLKEM768?

The client key share is 1,216 bytes and the server key share is 1,120 bytes. With X25519 alone, each is 32 bytes. Nearly all of the difference is the ML-KEM-768 encapsulation key (1,184 bytes) and ciphertext (1,088 bytes).

How do I check whether my server or site negotiates X25519MLKEM768?

Use OpenSSL 3.5 or later and run openssl s_client -connect yourhost:443, filtering the output for “x25519”. “Negotiated TLS1.3 group: X25519MLKEM768” means the hybrid group is in use. “Peer Temp Key: X25519, 253 bits” means the connection used classical X25519 only.

Sources