What Is Hybrid Cryptography?
Hybrid cryptography, in the post-quantum context, refers to cryptographic schemes that combine a classical algorithm and a post-quantum algorithm in a single operation, with security guaranteed as long as either algorithm remains unbroken. A hybrid key encapsulation mechanism runs both ECDH and ML-KEM in parallel during a TLS handshake and combines their outputs using a key derivation function. An adversary must break both ECDH and ML-KEM simultaneously to recover the session key breaking one algorithm alone is insufficient.
Hybrid schemes are distinct from algorithm fallback mechanisms. A fallback allows one algorithm to be used if the other fails; a hybrid requires both to succeed and uses both outputs to derive the final key material. The security of a hybrid scheme is at least as strong as its strongest component: if ML-KEM is unbroken, the hybrid is secure, regardless of what happens to ECDH; if ECDH is unbroken, the hybrid is secure regardless of what happens to ML-KEM. This bidirectional security guarantee is what makes hybrid cryptography the recommended transition strategy.
Why Hybrid Is the Recommended Transition Strategy
Hybrid cryptography resolves the tension between two legitimate concerns during the PQC transition. The first concern is that ML-KEM and ML-DSA, despite extensive analysis, are relatively new algorithms compared to decades of classical cryptanalysis. Deploying pure post-quantum algorithms removes the protection of classical algorithms whose security has been validated over a much longer period. The second concern is that maintaining classical-only key exchange creates ongoing HNDL exposure. Hybrid schemes address both concerns simultaneously: they provide HNDL protection through the post-quantum component while maintaining classical security as a backstop.
NSA CNSA 2.0, published in September 2022, endorses hybrid deployment as an acceptable interim measure for National Security Systems during the migration period. NIST SP 1800-38 recommends hybrid deployment for organizations in the initial phases of PQC migration. The IETF PQUIP working group's analysis of hybrid schemes has produced several specifications for integrating hybrid key exchange into widely deployed internet protocols. The broad endorsement of hybrid deployment from NIST, NSA, CISA, and IETF reflects the conclusion that hybrid provides a pragmatic and secure transition path.
“Hybrid key establishment combines a classical key establishment algorithm (such as ECDH) with a post-quantum key encapsulation mechanism (such as ML-KEM) to protect against both classical and quantum-computing-based attacks during the transition period.”
How Hybrid Key Establishment Works
In a hybrid key establishment scheme, both the classical algorithm (typically ECDH with X25519 or P-256) and the post-quantum algorithm (ML-KEM) run in parallel during the protocol handshake. The classical algorithm produces a classical shared secret; ML-KEM produces a post-quantum shared secret (via encapsulation/decapsulation). Both shared secrets are combined using a key derivation function (KDF) typically HKDF to produce the final session keys. Neither shared secret alone is used directly; the final key material is derived from both.
The KDF combination step is security-critical. A naive concatenation of the two shared secrets and passing them to the KDF is generally secure, but the specific combiner design matters for formal security analysis. The IETF draft-ietf-tls-hybrid-design specification provides detailed guidance on the KDF construction for TLS hybrid key exchange. For TLS 1.3, hybrid key exchange is implemented using named group extensions a hybrid named group such as 'X25519MLKEM768' identifies a combined ECDH-X25519 plus ML-KEM-768 key exchange, and both parties must support the named group to use it.
How Hybrid Digital Signatures Work
Hybrid digital signature schemes produce a combined signature consisting of both a classical signature (ECDSA or RSA) and a post-quantum signature (ML-DSA or SLH-DSA) over the same message. Verification requires both signatures to be valid for the message. An adversary who can forge only one signature type using either quantum-enabled classical algorithm attacks or classical cryptanalysis of the post-quantum algorithm cannot produce a hybrid signature that passes verification. Both signature types must be valid simultaneously.
The IETF LAMPS (Limited Additional Mechanisms for PKIX and SMIME) working group has developed specifications for composite digital signatures in X.509 certificates and other PKI contexts. A composite certificate contains both a classical public key and a post-quantum public key, and is signed with both a classical signature and a post-quantum signature. Verification requires checking both. This allows hybrid certificates to be issued now and used in environments that support composite verification, while classical-only environments can verify only the classical signature component if a separation mechanism is used.
Security Properties of Hybrid Schemes
The core security property of hybrid schemes is IND-CCA2 security (indistinguishability under chosen ciphertext attack) for hybrid KEMs, assuming either the classical component or the post-quantum component provides IND-CCA2 security. For hybrid signatures, the analogous property is existential unforgeability under chosen message attack (EUF-CMA), assuming either component signature scheme provides EUF-CMA security. These properties mean hybrid schemes inherit the security of their strongest component rather than their weakest.
A subtlety is that the security proofs for hybrid schemes depend on the KDF combining the two shared secrets behaving as a secure combiner. The IETF draft-ietf-tls-hybrid-design specification provides a combiner design for TLS hybrid key exchange that satisfies the required security properties under standard assumptions about HKDF. Organizations implementing hybrid key exchange outside of TLS should consult the relevant specification or have the combiner design reviewed by a cryptographer to ensure it preserves the hybrid security properties.
Standards and Specifications for Hybrid Cryptography
Several IETF working groups are developing specifications for hybrid cryptography in standard protocols. The PQUIP working group provides guidance on post-quantum use in protocols and has published analysis of hybrid scheme requirements. The TLS working group, through draft-ietf-tls-hybrid-design, specifies how hybrid key exchange is integrated into TLS 1.3. The LAMPS working group is developing composite signature specifications for X.509 and S/MIME. The SSH working group has developed hybrid key exchange specifications for SSH.
IETF RFC 9180 (Hybrid Public Key Encryption, HPKE) defines a framework for public key encryption that supports algorithm agility and serves as a basis for post-quantum and hybrid encryption in application protocols. While HPKE itself is not a hybrid KEM in the post-quantum sense, it provides a well-analyzed framework that post-quantum and hybrid encryption schemes can build on. The combination of these IETF specifications provides a comprehensive standards foundation for hybrid cryptography deployment across the major protocol contexts where post-quantum migration is needed.
“This document defines a standard framework for hybrid key exchange, combining classical and post-quantum key exchange mechanisms in TLS 1.3, to provide security against both classical and quantum adversaries during the cryptographic transition period.”
Hybrid Key Establishment in TLS 1.3
TLS 1.3 integrates hybrid key exchange through named group extensions. Hybrid named groups such as X25519MLKEM768 (combining ECDH with X25519 and ML-KEM-768) are registered in the IANA TLS Named Groups Registry and negotiate through the standard TLS ClientHello supported_groups extension. A TLS client supporting hybrid key exchange includes hybrid named groups in its supported_groups list; a server that supports the same hybrid group will accept it and use it for key exchange.
Major TLS libraries have added hybrid TLS support. BoringSSL (used by Chromium, Android, and Google services) has shipped hybrid X25519Kyber768 support in production since 2023 and updated to FIPS 203 ML-KEM. OpenSSL 3.x with OQS provider supports hybrid TLS configurations. Rustls and the Go standard library have post-quantum extensions in development or available through community crates. Cloud providers AWS, Google Cloud, Cloudflare have deployed hybrid TLS on their endpoints. Server-side hybrid TLS deployment is immediately achievable for most organizations with current TLS library support.
KEM Combiners and Key Derivation
The security of hybrid KEM schemes depends critically on how the classical and post-quantum shared secrets are combined. A secure KEM combiner takes both shared secrets and produces a single combined secret that is indistinguishable from random as long as either input is secure. HKDF (HMAC-based Key Derivation Function, IETF RFC 5869) is commonly used as the combiner, with the two shared secrets provided as input key material along with context labels that bind the combined secret to the protocol context.
A common KEM combiner construction uses HKDF-Extract to combine both shared secrets with a protocol-specific salt, then HKDF-Expand to produce the final keying material. The specific construction in TLS 1.3 hybrid key exchange is defined in draft-ietf-tls-hybrid-design. For application-level implementations outside of TLS, HPKE (RFC 9180) provides a well-analyzed alternative that supports multiple KEM algorithms and can be used to implement hybrid encryption at the application layer with proper key derivation.
Size and Performance Trade-offs
Hybrid key establishment increases TLS handshake message sizes because both the classical key material and the ML-KEM key material must be transmitted. For X25519MLKEM768, the ClientHello key share increases from 32 bytes (X25519 alone) to approximately 1,216 bytes (32 bytes for X25519 plus 1,184 bytes for ML-KEM-768 public key). The ServerHello key share increases by the ML-KEM ciphertext size (1,088 bytes). Total additional handshake data is approximately 2,270 bytes per TLS connection establishment.
For most modern network environments, this size increase is not operationally significant. TLS session establishment is already a multiple round-trip process with cryptographic computation overhead; adding 2KB of additional key material has negligible impact on connection latency in typical conditions. Environments with severe bandwidth constraints IoT devices on low-bandwidth connections, or mobile devices on congested networks may see more noticeable impact and may prefer ML-KEM-512 hybrid (smaller parameter set) to reduce the overhead.
Dual Certificates in PKI
A dual-certificate approach issues each server or entity two separate certificates: one using classical algorithms (ECDSA or RSA) for compatibility with clients that do not support post-quantum certificates, and one using post-quantum algorithms (ML-DSA or composite) for clients that do. The server presents the appropriate certificate based on what the client advertises in the TLS handshake. This approach allows PKI migration to proceed without breaking existing clients, while new clients benefit from post-quantum certificate authentication.
Dual certificates increase the certificate management burden each entity now has two certificates to issue, renew, and revoke but this is operationally manageable with modern certificate lifecycle management platforms. ETSI TS 119 312 provides a framework for managing cryptographic suites in electronic signature infrastructure that can accommodate dual-certificate approaches. The dual-certificate strategy is expected to remain in use through the transition period until post-quantum certificate support is sufficiently widespread to retire classical certificates.
When to Deploy Hybrid vs. Pure PQC
Hybrid deployment is the recommended approach during the transition period for most production systems, because it provides HNDL protection while maintaining classical security as a backstop. Pure post-quantum deployment using ML-KEM or ML-DSA alone without classical algorithms is appropriate in two scenarios. First, in environments where all communicating parties are known to have migrated to post-quantum-capable implementations and backward compatibility with classical clients is not required. Second, in resource-constrained environments where the size overhead of hybrid schemes is prohibitive.
CNSA 2.0 requires that National Security Systems ultimately adopt pure CNSA 2.0 algorithms without classical algorithm fallback by 2033. The 2033 date is a deadline for pure post-quantum operation; hybrid operation is acceptable as an interim measure during migration. For commercial organizations not subject to CNSA 2.0, maintaining hybrid operation indefinitely is acceptable hybrid provides strong security under the assumptions that either algorithm remains unbroken, and the additional operational overhead of hybrid schemes is modest.
Implementation Pitfalls to Avoid
Several implementation mistakes undermine hybrid scheme security. Using pre-standardization algorithm parameter sets (e.g., Kyber768 rather than ML-KEM-768 per FIPS 203) creates interoperability problems and may not match the security analysis of the finalized standard. Implementing a custom KEM combiner without cryptographic review risks creating a scheme that does not preserve the hybrid security properties, potentially allowing an adversary to recover the combined key by attacking only one component. Using the classical shared secret as a key directly and XORing it with the post-quantum secret, rather than using a proper KDF, is a common implementation error that weakens the combiner.
For signature hybrid schemes, separately transmitting a classical signature and a post-quantum signature without a binding mechanism allows an adversary to strip one signature type and present only the other defeating the hybrid security goal. The IETF LAMPS composite signature specifications include binding mechanisms that prevent this attack. Organizations implementing hybrid schemes should use well-reviewed libraries and follow published specifications rather than implementing custom combiners, and should have any novel constructions reviewed by a cryptographer before production deployment.
References
- [1]NISTNIST FIPS 203(2024)Module-Lattice-Based Key-Encapsulation Mechanism Standard (ML-KEM)
- [2]NISTNIST FIPS 204(2024)Module-Lattice-Based Digital Signature Standard (ML-DSA)
- [3]
- [4]NSANSA CNSA 2.0(2022)Commercial National Security Algorithm Suite 2.0
- [5]CISACISA/NSA/NIST Joint Guidance(2023)Quantum-Readiness: Migration to Post-Quantum Cryptography
- [6]IETFIETF draft-ietf-tls-hybrid-design(2024)Hybrid key exchange in TLS 1.3
- [7]IETFIETF RFC 9180(2022)Hybrid Public Key Encryption (HPKE)
- [8]IETFIETF PQUIP WG(2022)Post-Quantum Use In Protocols Working Group
Related Guides
Complete Guide to Post-Quantum Cryptography
A comprehensive reference covering why classical public-key cryptography is being replaced, the NIST-standardized algorithms (ML-KEM, ML-DSA, SLH-DSA), the harvest-now decrypt-later threat, and how to plan and execute a cryptographic migration program.
What Is Harvest Now Decrypt Later?
Harvest-now, decrypt-later (HNDL) is the most immediate cryptographic risk requiring action before quantum computers exist at scale. This guide explains how HNDL attacks work, what data is most exposed, and why cryptographic migration cannot wait.
ML-KEM Explained
ML-KEM (NIST FIPS 203) is the primary post-quantum key encapsulation mechanism, replacing RSA and ECDH in TLS, VPNs, and SSH. This guide explains how it works, its parameter sets, hybrid deployment, and migration from ECDH.