Post-Quantum Encryption in Practice: Hybrid ML-KEM and X25519, FIPS 203

The threat in plain terms

Most of the public-key cryptography used today, RSA and elliptic-curve Diffie-Hellman among it, depends on mathematical problems that a sufficiently large quantum computer could solve quickly. Nobody can say when such a machine will exist, and nobody should plan around a date. The planning argument is different. Data that must stay secret for many years, such as medical records, legal files, financial agreements, trade secrets and government material, can be recorded by an adversary now and decrypted later. That is called harvest now, decrypt later. It makes the protection of key exchange urgent even though the quantum computer does not yet exist, because the exposure begins when the traffic is captured, not when the machine arrives.

Symmetric cryptography is affected much less. AES with a 256‑bit key is considered resistant, and our own backup standard already specifies random 256‑bit keys for that reason. The weak points are the public-key parts: key exchange, which sets up the shared secret for a session, and digital signatures, which prove who signed something. The two migrate separately and on different timelines.

What FIPS 203 standardizes

NIST published FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard, on 13 August 2024, after a draft in August 2023. It specifies ML-KEM, a way for two parties to establish a shared secret key over a public channel. NIST's page says the scheme's security is related to the computational difficulty of the Module Learning with Errors problem and that ML-KEM is believed to be secure even against adversaries who possess a quantum computer. The standard defines three parameter sets, ML-KEM-512, ML-KEM-768 and ML-KEM-1024, listed in order of increasing security strength and decreasing performance. ML-KEM is the standardized form of the scheme submitted to NIST's competition as CRYSTALS-Kyber; the NIST page we read does not mention that name, so that connection is background knowledge rather than something the source states.

A key-encapsulation mechanism works differently from Diffie-Hellman in its interface: one party generates a key pair and publishes the encapsulation key; the other uses it to produce a ciphertext and a shared secret; the first party decapsulates the ciphertext to recover the same secret. For a protocol designer the difference is mostly bookkeeping. For an operator the practical differences are the sizes of the values and the fact that implementations must be tested carefully, since lattice-based schemes have different side-channel risks from elliptic curves.

Why hybrid

Post-quantum algorithms are new compared with elliptic-curve cryptography, which has decades of analysis and implementation experience. The conservative response is to run both. In a hybrid key exchange the client and server perform an X25519 exchange and an ML-KEM exchange, and derive the session key from both shared secrets. An attacker has to break both. If ML-KEM turns out to have a flaw, X25519 still protects against classical attackers. If a quantum computer arrives, ML-KEM still protects the session.

The IETF TLS working group has standardized this for TLS 1.3. The specification we read, published as RFC 10024 in August 2026 as a Proposed Standard, defines three named groups. X25519MLKEM768 combines X25519 with ML-KEM-768 and is marked recommended. SecP256r1MLKEM768 combines the NIST P-256 curve with ML-KEM-768, and SecP384r1MLKEM1024 combines P-384 with ML-KEM-1024; those two are not recommended by default but suit environments that need both shared secrets to come from FIPS-approved mechanisms. The RFC obsoletes the earlier pre-standard Kyber768 code points that some early deployments used. Its stated rationale is that a hybrid remains secure as long as at least one component stays secure, and that X25519 is widely deployed and the practical choice for a single hybrid.

The mechanics are straightforward. The client sends one key-share value that concatenates the ML-KEM encapsulation key and the X25519 share, 1,216 bytes for X25519MLKEM768. The server replies with the ML-KEM ciphertext followed by its X25519 share, 1,120 bytes. The shared secret is the two secrets concatenated, 64 bytes, and TLS's key schedule does the rest. Both sides validate lengths and elliptic-curve points. A client that offers the hybrid group will usually also offer plain X25519, so a server that does not support the hybrid still completes the handshake classically.

What it costs and what breaks

Computation is not the issue; ML-KEM is fast, comparable to elliptic-curve operations. The cost is bytes. A classic X25519 client key share is 32 bytes. The hybrid is more than 1,200. That makes the first handshake message large enough that it may not fit in one packet, and the TLS ClientHello may be split across packets. Some old firewalls, load balancers and inspection devices that read the ClientHello assume it fits in one segment and fail or drop it. This is a deployment problem, not a flaw in the cryptography, and it is why the first step in migration is to test your own path: the proxies, appliances and monitoring tools between a client and a server.

Operational monitoring changes too. Deep-inspection devices that terminate TLS must support the new groups or they will downgrade traffic to classical exchange. Logs and tooling that record the negotiated group let you measure how much of your traffic is protected, which is the number worth reporting upward. Bandwidth and latency effects are small for web traffic but can matter for constrained links and very high connection rates.

A practical migration plan

• Inventory. List where public-key cryptography is used: TLS on public and internal services, VPNs, SSH, email encryption, code signing, document signing, disk and backup key wrapping, certificates and identity systems, and embedded devices. Note who owns each and whether it can be updated.
• Classify by secrecy lifetime. A session carrying data that must stay confidential for ten years is a higher priority than one carrying a login page. Prioritize long-lived confidentiality over short-lived.
• Turn on hybrid key exchange where it is a setting. Current browsers, operating systems and TLS libraries increasingly support X25519MLKEM768; web servers, load balancers and content delivery networks can enable it. Measure the negotiated group in logs.
• Test the path. Verify that large ClientHello messages pass through every middlebox, and fix or replace those that do not.
• Ask vendors in writing for their post-quantum roadmap and for which standardized groups and algorithms they support. Make it a contract question for new purchases.
• Plan signatures separately. Certificates and signatures need post-quantum algorithms and a longer migration, tied to certificate lifetimes and your PKI; see our article on certificate lifecycle automation, because a company that can reissue certificates quickly has an easier path.
• Keep cryptographic agility as a design requirement: algorithms should be configuration, not hard-coded, so the next change does not require rewriting software.
• Do not roll your own hybrid. Use the standardized groups in maintained libraries, and prefer FIPS-validated modules where regulation or contracts require them.

Common mistakes to avoid

The first mistake is waiting for certainty. Standards for key exchange are final, and the hybrid construction is published, so there is no technical reason to delay turning it on where your software supports it. The second is treating the migration as a single project with an end date. Cryptography changes continuously, and the goal is to be able to change, which is why inventory and agility come before any particular algorithm. The third is confusing key exchange with signatures: enabling a hybrid group protects the confidentiality of a session, but does nothing for the authenticity of a certificate or a signed document, which depend on different algorithms and a later migration. The fourth is ignoring data at rest and in backups. Encrypted archives that use a public-key wrapper around a symmetric key inherit the weakness of the wrapper, so backup tools and key-wrapping schemes belong in the inventory. Finally, beware of products that advertise quantum-safe features without naming the algorithm and the standard they implement. A vendor should be able to say which parameter set of ML-KEM it uses, in which protocol, and how that was tested.

What this means for regulated firms and for our own work

Banks, health providers and law firms hold data with long confidentiality needs, and their contracts and regulators increasingly ask about cryptographic inventory and migration planning. A short written inventory, a stated policy for hybrid key exchange on externally facing services, and evidence from logs of the share of protected connections are a defensible position at this stage. Waiting for every product to support signatures is not necessary; key exchange is where the exposure is.

The same reasoning applies in our own engineering, where wallet and messaging designs have to survive for years. We treat post-quantum key exchange as a baseline for new systems and as a planned upgrade for existing ones, always through standardized, reviewed constructions. Clayton Cybernetics helps clients build the inventory, test their paths and turn on hybrid exchange where it matters first.

Sources

• NIST FIPS 203 - Module-Lattice-Based Key-Encapsulation Mechanism Standard
• IETF - Post-quantum hybrid ECDHE-MLKEM key agreement for TLS 1.3 (RFC 10024 / draft-ietf-tls-ecdhe-mlkem)

This article is general technical information, not a cryptographic design or compliance opinion. We read the NIST FIPS 203 page and the IETF datatracker page for the hybrid TLS specification through a summarizing fetch tool; the full text of FIPS 203 and of the RFC were not read, and the RFC number and status (RFC 10024, Proposed Standard, August 2026) come from the datatracker page and should be confirmed in the RFC editor index. The harvest-now-decrypt-later explanation, the remarks on AES-256, packet-size effects on middleboxes, the inventory and migration plan and the FIPS-validation advice are general engineering knowledge, not quoted from the sources listed. The link between ML-KEM and CRYSTALS-Kyber is background knowledge not stated on the NIST page we read. Last reviewed November 8, 2026.

Keep reading

Next · InfrastructureCan the Internet Be Switched Off in the US, and How Would a Business Keep Working?A question that surfaces after every major outage or crisis: could the U.S. government turn the internet off, and what would a company do if it did? The honest answer has two parts. The law gives a President broad emergency powers over communications, and nobody has tested how far they reach over the modern internet. And the more likely causes of a long outage are hurricanes, cable cuts, cloud failures and attacks on a provider, not a decree. This article reads the statute, explains why a total shutdown is practically hard, and describes how any business, with a law office as one worked example, keeps its core work running when connectivity is gone.10 min read

• Penetration Testing Explained for Executives: Scope, Reports and How Often to Test8 min
• Ransomware Readiness and Incident Response: A Checklist Based on the CISA #StopRansomware Guide9 min