X25519MLKEM768 vs SecP256r1MLKEM768: which should you use?

X25519MLKEM768 and SecP256r1MLKEM768 are two hybrid post-quantum key agreement groups for TLS 1.3. Each one combines ML-KEM-768 from FIPS 203 with an elliptic-curve Diffie-Hellman exchange. Their post-quantum strength is identical. What differs is the classical curve, the order in which the two secrets are joined, which half needs a FIPS-validated implementation, and the status IANA gives each group.

The two groups, and a third one, SecP384r1MLKEM1024, are now standardised. The IETF document draft-ietf-tls-ecdhe-mlkem was ultimately published as RFC 10024, dated August 2026. For operators of OT and critical infrastructure, the choice comes up wherever TLS-based or similar key exchange protects links between control centres and substations, data flows to cloud historians, and remote engineering access. The sections below explain which group fits which constraint.

What is the difference between X25519MLKEM768 and SecP256r1MLKEM768?

Both groups pair ML-KEM-768 with an ephemeral ECDH exchange. X25519MLKEM768 uses Curve25519 and puts the ML-KEM secret first. SecP256r1MLKEM768 uses NIST P-256 and puts the ECDH secret first.

RFC 10024 explains each group’s purpose. The X25519 group is widely deployed, and often serves as the most practical choice for a single PQ/T hybrid combiner. The P-256 group was originally added to support a use case that requires both shared secrets to be generated by FIPS-approved mechanisms.

The size figures come from the specifications. RFC 10024 gives the X25519 client share as 1216 bytes (1184 bytes for the ML-KEM part and 32 bytes for X25519) and the P-256 share as 1249 bytes (65 bytes for the secp256r1 part and 1184 bytes for ML-KEM). In practice the 33-byte gap is too small to matter. Both shares are dominated by the ML-KEM encapsulation key.

Why the byte order is reversed

The name X25519MLKEM768 is slightly misleading. The RFC notes that the order of shares in the concatenation has been reversed. This is due to historical reasons. In practice, for X25519MLKEM768, the shared secret is the concatenation of the ML-KEM shared secret and the X25519 shared secret. If you are building or testing an implementation, this is the most common source of interoperability failures. Do not assume that the order of names matches the order on the wire.

Which hybrid ML-KEM group should be used for FIPS compliance?

All three groups can be run in a FIPS-approved way. What changes is which half has to come from a validated module: ML-KEM for X25519MLKEM768, and ECDH for the two NIST-curve groups.

The rule comes from NIST’s key-derivation guidance. According to RFC 10024, NIST Special Publication 800-56Cr2 approves the usage of the HMAC-based Key Derivation Function (HKDF) with two distinct shared secrets, with the condition that the first one is computed by a FIPS-approved key-establishment scheme. P-256 and P-384 ECDH are approved under NIST SP 800-56A. X25519 is not. Kris Kwiatkowski, a co-author of the draft, put the reasoning plainly on the IETF TLS list: “X25519 is not FIPS-approved hence MLKEM goes first.”

The result: for SecP256r1MLKEM768 and SecP384r1MLKEM1024, the ECDHE implementation must be certified, whereas the ML-KEM implementation does not require certification. In contrast, for X25519MLKEM768, the ML-KEM implementation must be certified.

NIST does not plan to change this soon. In its 2025 proposal on the SP 800-56 series, the NIST Crypto Publication Review Board wrote that “NIST does not propose to approve the X25519 and X448 key exchange schemes.” Its reason was that it regards new schemes as secondary in the ongoing transition to post-quantum cryptography.

Does the choice of classical curve in a hybrid key exchange affect quantum security?

No. A cryptographically relevant quantum computer would break X25519, P-256 and P-384 alike, so a hybrid group’s quantum resistance depends only on its ML-KEM parameter set.

FIPS 203 sets out the tiers: ML-KEM-512 (security category 1), ML-KEM-768 (security category 3), ML-KEM-1024 (security category 5). X25519MLKEM768 and SecP256r1MLKEM768 both sit at category 3. SecP384r1MLKEM1024 has a higher quantum margin because of ML-KEM-1024, not because of P-384.

The classical curve still matters for three reasons:

• Protection if ML-KEM fails. During the IETF debate, participants argued that if an implementation or design flaw is found in one of the algorithms but not the other the hybrid group remains secure. In that case the curve sets how strong the fallback is against classical attackers.
• Certification path. As described above, the curve determines which half must come from a validated module.
• Implementation risk. X25519 was designed to make constant-time implementation straightforward. NIST curves depend more on careful point validation. RFC 10024 requires both peers to perform the all-zero shared secret check for X25519 and to abort on failure.

When should SecP384r1MLKEM1024 be used instead of X25519MLKEM768?

Use SecP384r1MLKEM1024 when a policy explicitly calls for ML-KEM-1024 or category 5 strength, or for FIPS-approved mechanisms with a larger margin. Otherwise X25519MLKEM768 is the general-purpose default.

The IETF draft describes the P-384 group as intended for high-security environments that require FIPS-approved mechanisms with an increased security margin. The usual driver is CNSA 2.0. The NSA’s draft profiles state that ML-DSA-87 and ML-KEM-1024 together with SHA-384, SHA-512, AES-256, LMS, and XMSS comprise the CNSA Suite 2.0.

Be careful about treating SecP384r1MLKEM1024 as equivalent to CNSA 2.0. The draft TLS profile states that any algorithm other than ML-KEM-1024 offered by the client MUST NOT be accepted by a CNSA TLS server establishing a CNSA-compliant connection. That means standalone ML-KEM-1024 rather than a hybrid. The draft IPsec profile, by contrast, does combine a classical exchange with an additional key exchange performed in IKE_INTERMEDIATE that must be ML-KEM-1024. Check the profile for your protocol before you commit to a group.

There is a cost. The ML-KEM-1024 encapsulation key is 1568 bytes, against 1184 bytes for ML-KEM-768 (FIPS 203). On OT links with small MTUs, cellular backhaul or legacy middleboxes, that difference can matter. The CNSA IPsec draft notes that ML-KEM-1024 in the first exchange would exceed the typical path MTU and necessitate in IP-level fragmentation, which can cause operational challenges and prevent the establishment of a connection.

Which hybrid ML-KEM groups do the IETF and IANA mark as recommended?

Only X25519MLKEM768 is marked Recommended “Y” in the IANA TLS Supported Groups registry. SecP256r1MLKEM768 and SecP384r1MLKEM1024 are marked “N”.

The registry entry created by RFC 10024 reads X25519MLKEM768 Value: 4588 (0x11EC) Description: X25519MLKEM768 DTLS-OK: Y Recommended: Y. The P-256 group is listed with Value: 4587 (0x11EB) Description: SecP256r1MLKEM768 DTLS-OK: Y Recommended: N.

The “Y” came out of a working-group decision. The TLS chairs held a consensus call to move X25519MLKEM768 to “Y”, which the document shepherd explained means “the group is recommended by the IETF for general use.” An “N” is not a warning. For the pure ML-KEM groups, the shepherd explains that it means there was no consensus to recommend this group and the IETF does not take a specific position on its suitability in general or for a particular purpose.

Real-world deployment follows the same pattern. A 2026 measurement of UK internet sectors found:

• X25519MLKEM768: 1,787 HTTPS endpoints supporting this configuration, out of 4,063 reachable endpoints.
• SecP256r1MLKEM768: 161 HTTPS endpoints.
• SecP384r1MLKEM1024: supported by 59 endpoints.

How should OT and critical infrastructure operators apply this choice?

Start from who controls each end of the connection. On links where you manage both ends, you can enforce one group. On cloud and remote-user paths, the group you get depends on what the client and platform support.

• Site-to-site links: configure one hybrid group on both ends and do not let the connection fall back to classical-only key exchange. A recorded handshake without a post-quantum component stays exposed to future decryption.
• Do not offer every hybrid by default. The hybrid design draft points out that offering both SecP256r1MLKEM768 and X25519MLKEM768 means the client would end up sending two ML-KEM-768 public keys. On constrained OT links, offer one key share and let HelloRetryRequest handle the rare mismatch.
• Edge to cloud: check which groups your cloud endpoints actually negotiate. Do not rely on what is configured. Packet captures of the ServerHello settle the question.
• Plan for change. NIST’s proposed revision of SP 800-56C would allow greater flexibility in the formatting of hybrid shared secrets. That could relax today’s ordering constraint, so make sure you can swap algorithms without touching the equipment behind the encryption point.

Encryption gateways that work at Layer 3 rather than in TLS face the same design questions. Quantum Network’s QPN, for example, combines a classical part and an ML-KEM (FIPS 203) part into one session key, renews both handshakes every two minutes, and allows the post-quantum algorithm to be changed if needed. Whatever you evaluate, ask the same questions this article covers: which classical component and ML-KEM parameter set are used, how the secrets are combined, and how quickly the algorithm can be replaced.