Hybrid modes and keeping your rollback

Hybrid cryptography is what you use when you are confident about the direction of travel and not yet confident about the destination. It combines an established classical algorithm with a post-quantum one, so that a weakness in either alone does not break the channel. It costs bandwidth, some CPU and some operational complexity. During a transition, that is usually the correct trade.

This article covers what hybrid actually means, what it costs, how to handle peers who have not moved, and the part that gets skipped most often: designing so you can go back.

#What hybrid key establishment actually is

In a hybrid key establishment, both parties run two key exchanges in the same handshake. One is classical, typically elliptic-curve Diffie-Hellman. One is post-quantum, typically ML-KEM as standardised in NIST FIPS 203. The two resulting shared secrets are then combined through a key-derivation function to produce the session keys.

The property that matters is the combination. An attacker who breaks only the elliptic-curve component still does not learn the session key, because the ML-KEM secret is also an input. An attacker who finds a structural weakness in the lattice problem underlying ML-KEM is in the same position with respect to the classical secret. You are protected as long as at least one component holds, which is a materially different bet from trusting either one alone.

Classical component

Elliptic-curve Diffie-Hellman. Decades of public cryptanalysis, and broken by a sufficiently large quantum computer.

Post-quantum component

ML-KEM, standardised in NIST FIPS 203. Believed quantum-resistant, and comparatively young.

Combination

Both secrets feed a key-derivation function; the session key holds if either component holds.

What it does not cover

Authentication. Hybrid key establishment says nothing about the signature algorithm in your certificates.

#Why hybrid is the sane default during transition

The argument for hybrid is not sentimental attachment to elliptic curves. It is an honest statement about the age of the evidence. The classical algorithms have absorbed decades of public cryptanalysis, and we know in detail how they fail. ML-KEM has been standardised and heavily reviewed, but its underlying assumptions have had less time under adversarial attention than the ones it replaces. Running both means a surprise on either side is survivable.

There is a second, more practical argument. Hybrid is a superset, so it degrades gracefully. A hybrid-capable endpoint can still negotiate a classical channel with a peer that has not moved, which means you can deploy it broadly without coordinating a flag day across every counterparty you have. A pure post-quantum deployment requires exactly that coordination.

Published guidance is not uniform on this point. Some national schemes expect hybrid during transition. Others, including the NSA’s CNSA 2.0 direction for national security systems, are comfortable with post-quantum algorithms used on their own. Which applies to you is a compliance question before it is an engineering one. See CNSA 2.0 and the federal timeline.

#What hybrid costs

Hybrid is not free, and the cost is mostly in bytes rather than cycles. ML-KEM public keys and ciphertexts are roughly a kilobyte in scale, where an elliptic-curve public value is a few dozen bytes. A hybrid handshake carries both. That changes the shape of connection setup in ways raw throughput benchmarks do not capture.

We deliberately do not publish generic latency or size numbers here. They depend on parameter set, library, hardware, network path and load, and a figure from someone else’s test bench is not evidence about your system. Measure it. Proving the performance impact sets out how.

#Dual signatures and dual certificates

On the authentication side, the equivalent idea is to present both a classical and a post-quantum signature, so a verifier can accept whichever it understands and a stricter verifier can require both. Two broad approaches exist. You can issue two separate certificate chains and select between them during negotiation, or you can carry both signatures inside a composite structure that older verifiers ignore.

Neither is comfortable yet. Dual chains double issuance and renewal work and push selection logic into the negotiation layer, where it is easy to get subtly wrong. Composite structures keep issuance simpler but depend on verifiers tolerating fields they do not recognise, and legacy verifiers frequently do not. Both inflate chain size, which matters because ML-DSA signatures under FIPS 204 are considerably larger than ECDSA signatures.

• Dual chains give clean separation and easy rollback, at the cost of doubled PKI operations.
• Composite certificates reduce operational duplication but depend on verifier tolerance you must test rather than assume.
• Verifier inventory first. Before choosing, enumerate every verifier, including embedded devices and pinned clients you cannot update.
• Code signing is the hard case. Artefacts signed today may be verified for a decade by software you will never patch.

#Negotiating with peers who have not moved

Most estates will spend years talking to counterparties at different stages of migration. The way to survive that is to offer hybrid, keep classical as an accepted fallback, and instrument which one every connection actually used. Without that telemetry you cannot tell the difference between a successful rollout and a rollout that is silently falling back on every connection.

Then decide, deliberately and in writing, when fallback stops being acceptable for each class of channel. That decision belongs to the data owner, because it is a confidentiality decision rather than a networking one. A channel carrying data with a fifteen-year secrecy requirement should stop accepting classical-only negotiation long before an internal metrics feed does.

#Designing so you can go back

Every cryptographic change should ship with a tested way back. Not because ML-KEM is expected to fail, but because the surrounding machinery fails routinely: appliances, libraries, size assumptions, monitoring. A rollback you have never executed is a hypothesis.

1. 1

   Make the algorithm a runtime setting

   Algorithm selection should be configuration you can change without recompiling or redeploying. If reverting requires a build, your rollback time is a release cycle, and during an incident that is too slow.

2. 2

   Roll forward in observable increments

   Move a percentage of traffic, a region, or a single service at a time. Increments limit exposure and, more usefully, produce a clear signal about which increment caused a regression.

3. 3

   Define the abort condition before you start

   Write down the thresholds that trigger a revert: tail latency beyond a stated bound, handshake failure rate above a stated share, or any unexplained fallback pattern. Decide these in advance, because nobody negotiates thresholds well during an incident.

4. 4

   Rehearse the revert under production conditions

   Execute the rollback deliberately, on real traffic, at a quiet hour, and time it. That number is your actual recovery time. Whatever the runbook claims is not.

5. 5

   Keep the old path warm, then retire it on purpose

   Leave the classical path functional and tested for a defined window. Then remove it as an explicit decision with a date and an owner, rather than letting it linger as a permanent downgrade route an attacker can try to force.