Hybrid Cryptography: Running NIST PQC and RSA Together

Hybrid cryptography is the bridge between the cryptographic world we have and the one we need. It is the practice of running classical algorithms (RSA, ECDH, ECDSA) alongside post-quantum algorithms (ML-KEM, ML-DSA, SLH-DSA) in the same handshake. The connection is secure as long as either algorithm is secure -- protecting against quantum threats that break classical algorithms AND against potential unforeseen weaknesses in new post-quantum algorithms.

Why Hybrid, Not Direct Replacement

Direct replacement (remove RSA, insert ML-DSA) carries a risk hybrid avoids. Post-quantum algorithms, while extensively analyzed, are younger than their classical counterparts. RSA has been in production since the 1970s. ML-DSA has been standardized since 2024. While the mathematical foundations are solid, implementation experience is limited.

There is a non-zero probability that a practical attack against a post-quantum algorithm will be discovered. Hybrid protects against this: if ML-KEM is broken, X25519 still provides classical security. If X25519 is broken by a quantum computer, ML-KEM still provides quantum security.

The history of cryptography is full of algorithms considered secure and later broken: MD5, SHA-1, RC4, DES. Hybrid mode provides insurance against post-quantum algorithms following this pattern.

How Hybrid Key Exchange Works

In hybrid TLS, the client and server perform two key exchanges simultaneously: one classical (X25519) and one post-quantum (ML-KEM-768). The two shared secrets are concatenated and processed through a KDF to produce the session key. If either shared secret is unpredictable (because either algorithm is secure), the derived key is secure. This is a provable property of the KDF construction.

In TLS 1.3, hybrid is implemented through the key share extension. The client sends both key shares in ClientHello. The server responds with both in ServerHello. The shared secrets combine to produce handshake keys.

How Hybrid Signatures Work

Composite signatures: One certificate contains both classical and PQ public keys. Signature is a composite of both algorithms.

Parallel chains: Two certificate chains (classical and PQ). Client verifies both. Works with existing infrastructure but doubles certificate data.

Attestation overlay: Classical certificates for TLS, plus separate PQ attestation for application data. The H33-74 approach provides three-family PQ signatures (ML-DSA + FALCON + SLH-DSA) as a 74-byte overlay, independent of TLS certificate infrastructure. This is the most practical approach for immediate deployment.

Browser and Server Support (2026)

Chrome: X25519Kyber768 hybrid ML-KEM in production since 2024. Enabled by default.

Firefox: Hybrid ML-KEM support enabled in recent versions.

OpenSSL 3.x: ML-KEM through oqs-provider or native support.

BoringSSL: Full hybrid support. Used by Google infrastructure.

AWS-LC: Full hybrid support. Used by AWS services.

For most organizations, enabling hybrid is a server-side configuration change. Browsers already support it.

Performance Impact

Hybrid adds ML-KEM on top of classical key exchange. X25519: ~50 us. ML-KEM-768: ~100 us. Total: ~150 us. Still fast for high-throughput applications.

Bandwidth: X25519 key shares are 64 bytes total. ML-KEM-768 adds ~2,272 bytes. Total hybrid key exchange: ~2,336 bytes. On 10 Mbps, this adds 0.2 milliseconds. Imperceptible for the vast majority of applications.

NIST Guidance

NIST explicitly recommends hybrid during the transition. NIST SP 800-227 (draft) provides guidance. The IETF has published hybrid TLS drafts. Browser vendors have deployed hybrid in production. The guidance is clear: use hybrid until post-quantum algorithms have sufficient deployment experience, which is estimated around 2030-2035.

Hybrid is not a compromise. It is the mathematically optimal strategy during transition -- providing security against classical attacks, quantum attacks, and insurance against unforeseen weaknesses. Enable it now.