What Is Hybrid Cryptography?
Hybrid cryptography combines a classical cryptographic algorithm with a post-quantum algorithm in a single protocol exchange. Both algorithms are run in parallel, and their outputs are combined using a key derivation function. The resulting session secret is only compromised if both the classical algorithm and the post-quantum algorithm are simultaneously broken.
This property is the key advantage of hybrid deployment during the transition period. A classical ECDH exchange provides protection if a post-quantum algorithm turns out to have an undiscovered weakness. The post-quantum algorithm provides protection if a capable quantum computer becomes available. Either protection mechanism is sufficient on its own; both must fail simultaneously for the session to be vulnerable.
Why Use Hybrid During the Transition?
NIST, NSA, CISA, and the IETF all recommend hybrid cryptography as the practical approach during the post-quantum transition. The reasons are interoperability, risk management, and deployment logistics.
Interoperability: not all clients and counterparties will update their cryptographic stacks simultaneously. A server running pure ML-KEM key exchange cannot establish a session with a client that only supports ECDH. A hybrid server accepts both classical and post-quantum key shares, completing the session with whichever mechanism the client supports, while providing ML-KEM-based protection for clients that do.
Risk management: the post-quantum algorithms in FIPS 203, 204, and 205 are well-analyzed, but they are newer than RSA and ECDH. Running hybrid provides defense in depth: the classical algorithm acts as insurance against undiscovered weaknesses in the post-quantum algorithm.
Hybrid Key Exchange in TLS 1.3
In TLS 1.3, key exchange is specified via named groups in the ClientHello. The IETF has standardized X25519MLKEM768 as a hybrid named group that combines X25519 (classical ECDH) with ML-KEM-768 (post-quantum key encapsulation). A TLS client that includes X25519MLKEM768 in its ClientHello indicates support for this hybrid group.
Major browsers have shipped support for X25519MLKEM768. Server-side support is available in recent versions of OpenSSL, BoringSSL, and most cloud TLS termination services. Enabling this hybrid group on servers requires no application-layer changes, only TLS library and server configuration updates.
The shared secrets from X25519 and ML-KEM-768 are combined using a key derivation function specified in the named group definition. The resulting key material feeds into the standard TLS 1.3 key derivation process. The TLS session is then encrypted using the derived symmetric keys in exactly the same way as a classical TLS session.
Hybrid in Other Protocols
Hybrid approaches apply beyond TLS. SSH key exchange can be extended to combine ECDH with ML-KEM. IKEv2 (used in VPNs and IPsec) can be configured to combine classical Diffie-Hellman with ML-KEM. IETF working groups are specifying hybrid approaches for each of these protocols.
For digital signatures, hybrid certificates combine an ECDSA or RSA signature with an ML-DSA signature. Verifiers that support only classical signatures can verify the classical component; verifiers that support ML-DSA can verify the post-quantum component. Several X.509 hybrid certificate profile approaches are under active IETF standardization.
Limitations and Tradeoffs
Hybrid cryptography increases handshake size. A TLS ClientHello including X25519MLKEM768 is larger than one using X25519 alone because it includes the ML-KEM public key share. This may push the ClientHello across TCP segment boundaries on some networks, adding a round-trip in the handshake. Measurement in production-representative environments is recommended.
Hybrid approaches add implementation complexity. Each implementation must correctly combine two cryptographic algorithms, which increases the attack surface for implementation errors. Using well-tested libraries rather than implementing hybrid from scratch is strongly recommended.
Transitioning Beyond Hybrid
Hybrid deployment is a transitional strategy, not a permanent state. Once the ecosystem of clients, servers, HSMs, and counterparty systems has broadly adopted post-quantum algorithms, and once the NIST algorithms have accumulated years of real-world security track record, organizations can plan to transition from hybrid to post-quantum-only operation.
NIST IR 8547 provides guidance on planned deprecation of classical algorithms, including timelines for when ECDH and RSA key exchange will no longer be acceptable in FIPS-compliant implementations. Organizations should track this document and plan to complete the transition from hybrid to pure post-quantum before the classical algorithms are deprecated.
References
Frequently Asked Questions
Does hybrid TLS protect against harvest-now-decrypt-later?
Yes. Hybrid TLS provides post-quantum key exchange in every session. An adversary collecting traffic today cannot derive the session key from the ML-KEM component without a capable quantum computer, even if they can break the classical X25519 component in the future.
Can I run hybrid TLS without updating my applications?
Yes, for most applications. Hybrid TLS key exchange is handled at the TLS library and server configuration level. Applications that use TLS through a library do not need to be modified to enable hybrid key exchange. Certificate and signature migration may require application changes to accept ML-DSA certificates.