X25519MLKEM768: Post-Quantum Hybrid Key Exchange Explained

X25519MLKEM768 is a TLS 1.3 hybrid key-agreement group. It combines the widely deployed X25519 ephemeral Diffie-Hellman exchange with ML-KEM-768, the post-quantum key-encapsulation mechanism specified by NIST FIPS 203. The hybrid design keeps a classical exchange while adding a post-quantum component, so the resulting handshake is intended to remain secure against both conventional and quantum-capable attackers.

The group is identified by TLS Supported Groups value 4588 (0x11EC). It establishes handshake secrets; it does not replace your certificate, TLS record cipher, or application protocol.

What X25519MLKEM768 contains

Component	Role
X25519	Ephemeral elliptic-curve Diffie-Hellman key agreement.
ML-KEM-768	Post-quantum key encapsulation defined by NIST FIPS 203.
TLS 1.3 hybrid framework	Combines the two shared-secret results before deriving traffic keys.

RFC 10024 defines three hybrid TLS 1.3 mechanisms: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024. The RFC describes the first as combining X25519 ECDH with ML-KEM-768 and marks it Recommended and DTLS-OK. See the RFC 10024 specification.

How the TLS 1.3 handshake works

1. The client sends a supported_groups extension listing groups it can use, including X25519MLKEM768 when supported.
2. The client sends a matching key_share. For this hybrid group, that share contains the ML-KEM-768 encapsulation public-key material together with the client’s ephemeral X25519 share.
3. The server selects a mutually supported group and processes both components.
4. The TLS hybrid construction combines the X25519 and ML-KEM shared secrets.
5. TLS 1.3’s normal key schedule derives handshake and application traffic keys from the combined secret.

Each offered hybrid combination has its own key share. Offering several hybrid combinations can therefore add several ML-KEM public keys to ClientHello, increasing the handshake size. RFC 9954 discusses this key-share behavior in detail: Hybrid key exchange in TLS 1.3.

What it does not change

• Not a bulk cipher: after key establishment, TLS record protection still uses suites such as AES-GCM or ChaCha20-Poly1305.
• Not a certificate replacement: your server certificate and its signature algorithm remain separate. ML-KEM certificate identifiers are a distinct PKIX topic; using ML-KEM certificates directly in TLS would require substantial protocol changes. See RFC 9935.
• Not an HTTP feature: applications continue to use HTTPS normally once the TLS stack negotiates the group.

What does 0x11EC mean?

0x11EC is the hexadecimal representation of decimal 4588, the IANA TLS Supported Groups code point assigned to X25519MLKEM768. Use the final RFC 10024 name and code point. Older experiments may use names such as X25519Kyber768Draft00; those draft identifiers are not the standardized group.

Comparison with the other standardized hybrids

Group	Classical component	Post-quantum component	When it may fit
X25519MLKEM768	X25519	ML-KEM-768	General deployment where broad ecosystem support and practical performance matter.
SecP256r1MLKEM768	P-256	ML-KEM-768	Policies requiring a NIST elliptic curve for the classical component.
SecP384r1MLKEM1024	P-384	ML-KEM-1024	Environments seeking a larger classical security margin and accepting additional overhead.

Choose using your classical-curve policy, FIPS validation requirements, target security margin, message-size budget, CPU capacity, and actual library or proxy support. There is no universal latency or bandwidth number: benchmark the exact implementation, version, hardware, and handshake pattern you operate.

Checking negotiation from the command line

Support depends on the TLS library and its build. First inspect the groups your local OpenSSL exposes:

openssl list -tls1_3 - kem-algorithms
openssl s_client -help 2>&1 | grep -i groups

If your build accepts the standardized group name, request it explicitly:

openssl s_client -connect example.com:443 -servername example.com -tls1_3 -groups X25519MLKEM768

A successful connection shows the negotiated TLS version and cipher. The output does not prove that every intermediary supports the group; test through the real load balancer, CDN, or service mesh path.

With curl builds backed by a TLS library that supports the group, a TLS 1.3 request can look like:

curl --tlsv1.3 --curves X25519MLKEM768 https://example.com/

If the option or group is rejected, your curl or underlying TLS library may predate the standardized support, or the peer may not offer the group.

Deployment checklist

1. Confirm RFC 10024 support in both endpoint TLS libraries.
2. Check every terminating proxy, load balancer, CDN, service mesh sidecar, and DTLS endpoint in the path.
3. Enable the final group name and code point, not a draft Kyber identifier.
4. Keep classical groups available during rollout so older peers can negotiate TLS 1.3 normally.
5. Capture ClientHello and ServerHello in a staging environment and verify the selected group.
6. Measure handshake bytes, CPU time, connection setup latency, and retry behavior on representative hardware.
7. Set monitoring for negotiation failures and unexpected fallback.

Edge cases and interoperability

• Peer lacks support: negotiation should select another mutually supported TLS 1.3 group if one remains enabled.
• Middlebox size limits: larger key shares can expose brittle firewalls or proxies. Test fragmented and lossy network paths.
• Multiple offerings: advertising many hybrid groups increases ClientHello size because each needs a key share when offered.
• Draft implementations: a peer supporting only an obsolete draft code point is not equivalent to RFC 10024 support.
• DTLS: RFC 10024 marks X25519MLKEM768 DTLS-OK, but verify support in the specific DTLS implementation and version.
• Certificate policy: migrating key agreement does not automatically change certificate issuance, rotation, or signature validation.

Troubleshooting

Symptom	Likely cause	Fix
Unknown group or invalid curve	Old TLS library, curl build, or draft-only support.	Upgrade the library and verify the final RFC 10024 identifier is compiled in.
Handshake fails after enabling only this group	The peer or an intermediary does not support it.	Restore a classical fallback group and test each endpoint separately.
Large ClientHello rejected	Firewall or proxy assumes smaller handshake messages.	Test path MTU and fragmentation handling; reduce simultaneously offered groups while retaining policy coverage.
Server selects a different group	The server preference order or client offer does not include a compatible X25519MLKEM768 share.	Inspect both extensions and configure compatible group ordering.
Certificate warnings remain	Key agreement and certificate authentication are separate mechanisms.	Install and validate the appropriate certificate chain; do not expect hybrid key exchange to alter certificate checks.
Unexpected CPU or latency increase	ML-KEM processing and larger messages add work.	Benchmark under production concurrency, reuse connections where possible, and size capacity from measured results.

Performance, reliability, and cost considerations

Hybrid negotiation adds key material and computation compared with X25519 alone. The impact depends on implementation quality, hardware, connection reuse, packet loss, and how many groups you offer. Record at least handshake CPU, p50/p95/p99 setup time, bytes sent and received, handshake failure rate, and fallback rate before and after rollout.

For reliability, deploy in stages, preserve a compatible fallback, and alert on changes in negotiated-group distribution. For cost, account for extra bandwidth and CPU at both endpoints and at terminating proxies. The standards do not provide one benchmark that can be applied to every deployment.

Or skip the browser setup

If you are collecting documentation screenshots of TLS configuration pages, traces, or dashboards, ScreenshotNeo can return a clean image or PDF with one GET request. Its consent handling accepts cookie banners and removes more than 60 known consent platforms, newsletter popups, and chat widgets before capture. Bot checks, blank pages, timeouts, failed loads, and cache hits are not billed, and response headers identify the page verdict and billing status. An MCP server provides take_screenshot, get_page_info, and capture_pdf tools for Claude, Cursor, and other MCP clients. The free plan includes 1,000 screenshots per month without a card; paid plans start at $5 for 3,000 shots.

See the ScreenshotNeo API documentation for all options.

cURL

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

Python

import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)

Node.js

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

Create a free ScreenshotNeo account to get 1,000 screenshots each month with no card.

FAQ

Is X25519MLKEM768 quantum safe?

It is designed as a hybrid against classical and quantum-capable attackers, combining X25519 with ML-KEM-768. Security still depends on correct implementation, configuration, and endpoint authentication.

Does it replace AES-GCM or ChaCha20-Poly1305?

No. It establishes TLS handshake secrets; the negotiated TLS record cipher continues to protect application data.

Does it replace my TLS certificate?

No. Certificate authentication is a separate part of TLS. Hybrid key agreement can be deployed while retaining your existing certificate workflow.

Why is the name so long?

The name identifies both components: X25519 and ML-KEM-768. The hexadecimal code point is 0x11EC.

Should every server enable all three hybrid groups?

Not automatically. Select groups that match your policy and implementation support, then measure message size, CPU, interoperability, and fallback behavior.

What should I monitor after rollout?

Track negotiated groups, handshake failures, fallback frequency, handshake size, setup latency, and endpoint CPU under realistic concurrency.