up:: Migration Architecture MOC

Hybrid Cryptography

Hybrid cryptography is the practice of running a classical algorithm and a post-quantum algorithm together in the same operation and deriving the result from both, so the protection holds as long as at least one of the two remains unbroken. In the post-quantum transition it is the standard way to establish keys, because it hedges the biggest open risk on both sides: the classical algorithm is old and trusted but a future quantum computer breaks it, while the post-quantum algorithm resists quantum attack but is young and less battle-tested. Combining them means an attacker has to defeat the mature algorithm and the new one at once, which is why TLS, IPsec, and SSH all reached for hybrid first rather than switching straight to a post-quantum algorithm on its own.

The short version:

• Hybrid means two algorithms, one classical and one post-quantum, feeding a single key. You are secure if either half holds, so you are only broken if both fail at the same time.
• The common construction is X25519MLKEM768: the classical X25519 key exchange plus ML-KEM-768, with the two shared secrets concatenated and run through the key schedule into one session key.
• It is the default during the transition because it protects against a quantum break of the classical side and against an undiscovered flaw in the young post-quantum side simultaneously.
• The deployment trap is size. A hybrid key share is much larger than a classical one, and the oversized first message can spill past a single packet and trip old middleboxes that assumed handshakes stay small. A protocol is only as safe as its weakest endpoint on the path.
• Hybrid is a bridge, not a destination. The classical component is the part a quantum computer breaks, so it has to come out before Q-Day, leaving the post-quantum algorithm standing alone.

Think of a bank vault with two different locks on the same door, one a heavy old combination dial that every locksmith understands, the other a new electronic lock nobody has picked yet. A thief who has spent years learning to crack combination dials still cannot open the door, because the electronic lock stops him. A thief with a zero-day for the electronic lock still cannot open it, because the old dial stops him. He needs to beat both locks in the same night. That is the whole idea: you are exposed only if both mechanisms fail together, and until then the weaker-looking one is still doing real work.

What is hybrid cryptography?

Hybrid cryptography is an architecture pattern, not a single algorithm. It takes two independent cryptographic mechanisms from different families, runs both, and combines their outputs under an explicit composition rule so that the combined result inherits the security of whichever component survives. In the current transition the two families are deliberately chosen to fail in unrelated ways: a classical algorithm like elliptic-curve Diffie-Hellman or RSA, whose security rests on problems a large quantum computer solves efficiently, paired with a post-quantum algorithm like ML-KEM, whose security rests on lattice problems believed hard for both classical and quantum machines.

The IETF specification for hybrid key exchange in TLS 1.3 states the design goal precisely: “The primary goal of a hybrid key exchange mechanism is to facilitate the establishment of a shared secret which remains secure as long as one of the component key exchange mechanisms remains unbroken.” That single sentence is the reason the pattern exists.

Source: Stebila, Fluhrer, Gueron, “Hybrid key exchange in TLS 1.3,” IETF, draft-ietf-tls-hybrid-design.

The word “hybrid” gets used loosely, so it helps to fix what it does and does not mean. Hybrid is about combining algorithm families for redundancy during a migration. It is distinct from crypto-agility, which is the ability to swap an algorithm through configuration, and a system can be agile without being hybrid or hybrid without being agile. It also carries a narrower formal name in the standards world, PQ/T hybrid, where T stands for “traditional,” to make explicit that exactly one classical and one post-quantum algorithm are being composed rather than two of the same kind.

Why is hybrid the default during the transition?

Hybrid is the default because it insures against the two failures that actually keep engineers up at night, and it insures against both at the same time. The classical algorithms in wide use today are trusted precisely because decades of cryptanalysis have failed to break them, but that trust has an expiration date: a cryptographically relevant quantum computer running Shor’s algorithm breaks RSA and elliptic-curve cryptography outright.

The post-quantum algorithms are built to survive that machine, but they are young, and a young algorithm carries a different risk: a classical cryptanalytic flaw that nobody has found yet, or a subtle implementation weakness in early code. Hybrid covers both. If the quantum computer arrives, the post-quantum half holds. If the post-quantum algorithm turns out to have a flaw, the classical half holds until the quantum computer exists.

This matters most for data that has to stay confidential for a long time, because of harvest now, decrypt later. An adversary can record encrypted traffic today and store it until a quantum computer can open it. Deploying a hybrid key exchange now closes that window on new sessions immediately, without betting the entire estate on a post-quantum algorithm that has only had a few years of public scrutiny. Mosca’s theorem frames the timing as a race between how long your data must stay secret plus how long migration takes, versus how long until the quantum computer arrives, and hybrid lets an organization start protecting long-lived data at the front of that race rather than the back.

Not every authority treats hybrid as mandatory, and that nuance is worth stating plainly. NSA’s CNSA 2.0 does not require hybrid solutions for national security systems; it expresses confidence in the standalone post-quantum algorithms and allows hybrid mainly for interoperability or where a protocol cannot cleanly carry a single large key. In IKEv2, for example, NSA anticipates using a design that performs a small classical key establishment followed by a larger ML-KEM-1024 establishment, precisely because a standalone ML-KEM-1024 exchange would demand awkward changes to the protocol. So hybrid is the pragmatic default across most of the commercial internet, and it is a permitted-but-not-required tool in the national-security profile.

Source: NSA, “The Commercial National Security Algorithm Suite 2.0 and Quantum Computing FAQ,” CSI_CNSA_2.0_FAQ.

How does hybrid key exchange actually work?

Hybrid key exchange runs the two key-establishment mechanisms in parallel, then folds their two shared secrets into one before either side derives session keys. The mechanics are concrete and worth walking through with the construction almost everyone deploys, X25519MLKEM768, which pairs the classical X25519 elliptic-curve exchange with the post-quantum ML-KEM-768 key-encapsulation mechanism.

1. The client generates an X25519 ephemeral key pair and an ML-KEM-768 encapsulation key, and sends both. In TLS the client’s key share is the ML-KEM-768 encapsulation key followed by the X25519 public key, 1216 bytes in total (1184 for the ML-KEM part, 32 for X25519).
2. The server generates its own X25519 ephemeral key and runs ML-KEM encapsulation against the client’s encapsulation key, producing a ciphertext and a post-quantum shared secret. It returns the ML-KEM ciphertext followed by its X25519 public key, 1120 bytes in total (1088 for the ML-KEM part, 32 for X25519).
3. Each side now computes two shared secrets independently: the X25519 Diffie-Hellman result, and the ML-KEM decapsulated secret.
4. The two secrets are concatenated, classical_secret || pq_secret, and that combined value enters the key derivation function in place of the single classical secret the protocol used before. Every downstream key comes from both halves at once.

Source: Kwiatkowski, Kampanakis, Westerbaan, Stebila, “Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3,” IETF, draft-ietf-tls-ecdhe-mlkem; Stebila, Fluhrer, Gueron, draft-ietf-tls-hybrid-design (“the two shared secrets are concatenated together and used as the shared secret in the existing TLS 1.3 key schedule”).

The security of the combination comes from the KDF. Because the derivation mixes both secrets, an attacker who recovers one of them still cannot predict the output without the other. This is why the standard is careful about how the concatenation feeds the key schedule: the combining step is where the “secure if either holds” property is actually enforced, so a sloppy composition that leaked structure from one secret would undermine the whole point. The construction here is the “parallel” composition mode, where the two algorithms run side by side and their outputs are combined, which is the shape almost all current standards use.

Direction	key_share contents (in order)	ML-KEM part	X25519 part	Total
Client to server	ML-KEM-768 encapsulation key, then X25519 public key	1184 bytes	32 bytes	1216 bytes
Server to client	ML-KEM-768 ciphertext, then X25519 public key	1088 bytes	32 bytes	1120 bytes

Source: draft-ietf-tls-ecdhe-mlkem, §3 (TLS supported_groups codepoint 4588 / 0x11EC).

Where is hybrid cryptography used today?

Hybrid key exchange is already live in the three protocols that carry most of the internet’s encrypted traffic, and in each case the pattern is the same classical-plus-ML-KEM pairing wired into the protocol’s existing negotiation.

Protocol	Hybrid mechanism	Standard	Deployment status
TLS 1.3	X25519MLKEM768 (X25519 + ML-KEM-768), codepoint 0x11EC	draft-ietf-tls-ecdhe-mlkem / draft-ietf-tls-hybrid-design	Shipped by default in Chrome, Edge, and Firefox; advertised by Cloudflare, Google, and major CDNs
IPsec / IKEv2	Multiple key exchanges: classical (EC)DH plus one or more post-quantum KEMs, combined into the final key	RFC 9370	Published standard; implemented by major VPN vendors
SSH	mlkem768x25519-sha256 (X25519 + ML-KEM-768)	OpenSSH, per draft-ietf-sshm-mlkem-hybrid-kex	Default key exchange since OpenSSH 10.0 (April 2025); hybrid available by default since 9.0

Sources: RFC 9370, Multiple Key Exchanges in IKEv2; OpenSSH, “Post-Quantum Cryptography” (mlkem768x25519-sha256 default in 10.0; sntrup761x25519-sha512 by default since 9.0); browser and CDN deployment per draft-ietf-tls-ecdhe-mlkem.

The common thread is that hybrid slots into machinery the protocol already had. TLS already negotiated a “group” for key exchange, so a hybrid group is a new named option in the same negotiation. IKEv2 already supported an exchange step, so RFC 9370 adds the ability to layer additional key exchanges on top of the first. SSH already named its key-exchange algorithm in a handshake, so a hybrid name drops into the same slot. None of these required inventing a new protocol, which is a large part of why hybrid moved from paper to production so quickly.

How does the signature side work?

Key exchange protects confidentiality, but authentication runs on signatures and certificates, and hybrid has a parallel story there under a different name. A hybrid signature signs the same message with both a classical algorithm and a post-quantum one, and the two signatures travel together so a verifier can check both. The goal mirrors hybrid key exchange: a forgery requires defeating both signature algorithms, so the authentication holds as long as either remains unforgeable.

The IETF’s standardization of this for certificates is Composite ML-DSA, which combines ML-DSA with a traditional signature algorithm (RSA-PSS, RSA-PKCS1, ECDSA, Ed25519, or Ed448) and treats the pair as a single algorithm with a single public key, signature, and identifier. Its stated security property is exactly the belt-and-suspenders one: “a classical adversary cannot forge a Composite ML-DSA signed certificate if at least one component algorithm is classically EUF-CMA secure, and a quantum adversary cannot forge a Composite ML-DSA signed certificate if ML-DSA remains quantumly EUF-CMA secure.”

Source: Ounsworth, Gray, Pala, Klaußner, Fussell, “Composite ML-DSA for use in X.509 Public Key Infrastructure,” IETF, draft-ietf-lamps-pq-composite-sigs; RFC 9794 (a composite algorithm is treated as a single algorithm performing one operation).

There are two broad ways to carry hybrid authentication, and the distinction matters for how much of the ecosystem has to understand the new structure. Composite certificates wrap both algorithms into one certificate that a library handles as a single unit, so protocols like PKCS#10, CMS, and X.509 can treat it like any other algorithm. Dual-signature approaches instead carry two parallel certificates or two separate signatures, which keeps each algorithm legible to old software but pushes the “require both” policy decision out to every verifier. Composite hides the complexity inside the crypto library; dual keeps it visible and puts the burden on the verifier’s rules.

What is the deployment trap with hybrid?

The trap is size, and it is the most common way a hybrid rollout fails in production. A classical key share is tiny, tens of bytes. A hybrid key share carrying an ML-KEM encapsulation key is over a kilobyte, and that inflation lands in the first message of the handshake. In TLS the ClientHello was almost always small enough to fit in a single network packet, and decades of middleboxes, load balancers, and inspection appliances quietly assumed it always would be. A 1216-byte hybrid key share pushes the ClientHello past that boundary and splits it across two packets, and some of that old equipment mishandles or simply drops a ClientHello it cannot buffer.

This is protocol ossification: the ecosystem hardened around an assumption that was true for years, and the assumption stopped being true. Cloudflare, testing hybrid at scale, found sharp cliffs where connections failed once the handshake grew past certain sizes, evidence that specific middleboxes cannot process handshakes beyond a fixed length and start dropping them. The failure is not in the cryptography and not in the two endpoints that both support hybrid; it is a third box on the path that neither endpoint controls.

Source: Cloudflare, “Defending against future threats: Cloudflare goes post-quantum”.

That is the load-bearing lesson: a protocol is only as safe as its weakest endpoint on the path. Two perfectly configured hybrid endpoints still fail if a legacy device between them refuses the larger handshake, and the fix is rarely as simple as flipping a setting because the offending box may belong to a network operator, a cloud provider, or a customer. The standards anticipated this and left an escape hatch: a client can advertise hybrid support while sending only a small classical key share first, and if the server wants hybrid it uses a HelloRetryRequest to ask for the full hybrid share on a second round trip. That trades a small latency cost for surviving the middleboxes, but it is a workaround for a compatibility problem that pure-classical cryptography never had.

When does the classical half come out?

Hybrid is a transition mechanism with a built-in expiration, because the classical component is the exact thing a quantum computer breaks. Once a cryptographically relevant quantum computer exists, the classical half of every hybrid contributes nothing to security against that adversary, and continuing to run it is dead weight in the handshake. The endgame of the migration is the classical component retiring and the post-quantum algorithm standing alone, on the schedule the mandates set. CNSA 2.0, for instance, drives national security systems toward standalone post-quantum algorithms rather than permanent hybrids.

The discipline this demands is an exit plan, and it is the part organizations most often skip. Hybrid earns its place by hedging risk during the window when a quantum computer might not exist yet and the post-quantum algorithms are still young. As the post-quantum algorithms accumulate scrutiny and the quantum timeline sharpens, that hedge stops paying for its complexity, and the classical half should come out before the deadline rather than lingering because nobody owns the decision. A hybrid deployment with no plan to observe, validate, and eventually remove the classical component turns a transition tool into permanent technical debt, which is the quiet way hybrid goes wrong long after the rollout looked like a success.

Has cryptography been layered like this before?

Layering cryptography so that breaking one part is not enough to read the message is an old idea, and the clearest historical example is superencipherment. In the Second World War the Imperial Japanese Navy’s main operational system, known to American codebreakers as JN-25, was a codebook that turned words and phrases into number groups, and those number groups were then enciphered a second time by adding a stream of key numbers from a separate additive table. To read a message an analyst had to strip the additive layer and reconstruct the codebook, two distinct cryptanalytic problems stacked on one message, and progress on one did not hand you the other. The US Navy’s partial solution of JN-25 before Midway in 1942 was hard precisely because both layers had to be defeated.

Source: David Kahn, The Codebreakers.

The parallel is instructive and the difference is worth naming. Superencipherment stacks the two mechanisms in series, one applied on top of the other, so an attacker peels them off one at a time. Modern hybrid runs its two algorithms in parallel and combines their secrets through a key derivation function, which is a cleaner construction with a sharper guarantee. The shared intuition across eighty years is the same: do not bet everything on one mechanism when the cost of being wrong is catastrophic, and design so that a single break is survivable.

Common misconceptions

• “Hybrid extends the deadline.” It does the opposite of buying you time to relax. Hybrid closes the harvest-now-decrypt-later window on new data immediately, but the classical half still has to be removed before Q-Day, so the migration deadline is unchanged. Hybrid gets you to the starting line sooner; it does not move the finish line.
• “Two algorithms automatically means twice the security.” Security comes from the composition, not from the count. A hybrid is “secure if either holds” only when the secrets are combined correctly through the KDF and the protocol refuses to silently fall back to classical-only. A sloppy combination can forfeit the guarantee even with two algorithms present.
• “Hybrid is the permanent answer.” It is a bridge sized for the transition window. The classical component is quantum-vulnerable by definition, so a hybrid that never retires its classical half is running dead weight and, worse, hiding an unfinished migration behind a reassuring word.
• “If both endpoints support hybrid, we’re done.” The oversized handshake can be dropped by a middlebox neither endpoint controls. Hybrid support at the two ends is necessary and not sufficient; the whole path has to tolerate the larger messages.
• “Hybrid and crypto-agility are the same thing.” They are related and distinct. Hybrid runs two algorithm families at once for redundancy; crypto-agility is the ability to change the algorithm centrally through configuration. You want both, but having one does not give you the other.
• “NIST and NSA both require hybrids.” NSA’s CNSA 2.0 permits hybrids but does not require them for national security systems, and favors standalone post-quantum algorithms. Hybrid is the pragmatic commercial default, not a universal mandate.

Questions people ask

Is hybrid slower than classical or pure post-quantum key exchange? It adds work and bytes, since both algorithms run and both key shares travel, but for ML-KEM the computation is fast and the dominant cost is the larger handshake rather than CPU time. In practice the measurable hit is the extra kilobyte in the first message and the occasional extra round trip when a HelloRetryRequest is needed to dodge middleboxes, rather than any meaningful slowdown in the cryptography itself.

Which hybrid group should I expect to see in TLS? X25519MLKEM768, codepoint 0x11EC (decimal 4588). It combines the classical X25519 curve with ML-KEM-768 and is the group the major browsers and CDNs have already shipped by default, so it is the one you will encounter in real traffic and captures.

Do I have to use hybrid, or can I go straight to post-quantum? Both are valid depending on your risk posture and your regulator. Hybrid is the widespread commercial default because it hedges a flaw in the young post-quantum algorithms, while CNSA 2.0 permits going straight to standalone post-quantum algorithms and does not require the hybrid step. The tradeoff is a young-algorithm hedge on one side against a smaller, simpler handshake on the other.

Does hybrid protect data I already sent? No. Encryption protects sessions going forward, so already-collected ciphertext that used classical-only key exchange stays exposed to a future quantum computer. That is the harvest-now-decrypt-later problem, and it is the argument for deploying hybrid on long-lived confidential traffic as early as possible rather than waiting.

Why is the post-quantum part so much bigger than the classical part? ML-KEM is a lattice-based scheme, and its keys and ciphertexts are naturally larger than elliptic-curve values: an ML-KEM-768 encapsulation key is 1184 bytes against 32 bytes for an X25519 public key. That size difference is inherent to the math and is the root cause of the oversized-handshake compatibility problem.

How do I know a connection is actually using hybrid and not silently falling back? You verify it on the wire, not from a config file. A packet capture of the handshake shows the negotiated group (for TLS, X25519MLKEM768 / 0x11EC) and the kilobyte-scale key shares. Confirming hybrid is genuinely negotiated, rather than assuming it because it is enabled, is exactly the kind of check that separates a real deployment from a claimed one.

Is hybrid only about key exchange, or does it cover signatures too? Both. Confidentiality is handled by hybrid key exchange (classical Diffie-Hellman plus ML-KEM), and authentication is handled by hybrid signatures, standardized for certificates as Composite ML-DSA. They are separate mechanisms that transition on their own timelines, which is one reason a full migration touches more than just TLS key exchange.

What happens to hybrid once a quantum computer exists? The classical half loses all value against that adversary, so the migration’s endpoint is the classical component retiring and the post-quantum algorithm running alone. Planning that retirement is part of doing hybrid correctly, because a hybrid with no exit strategy quietly becomes permanent overhead.

---

Everything here is the map, given freely. When your team needs its own protocols, certificates, and endpoints assessed for a safe hybrid rollout and a real retirement plan, that’s what an alignment briefing is for.

Last verified 2026-07-09 · Maintained by Addie LaMarr, LaMarr Labs.