Hybrid Cryptography: What It Is and How to Implement It

Hybrid cryptography is an often-recommended approach to quantum migration but requires careful design and implementation

In several jurisdictions, hybrid cryptography is recommended as a transitional step during quantum migration. Its goal is to manage exposure to two types of cryptographic risk, ensuring that an attacker will need to be able to break both a classical and post-quantum algorithm to access encrypted data or forge a digital signature.

Official policies on hybrid cryptography are mixed since the protocol introduces additional complexity and overhead in exchange for reduced risk. Organizations need to be familiar with local recommendations as well as how to implement compatible and secure hybrid algorithms.

The Pros and Cons of Hybrid Cryptography

Hybrid key establishment algorithms involve the creation of two shared secrets that are combined via a key derivation function (KDF). Hybrid signature schemes can either be implemented as a composite signature (one signature, two components to verify) or parallel signature (two independent signatures).

Hybrid cryptography is recommended by Germany's BSI and France's ANSSI because it helps to reduce the risk of a classical algorithm being broken by a quantum computer or a post-quantum algorithm containing flaws that render it insecure (like Rainbow or SIKE).

However, the US's NSA does not require hybrid cryptography, Australia's ASD does not recommend (but does not prohibit) it, and the UK's NCSC accepts it only as an interim measure. Hybrid protocols have several disadvantages, including additional complexity and generally larger key and signature lengths. Hybrid also adds complexity to quantum migration since it is, at best, a temporary stage. Once cryptographically relevant quantum computers (CRQCs) become available, the classical component will no longer protect against quantum attackers.

Hybrid Key Establishment in Practice

Hybrid cryptography isn't theoretical, and, by April 2026, an estimated two-thirds of human-generated TLS traffic to Cloudflare's network already used hybrid key exchange. Chrome, Firefox, OpenSSL, and OpenSSH have enabled hybrid key exchange by default, and RFCs 9954 and 10024 (published in July and August 2026) later standardized it for use in TLS.

When implementing hybrid cryptography, the combiner is critical to achieving the security benefits of the overall scheme. An insecure combiner can mean that breaking just one component is enough to recover the key, which defeats the purpose of hybrid cryptography. NIST SP 800-227 and SP 800-56C Rev. 2 detail approved, standardized combiner algorithms for hybrid key establishment.

Hybrid Signatures and Certificates

The main driver of PQC adoption today for key establishment is harvest now, decrypt later (HNDL) attacks. An attacker who collects encrypted data today can decrypt it in the future when CRQCs become available, which is why Chrome and other software are moving so quickly on this threat.

Trust now, forge later (TNFL) attacks are the signature counterpart of HNDL. An attacker who can forge signatures once CRQCs exist can attack long-lived signed artifacts that are trusted today, such as firmware. Real-time authentication, like the signature in a TLS handshake, is only exposed once a CRQC actually exists. As a result, hybrid signatures in TLS are less urgent than hybrid key exchange, although Google announced in March 2026 that it had adjusted its threat model to prioritize PQC migration for authentication services, targeting a 2029 migration.

Work is being done to create and standardize hybrid signature schemes. For example, the IETF's composite ML-DSA specification for X.509 certificates has been approved and is in the RFC Editor queue. Once such schemes are available, they should be applied to long-lived signatures first, such as firmware, code signing, and root CAs.

Supporting Hybrid Cryptography in a Crypto API

The use of a crypto API is essential for crypto-agility since it allows algorithms and configurations to be swapped as needed without extensive rewrites. In the case of hybrid cryptography, it's especially important since hybrid schemes may later need to be reconfigured or replaced with pure PQC.

In a crypto API, hybrid algorithms should be first-class algorithms selected explicitly via corporate policy. All of the cryptographic code, including the combiner, should be implemented within the API and transparent to the caller. Best practices include:

Explicitly requiring verification of all components for digital signatures (for example, CVE-2026-5588, where a Bouncy Castle composite signature verifier accepted an empty signature)
Resistance to downgrade attacks
Fail secure for unknown combinations
Config-level retirement path for classical components

Implementing Hybrid Cryptography

Hybrid cryptography introduces additional complexity when compared to pure PQC. As a result, additional testing is required to ensure that everything works properly.

A full test regimen for hybrid cryptography includes:

Known answer testing
Interoperability testing across stacks
Negative tests verifying that breaking one component causes composite algorithms to fail
Side channel testing (for example, CVE-2026-5598, a side-channel vulnerability in a FrodoKEM implementation)
Network testing for packet fragmentation and middlebox support
Monitoring the share of connections that successfully negotiate hybrid cryptography

Once the crypto API is complete and tested, the CBOM can be used to identify locations where data is especially exposed to HNDL attacks. These areas can be used for initial pilots before a full-scale rollout. For TLS, hybrid key exchange is usually enabled through the TLS library's built-in groups, so a pilot doesn't need to wait for a custom crypto API.

Common Mistakes when Implementing Hybrid Cryptography

Hybrid cryptography can be difficult to implement correctly since it involves deploying two standardized algorithms and a combiner rather than a single, integrated algorithm. Some common mistakes include:

Using a homemade combiner
Hardcoding X25519MLKEM768 as the selected hybrid algorithm
Allowing silent fallback to classical algorithms
Building using draft identifiers for hybrid schemes
Deploying hybrid everywhere without checking local guidance
Not creating a retirement plan for hybrid algorithms

FAQs

Is hybrid required?

Hybrid cryptography isn't required, and, in some jurisdictions, isn't even recommended. Its purpose is to limit the potential risks associated with a transition to PQC algorithms that might prove to be insecure.

If we're deploying ML-KEM, can we skip the classical half?

Yes, but it might not be a good idea. While the strongest relevant guidance is "recommending" its use (ANSSI and BSI), it can provide some benefits for cryptographic risk management. Best practice is to check the guidance in your jurisdiction and act accordingly.

Does hybrid double the performance cost?

No, the majority of the performance cost for hybrid cryptography comes from the PQC component, which is required regardless for a quantum migration. Adding a combiner and a classical component doesn't double the compute, storage, or latency.

What if one half is broken?

Hybrid cryptography is designed to be secure if one half (PQC or classical crypto) is broken. It's only fully insecure if both components are broken or an insecure combiner or fallback allows an attacker to force the use of only the insecure component.

Do we need hybrid signatures now?

Trust now, forge later (TNFL) attacks are only relevant if a digital signature generated today will still be relevant and trusted when Q-Day comes. While this may be true in certain cases, like firmware in long-lived systems, most common use cases, like authentication, are less urgent than key exchange, although Google has prioritized authentication services in its 2029 migration timeline.