Invalid Date

Hybrid Classical and Post-Quantum Cryptography Explained

Hybrid PQC runs two independent key exchange algorithms simultaneously so an attacker must break both. This guide covers combiner constructions, TLS standards, and the X-Wing versus Draft00 distinction.

Hybrid Classical and Post-Quantum Cryptography Explained

When security engineers talk about hybrid post-quantum cryptography, they mean a specific belt-and-braces architecture: two independent key exchange algorithms running simultaneously, such that an attacker must break both to recover the session key. If the classical algorithm holds, classical security holds. If the post-quantum algorithm holds, post-quantum security holds. Neither can be broken without breaking both. That is not twice as secure, but it is meaningfully more resilient during a period when no post-quantum algorithm carries the decades of field deployment that RSA and ECC have accumulated.

The rationale for the hybrid approach is grounded in two PQC breaks that happened in 2022. Rainbow, a multivariate signature scheme that reached the final round of the NIST standardisation competition, was broken by Ward Beullens in a classical attack that recovered the signing key over a weekend on a laptop. SIDH and SIKE, based on supersingular isogeny mathematics and a NIST alternate candidate, were broken by Wouter Castryck and Thomas Decru using a classical attack involving auxiliary elliptic curve information. Neither break used a quantum computer. Both eliminated their respective algorithms from the standardisation process. ML-KEM, the NIST-standardised post-quantum KEM from FIPS 203 (August 2024), has a fundamentally different mathematical structure, based on lattice problems, and the Rainbow and SIKE breaks do not apply to it. But ML-KEM has not had the decades of cryptanalytic scrutiny behind RSA. The hybrid design maintains classical security during the period when that confidence is still being built.

This article explains the combiner constructions that make hybrid PQC work, the protocol-level standards governing it, the critical distinction between X25519Kyber768Draft00 and X-Wing (two hybrid schemes that are frequently confused but are not interoperable), and guidance on when hybrid is necessary versus when pure PQC suffices.

What Hybrid Cryptography Is and Why It Exists

Hybrid PQC combines a classical key exchange algorithm, typically X25519 or P-256 ECDH, with a post-quantum KEM (Key Encapsulation Mechanism), typically ML-KEM from FIPS 203, such that the resulting shared secret depends on both algorithms. A KEM is a cryptographic primitive that allows a sender to encapsulate a shared secret under a recipient's public key, which the recipient decapsulates using their private key. ML-KEM (FIPS 203) is the NIST-standardised post-quantum KEM, based on the Module Learning with Errors lattice problem.

NIST SP 800-227 (Initial Public Draft, 2024), which defines recommendations for KEM usage including hybrid KEM constructions, gives the transition rationale explicitly: NIST-standardised PQC algorithms have received intensive cryptanalytic scrutiny since the competition began in 2016, but field deployment confidence accumulates over decades. The hybrid design maintains classical security during the period before that confidence is fully established. For an overview of the NIST FIPS 203 ML-KEM standard itself, see our article on NIST PQC standards for enterprise.

The 2022 breaks of Rainbow and SIKE are worth understanding in that context. They illustrate that public competition and cryptanalytic scrutiny can surface fundamental algorithm weaknesses even after years of review. The breaks are not a reason to distrust all post-quantum cryptography. ML-KEM's lattice-based structure is mathematically unrelated to multivariate systems (Rainbow) and isogeny-based systems (SIKE), and both breaks used classical, not quantum, techniques. They are, however, a reason to maintain classical security alongside PQC during the transition. That is precisely what hybrid provides.

How the Combiner Works

The KDF-over-Concatenation Combiner

The standard approach for combining two KEM outputs into a single session key is to derive the final shared secret using a key derivation function (KDF) over the concatenation of both KEM shared secrets and their ciphertexts. The construction takes the form: K = KDF(ss_classical || ss_pqc || ct_classical || ct_pqc), where ss denotes the shared secret from each KEM and ct denotes the corresponding ciphertext. NIST SP 800-227 IPD describes this structure in its section on combiner constructions, and both the IETF TLS hybrid design draft and the X-Wing specification use this structural approach.

This combiner provides security if either component KEM is secure, under the assumption that the KDF is a secure pseudorandom function and that the two component KEMs are independent. The independence requirement means they must use no shared randomness and have no correlated failure modes. The theoretical basis for this security property is established in Giacon, Heuer, and Poettering's “KEM Combiners” paper from PKC 2018, which NIST SP 800-227 IPD cites in its combiner security discussion.

Including ciphertexts in the KDF input, not just the shared secrets, protects against KEM-recombine attacks. In a KEM-recombine attack, an adversary who learns the output of one component KEM can attempt to construct a related ciphertext for the other. Binding both ciphertexts into the key derivation closes this attack vector. The IETF draft-ietf-tls-hybrid-design Appendix A, which addresses security considerations for hybrid TLS, discusses this protection specifically.

The XOR Combiner and Why It Is Vulnerable

A simpler combiner is XOR: the final key is derived as the bitwise XOR of the two component shared secrets. This construction is attractive for its simplicity and is sometimes proposed in informal discussions. It is not safe. If an attacker recovers one component shared secret, say by breaking the classical ECDH component using a large quantum computer, they can recover the full combined key by XOR with the known value. The linearity of XOR means the combined key provides no security beyond the stronger component alone.

Neither the IETF draft-ietf-tls-hybrid-design nor NIST SP 800-227 IPD recommends the XOR combiner for new deployments. Both favour KDF-based combiners. If a hybrid scheme is worth deploying, it is worth deploying with a combiner that provides the security properties the hybrid design is meant to deliver.

Authenticated Combiners and Key Binding

An authenticated combiner additionally binds the public keys of both component KEMs into the KDF input. This prevents substitution attacks where an adversary replaces one component's public key with a related key of their choosing, then extracts information about the combined secret. The X-Wing draft specification (draft-connolly-cfrg-xwing-kem) is notably explicit about this property: it binds the ML-KEM-768 public key into the key derivation, providing a strongly-binding combiner construction as one of its distinguishing design choices relative to earlier hybrid schemes. For implementations requiring the strongest binding guarantees, X-Wing's construction is the current state-of-the-art design in the IETF CFRG process.

Protocol-Level Standards

Hybrid Key Exchange in TLS 1.3

The IETF TLS Working Group's draft-ietf-tls-hybrid-design defines how hybrid key exchange groups should be specified within TLS 1.3's named group extension. The draft covers the naming convention (for example, X25519MLKEM768), the combiner construction, and the encoding of the hybrid KeyShare. It provides the standard framework within which browser vendors, TLS library maintainers, and VPN implementations define their hybrid PQC support.

Browser deployment of hybrid TLS illustrates the transition from pre-standard Kyber to finalised ML-KEM. Google Chrome deployed hybrid TLS using X25519Kyber768Draft00 from Chrome 116 in August 2023. The “Draft00” designation matters: this version is based on the CRYSTALS-Kyber algorithm as submitted in an earlier round of the NIST competition, before the parameter changes that produced the finalised ML-KEM in FIPS 203. Chrome began transitioning to X25519MLKEM768, using FIPS 203 ML-KEM-768, from Chrome 131. Cloudflare has followed a similar progression at its edge, moving from the Kyber draft to ML-KEM-based hybrid TLS.

For organisations assessing their TLS deployment, the distinction between the Draft00 variant and the FIPS 203 variant matters for interoperability. Clients and servers must agree on which specification they are negotiating. For a broader treatment of what TLS migration to post-quantum involves, see Post-Quantum TLS: What Changes and What Stays the Same.

Hybrid Key Exchange in IKEv2 and IPsec

RFC 9370, published in May 2023 and titled “Multiple Key Exchanges in IKEv2,” defines the IETF standards mechanism for hybrid PQC in IPsec VPN connections. The RFC provides for multiple sequential key exchanges within a single IKE_SA_INIT exchange: a classical ECDH exchange followed by a PQC KEM exchange, with the results combined using the IKEv2 PRF. This is the correct standards basis for hybrid PQC in VPN deployments.

RFC 9370 is the relevant standard for organisations evaluating VPN firmware and appliance upgrades. StrongSwan and libreswan are among the open source IKEv2 implementations that have added RFC 9370 support. Commercial VPN vendors including Cisco, Palo Alto, Fortinet, and others have announced or released PQC-enabled firmware builds. For a comparison of post-quantum VPN deployments across enterprise vendors, including version support and deployment considerations, see our dedicated analysis. Specific version support should be confirmed from current vendor release notes before deployment planning.

X25519Kyber768Draft00 and X-Wing: The Critical Distinction

Two hybrid KEM specifications combining X25519 with a post-quantum algorithm are regularly conflated in secondary literature and vendor documentation. They are not interoperable and must not be treated as equivalent. The first is the X25519Kyber768Draft00 hybrid, published as an IETF internet draft (most widely referenced as draft-tls-westerbaan-xyber768d00, referred to here as the Draft00 hybrid for brevity). The second is X-Wing (draft-connolly-cfrg-xwing-kem). The distinction matters for any organisation assessing current TLS deployments or planning hybrid PQC adoption.

The Draft00 hybrid combines X25519 with Kyber768Draft00. The “Draft00” designation is precise: this is the CRYSTALS-Kyber algorithm as it existed in an early round of the NIST standardisation competition, before the parameter and specification changes that produced the finalised ML-KEM in FIPS 203 (August 2024). The Draft00 hybrid was deployed in production by Google Chrome (versions 116 to 130) and by Cloudflare at their edge before FIPS 203 was finalised. It was a real, widely deployed hybrid scheme. It is also a transitional scheme based on a pre-finalisation algorithm version, not a forward path for new deployments. No numbered RFC exists for the X25519Kyber768Draft00 hybrid: it was specified through IETF internet drafts only, never advanced to RFC status.

X-Wing (draft-connolly-cfrg-xwing-kem) specifies a hybrid KEM combining ML-KEM-768, the FIPS 203 finalised algorithm, with X25519. X-Wing was designed after FIPS 203 finalisation and uses the production-ready NIST standard. Its combiner construction is strongly binding: the ML-KEM-768 public key is bound into the key derivation, closing substitution attacks that earlier hybrid schemes did not explicitly address. As of May 2026, X-Wing remains an IETF CFRG Internet Draft, not a published RFC, but it represents the state-of-the-art design direction in the CFRG process.

These two schemes produce different output key material and are not interoperable. A client negotiating the Draft00 hybrid cannot complete a key exchange with a server implementing X-Wing over ML-KEM-768, and vice versa. Chrome's transition from X25519Kyber768Draft00 to X25519MLKEM768 (using FIPS 203 ML-KEM-768) beginning with Chrome 131 reflects this shift. Organisations assessing their TLS deployments should identify which variant their clients and servers are currently negotiating, because the two are not compatible, and the Draft00 variant is a transitional scheme, not the intended long-term path.

NIST SP 800-227: The Hybrid KEM Framework

NIST SP 800-227 (“Recommendations for Key-Encapsulation Mechanisms”), published as an Initial Public Draft in 2024, defines the NIST framework for KEM usage during the post-quantum transition, including hybrid KEM constructions. It specifies KEM security properties including IND-CCA2 security, which means indistinguishable under adaptive chosen-ciphertext attack: a KEM is IND-CCA2 secure if an adversary cannot distinguish the encapsulated key from a random value even with access to a decapsulation oracle. This is the standard security model against which hybrid combiner security proofs are assessed.

SP 800-227 does not mandate a specific hybrid scheme but provides the framework for evaluating hybrid KEMs. It references both the TLS hybrid design draft and RFC 9370 as protocol-level implementations. The current recommended hybrid pairing for most deployments, per FIPS 203 and SP 800-227, is ML-KEM-768 paired with X25519 for 128-bit post-quantum security equivalence, or ML-KEM-1024 paired with P-384 for higher security levels. The choice depends on the security level required and the performance constraints of the deployment environment.

When to Use Hybrid and When Pure PQC Is Sufficient

Hybrid PQC carries computational overhead. Two key exchange operations run instead of one. Combined public key and ciphertext sizes are larger than either component alone. For TLS 1.3 with ML-KEM-768 and X25519, the overhead is measurable, particularly on constrained devices. For a detailed look at ML-KEM versus X25519 comparative performance, including latency and handshake size benchmarks, see our dedicated analysis. Open Quantum Safe project benchmarks show it is manageable for most standard application environments.

The recommendation from NIST and from France's ANSSI (whose March 2022 position paper explicitly endorses hybrid as the transition approach) is to use hybrid PQC during the current migration period. That means now and through to the point where confidence in ML-KEM is established through broad field deployment. ANSSI's position is based on exactly the reasoning above: ML-KEM has not yet accumulated the decades of field exposure that would justify trusting it without a classical safety net.

For new deployments where backwards compatibility with pre-PQC systems is not required, pure ML-KEM without classical hybrid is technically sound. The hybrid overhead is unnecessary once confidence in ML-KEM is established through sustained field deployment and continued cryptanalytic scrutiny. NIST IR 8547 IPD timelines, published in November 2024, suggest this transition point is approximately 2030 for most use cases. Organisations building new systems today should plan for hybrid now and for the transition to pure PQC as the field deployment record accumulates. For the architecture that supports that transition without platform replacement, see our article on Crypto Agility: The Architecture Principle.

About the Author

Steven Vaile is a quantum security and post-quantum cryptography consultant and the founder of Quantum Security Defence. He advises enterprises and government bodies on PQC migration strategy, cryptographic governance, and quantum risk assessment. He has spoken at international security conferences on the intersection of quantum computing and critical infrastructure protection.