Marin Ivezic
The word “hybrid” is overloaded, and the overload costs engineers real time in design reviews. Three usages are in circulation, and only two of them have anything to do with quantum computers.
Hybrid public key encryption is the oldest sense of the term. RFC 9180 standardises HPKE, in which an asymmetric operation establishes a symmetric key and a symmetric cipher does the bulk encryption. Every TLS session you have ever opened is hybrid in that sense. None of it is post-quantum.
Hybrid key exchange is what most people mean now. Two key establishment algorithms run inside a single handshake, one classical and one post-quantum, and the session keys are derived from both.
Hybrid signatures, also called dual or composite signatures, attach two signatures to the same object so that old verifiers and new verifiers can each do their job.
This article works through the second and the third, starting at the bytes and moving outward to the operational surface. If you are trying to decide whether hybrid or pure post-quantum is right for a given system, that is a different question with a different answer per system. Here we’re concerned with what the machinery does.
What the combiner actually does
Start with the two halves.
A key encapsulation mechanism, or KEM, is the post-quantum replacement for Diffie-Hellman key agreement. It works in three steps. One side generates a keypair and sends the public half, called the encapsulation key. The other side runs encapsulation against it, which produces a ciphertext and a shared secret. The first side decapsulates the ciphertext and recovers the same shared secret. ML-KEM, standardised as FIPS 203, is the KEM NIST selected as its primary choice, and at the ML-KEM-768 parameter set the encapsulation key is 1,184 bytes, the ciphertext is 1,088 bytes, and the shared secret is 32 bytes.
X25519 is elliptic-curve Diffie-Hellman. Each side sends a 32-byte public value, both sides compute the same 32-byte shared secret, and a sufficiently large quantum computer running Shor’s algorithm would recover it.
A hybrid handshake performs both operations and feeds both secrets into a key derivation function, or KDF, which is the hash-based construction that turns input secrets into keying material of whatever length the protocol needs. TLS 1.3 uses HKDF for this, and the hybrid change is smaller than people expect: instead of one 32-byte secret entering the key schedule, 64 bytes enter it.
The security property that makes this worth doing is called a secure combiner. Informally, the derived key stays secret as long as at least one of the two input secrets stays secret. An attacker who breaks X25519 but not ML-KEM learns nothing. An attacker who breaks ML-KEM but not X25519 also learns nothing. To read the session, they need both.
Two details in that construction do the real work, and both are easy to get wrong in a home-grown implementation.
The first is concatenation rather than XOR. The TLS specification for hybrid groups concatenates the two shared secrets in a fixed order and feeds the result into the key schedule. Order is part of the wire format, on both the key shares and the secrets, so two implementations that disagree about it produce different keys and the handshake fails.
The second is transcript binding. The concatenated secret does not go into the KDF alone. It goes in alongside a running hash of every handshake message exchanged so far, which is what prevents an attacker from tampering with one component’s key share without invalidating the finished message. Hybrid without transcript binding is two algorithms with a gap between them, and the gap is where the attack goes.
The arithmetic on the wire
Apologies in advance, the next few paragraphs are arithmetic, but this is the part that shows up in your packet captures.
Under classical X25519 alone, each side sends a 32-byte key share. Under the X25519MLKEM768 hybrid group, the client sends the ML-KEM encapsulation key plus the X25519 public value, which is 1,184 plus 32, or 1,216 bytes. The server replies with the ML-KEM ciphertext plus its X25519 value, which is 1,088 plus 32, or 1,120 bytes.
That is roughly 1.2 KB added to the ClientHello, and it’s commonly enough to push the message past a single 1,500-byte Ethernet frame. ML-KEM is fast, faster than X25519 on most hardware, so the CPU cost is noise, but the message that typically fit in one packet now spans two, and any middlebox that quietly assumed otherwise will show you exactly what it assumed.
What hybrid does not fix
The combiner protects against one specific thing, which is the failure of one of the two key establishment algorithms. It does nothing about a weak random number generator, because both halves draw from the same entropy source. It does nothing about a compromised endpoint, since the session key is in memory either way. It does nothing about an implementation that derives keys correctly and then logs them. And it does nothing about long-term authentication, because the handshake signature is still whatever your certificate says it is, which for almost everyone in production today still means RSA or ECDSA.
Put the other way: a hybrid key exchange under a classical certificate protects session confidentiality against a future quantum adversary but not session authenticity against a present-day one. Those are separate problems with separate timelines, which is the subject of the next two sections.
Why the construction exists
Two distinct risks drove the design, and they pull in opposite directions.
The first is retroactive decryption, usually called harvest now, decrypt later. An adversary with storage and patience can record encrypted traffic today and decrypt it whenever a cryptographically relevant quantum computer becomes available. The exposure window for any given session is not the session length, it’s the confidentiality lifetime of what was inside it. A ten-year patent filing sent over TLS in 2026 is still sensitive in 2036. This argues for deploying post-quantum key establishment immediately, ahead of any confidence that the deadline is close.
The second risk points the other way. The post-quantum algorithms are young, and young cryptography sometimes breaks. In July 2022, Wouter Castryck and Thomas Decru published a key recovery attack against SIDH, the mathematics underlying the SIKE key encapsulation mechanism, which at that point had reached the fourth round of the NIST selection process. Their attack ran on a single core and finished in about an hour. SIKE was not a fringe submission. It had been through years of public review, and it had been deployed in one of Google and Cloudflare’s early hybrid TLS experiments, where the classical half of the hybrid is precisely what kept those connections safe when the post-quantum half fell over.
The lattice schemes behind ML-KEM and ML-DSA have had far more cryptanalytic attention than SIDH ever did, and nobody serious expects a repeat. But “nobody serious expects it” is not a security argument, and the cost of the insurance is about 1.2 KB and a few microseconds.
There’s a third reason that gets less airtime and is arguably the most practical of the three. Hybrid gives you a deployment path with no flag day. A hybrid group is negotiated like any other group, so a client that supports it and a server that does not will simply fall back to classical, and the connection still works. You can turn hybrid on across a fleet incrementally, watch what breaks, and turn it off again. A pure post-quantum cutover has none of that.
The asymmetry between encryption and signatures
Most treatments of hybrid cryptography hand encryption and signatures the same argument. They shouldn’t, because the threat model is genuinely different.
For key establishment, the risk is retroactive. Traffic captured today can be broken later, so the migration deadline is set by the confidentiality lifetime of your data minus the time until a quantum computer exists. If you handle anything with a fifteen-year sensitivity horizon, that arithmetic is already uncomfortable.
For signatures, the risk is not retroactive in the same way. An adversary with a quantum computer in 2035 cannot go back and forge a software update that was distributed in 2026, because forging it in 2035 doesn’t put it into the 2026 update channel. What they can do is forge signatures from 2035 onward, using any key that’s still trusted at that point.
So the signature deadline is set by something else entirely: the lifetime of your trust anchors and the update horizon of your verifiers. A root certificate authority key with a twenty-five year validity period needs to be quantum-resistant now. A device that will sit in a substation until 2045, verifying firmware against a key burned into it at manufacture, needs a quantum-resistant verification path burned in with it. A TLS server certificate with a 90-day lifetime does not have the same urgency, and treating it as though it does will consume budget that belongs elsewhere.
That reordering changes what hybrid is for on the signature side, where it works as a compatibility mechanism, letting you put a post-quantum key in front of verifiers that don’t understand it yet, rather than as insurance against retroactive attack.
Two signatures on one object
There are two standard ways to attach a classical and a post-quantum signature to the same artefact, and they differ in a way that has operational consequences.
Dual signatures keep the two independent. In X.509, the post-quantum public key and the post-quantum signature are placed in certificate extensions marked non-critical, which is the X.509 mechanism for “ignore this if you don’t recognise it”. A legacy verifier validates the RSA or ECDSA signature and ignores the extensions. An upgraded verifier validates the post-quantum signature as well. Both succeed, which is exactly the point, and also the weakness: if the post-quantum half is stripped in transit, the legacy verifier still says yes and nothing in the protocol notices.
Composite signatures bind the two together. The pair verifies as a single unit, and if either component fails, the whole verification fails. This gives you the strong guarantee that an attacker must break both, with no strip-down path, and it costs you backward compatibility, because a verifier that doesn’t know the composite algorithm identifier cannot validate anything at all. IETF working groups have been standardising composite constructions around ML-DSA for exactly this reason, and the choice between the two forms is essentially a choice about whether your verifier population is under your control.
The size arithmetic
ML-DSA is the post-quantum signature scheme standardised as FIPS 204. At the ML-DSA-65 parameter set, the public key is 1,952 bytes and the signature is 3,293 bytes. Compare that with roughly 32 bytes and 64 bytes for Ed25519.
Now price a chain. Take a leaf certificate and one intermediate, and give each of them both a post-quantum public key and a post-quantum signature from its issuer. That’s about 5,245 additional bytes per certificate, or about 10.5 KB for a leaf plus one intermediate, added to the chain the server sends during the handshake. TLS servers commonly start with an initial congestion window of ten packets, which is roughly 14 KB, so a chain that used to arrive comfortably inside the first flight now competes for that space and can add a round trip on high-latency links.
SLH-DSA, the hash-based scheme standardised as FIPS 205, is the fallback whose security rests only on hash functions rather than on lattice assumptions. Its signatures run from roughly 7.8 KB at the smallest parameter set to about 49 KB at the largest. That size profile puts it outside general web PKI and squarely into places where a signature is verified rarely and trusted for a very long time, which is a real category.
Firmware and software signing
For code and firmware, the mature quantum-resistant options predate the FIPS 203 to 205 family. NIST SP 800-208 specifies LMS and XMSS, which are stateful hash-based signature schemes. Stateful means each private key can produce only a fixed number of signatures, and the signer must record which one-time keys have been consumed. Reusing one destroys the security of the scheme, so if you sign from a hardware security module, that state must live somewhere that cannot be rolled back by a snapshot restore or a failover. This is an operations problem more than a cryptography problem, and it’s the reason LMS deployments tend to be run by small, careful teams.
The hybrid pattern here is straightforward. Sign the artefact with the classical signature that your installed base already checks, and with a quantum-resistant signature that newer verifiers prefer. Distribute both. Retire the classical one when the last verifier that needs it is out of the field, which for industrial equipment may be a very long time from now.
What breaks first in production
Across early hybrid deployments, the failures cluster in a small number of places, and almost none of them are cryptographic.
Packet size assumptions. This is the big one. The larger ClientHello and the larger certificate chain expose middleboxes, load balancers, and DPI appliances that were written against the sizes typical in 2015. The failure mode is often not a clean error but a hang, because the device drops the second segment and both endpoints wait.
UDP-based protocols. IKEv2, the key management protocol behind IPsec VPNs, could not fit post-quantum key shares into its original message structure. Two RFCs fixed this. RFC 9242 adds an IKE_INTERMEDIATE exchange that can carry large payloads before the main handshake completes, and RFC 9370 extends IKEv2 to perform multiple key exchanges in sequence, which is the hybrid mechanism. RFC 8784 offers an older and cruder option, mixing a long pre-shared key into the derivation, and it’s still useful where you control both endpoints and cannot upgrade the algorithm negotiation.
Hardware security modules. An HSM is the tamper-resistant device that holds private keys and performs operations on them. Post-quantum algorithm support requires vendor firmware, certification of that firmware takes time, and key sizes and object formats change. If your signing keys live in an HSM, the vendor’s roadmap is your roadmap, and finding that out early is cheaper than finding it out during the migration.
Constrained devices. ML-KEM’s compute cost is modest, but its memory footprint is not trivial for microcontrollers with tens of kilobytes of RAM. The buffer that used to hold a 32-byte key share now holds 1,184 bytes, and embedded stacks with statically sized buffers fail in ways that are unpleasant to debug in the field.
Vendor claims. A blunt observation about the market: “quantum-safe” on a datasheet means nothing on its own. Ask which algorithm, at which parameter set, in which protocol position, and whether it’s negotiated or hard-coded. A product that has added ML-KEM to its key exchange and still signs with RSA-2048 is quantum-safe in one dimension and not in the other, and both facts belong in the datasheet.
Verifying that hybrid is actually on
Configuration is not deployment. Check the wire.
Confirm the negotiated group by name. For TLS, openssl s_client -connect host:443 reports the negotiated group in its output. You are looking for the hybrid group name, not for the presence of TLS 1.3, which tells you nothing about the key exchange. For SSH, ssh -v prints the negotiated key exchange algorithm; OpenSSH has defaulted to a hybrid group since version 9.0 in April 2022, pairing X25519 with NTRU Prime at the sntrup761 parameter set.
Confirm the fallback path. Point a client that does not support the hybrid group at the same endpoint and check that it connects. If it doesn’t, you have not deployed hybrid, you’ve deployed an outage with a delay fuse.
Measure the handshake, not the throughput. The cost of hybrid lands almost entirely in connection establishment. Compare handshake completion time and first-flight packet counts, and do it from a client on a genuinely lossy path rather than from the next rack over.
Check what your monitoring can see. If your telemetry does not record the negotiated group per connection, you cannot tell how much of your traffic is protected, and you cannot detect a regression when someone rolls back a load balancer configuration.
Test the removal. Turn the classical half off in a staging environment and see what happens. Whether or not you intend to run pure post-quantum any time soon, the exercise tells you how much of your estate is genuinely agile and how much is welded shut.
Designing for the removal
Hybrid is scaffolding, and scaffolding that never comes down becomes part of the building. Every hybrid deployment carries a permanent maintenance cost: two algorithms to patch, two sets of parameters to review, two failure modes to reason about, and a downgrade path that has to be watched forever.
NSA’s CNSA 2.0 suite sets 2035 as the end date for the National Security Systems transition, and its position on hybrid is that it’s permitted for interoperability rather than required for compliance. The direction of travel is toward single-algorithm post-quantum implementations, with hybrid as the bridge. NIST’s guidance on key encapsulation mechanisms in SP 800-227 addresses how to combine KEM outputs safely, which is the standards-level version of the transcript binding point from earlier in this article. NIST also selected HQC in 2025 as a code-based backup KEM, on the reasoning that a second mathematical foundation is worth having if lattices ever disappoint, with a draft standard expected in 2026.
The deliverable that survives all of this is crypto-agility, which means the ability to change cryptographic algorithms without changing application code. In practice that comes down to a small number of unglamorous things. Algorithms referenced by identifier rather than hard-coded. Key material sized dynamically rather than by fixed buffer. Cryptographic operations behind a service or library boundary rather than inlined. And an inventory that records which system uses which algorithm for which purpose, because the organisations that struggle most with this migration are not the ones with hard cryptography problems, they’re the ones that cannot answer the question of where their keys are.
Build the hybrid deployment so that removing the classical half is a configuration change. If it’s a code change, you’ll be running hybrid in 2040.
Where to go next
The mechanics above are testable this week. Enable a hybrid group on a staging endpoint, capture the handshake, count the bytes, and see which piece of your infrastructure objects first. That exercise generates a better migration plan than any document.
For the wider migration methodology this fits into, including inventory and prioritisation, see pqcframework.org. For deeper technical background on hybrid deployments across protocols, see the extended treatment on PostQuantum.com.
If you’d rather work through it with structure and assessment, Quantum Academy’s post-quantum cryptography training covers hybrid key establishment, certificate handling, and migration planning as a sequence rather than a set of disconnected facts. Current programs are listed at quantumacademy.com/.