Hybrid PQ Deployment — TLS, SSH, IPsec, S/MIME with Classical + ML-KEM Together

Hybrid mode is the answer to “what if Kyber is broken next year?” If lattice cryptanalysis advances unexpectedly, the classical leg of a hybrid still protects you. Defence-in-depth at the cryptographic primitive level.

The basic hybrid construction

Two-leg hybrid for KEM:

1. Sender:
   k_classical = X25519(s_sender, P_receiver)
   ct_pq, k_pq = ML-KEM-Encap(P_receiver_pq)

2. Both parties derive:
   shared_secret = HKDF-Extract(salt, k_classical || k_pq)
   session_key   = HKDF-Expand(shared_secret, "tls13 traffic", 32)

Adversary needs to recover BOTH k_classical (requires solving ECDLP, broken by Shor) AND k_pq (requires solving Module-LWE, no known quantum attack) to derive the session key. If Shor exists, k_classical falls but k_pq protects. If lattice cryptanalysis advances, k_pq falls but k_classical protects (against classical-only adversary). Both must fail simultaneously.

TLS 1.3 hybrid — the default deployment

The IETF tls-hybrid-design draft (Stebila, Whyte) defines hybrid named groups. The most-deployed:

• X25519MLKEM768 (NamedGroup 0x11ec, IANA-registered) — pure-PQ-with-classical-fallback. Default for Cloudflare, Google, Chrome, Firefox.
• secp256r1MLKEM768 — for FIPS-only environments where X25519 is not approved.
• secp384r1MLKEM1024 — higher security level, less commonly negotiated.

Wire format of the hybrid keyshare is a concatenation: classical_pubkey || pq_pubkey. The shared secret is HKDF-extract of the concatenated raw secrets. RFC-pending; production deployments are stable.

OpenSSL config for hybrid TLS — production recipe

OpenSSL 3.5+ ships native PQ. Configuration:

// nginx.conf
ssl_ecdh_curve x25519_kyber768:X25519:secp256r1;
ssl_protocols TLSv1.3;
ssl_prefer_server_ciphers off;

// Apache
SSLOpenSSLConfCmd Curves x25519_kyber768:X25519:secp256r1
SSLProtocol TLSv1.3
SSLCipherSuite TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256

// HAProxy
ssl-default-bind-curves x25519_kyber768:X25519:secp256r1
ssl-default-bind-options ssl-min-ver TLSv1.3

Modern browsers prefer x25519_kyber768 in their ClientHello supported_groups list. Server picks the first mutual group. Migration is transparent.

Cloudflare hybrid — already enabled

If you’re behind Cloudflare with TLS 1.3 enabled, hybrid is on by default. To verify: curl https://your-site.com -I -v 2>&1 | grep -i "Negotiated".

Or test with the experimental SSL Labs assessment that reports “Post-Quantum Key Exchange” as YES.

On the origin side, Cloudflare-to-origin can also use PQ if the origin supports it. If origin is OpenSSL 3.5+, no extra config needed.

SSH hybrid

OpenSSH 9.0+ ships [email protected] — a pre-NIST hybrid (sntrup761 is a different lattice scheme, slightly older than Kyber).

OpenSSH 9.9+ ships mlkem768x25519-sha256 — the NIST-aligned ML-KEM hybrid.

Configuration (server side, /etc/ssh/sshd_config):

KexAlgorithms mlkem768x25519-sha256,[email protected],curve25519-sha256
PubkeyAcceptedAlgorithms ssh-ed25519,ssh-rsa,rsa-sha2-512
HostKeyAlgorithms ssh-ed25519,ssh-rsa,rsa-sha2-512

Client side (~/.ssh/config):

Host *
    KexAlgorithms mlkem768x25519-sha256,[email protected],curve25519-sha256

Both client and server need OpenSSH 9.9+ for ML-KEM. For older systems, sntrup761x25519 hybrid is also acceptable (less performant, similar security guarantee).

IPsec / IKEv2 hybrid

Classical IKEv2 negotiates Diffie-Hellman group (e.g., MODP-2048, ECP-256). Hybrid extension defines additional “Key Exchange Methods” (KEM) negotiated alongside.

RFC 9242 (Multiple Key Exchanges in IKEv2) is the framework. Vendor support:

• strongSwan 5.9.13+ supports ML-KEM-768 hybrid.
• libreswan 4.10+ similar.
• Cisco IOS-XE 17.9+: ML-KEM-768 in hybrid mode.
• Fortinet FortiOS 7.4+: experimental support.
• Palo Alto PAN-OS 11.x: announced for 2025-2026.

Email — S/MIME and PGP

S/MIME signing: ML-DSA-65 hybrid with RSA-2048. The signed message has both signatures; recipient verifies whichever is supported. Microsoft Exchange / Outlook expected to support 2026-2027.

PGP/GnuPG: experimental ML-KEM and ML-DSA support in GnuPG 2.4+ (compile-time enabled). Hybrid pgp keys can have both classical and PQ subkeys.

Hybrid signature deployment — code signing

Code signing has unique constraints — signed binaries are persistent and verified by old systems. Hybrid signature pattern:

1. Sign binary with ECDSA (current).
2. Also sign with ML-DSA-65, embedded as separate signature in the file’s signature container.
3. Verifiers check ECDSA (legacy systems) OR ML-DSA (new systems) OR both (transitional verifiers).

Microsoft Authenticode is roadmapped for hybrid by 2026. Java JAR signing (jarsigner) similar.

Performance characterisation — what to expect

For most production sites, the additional 100-200 µs per handshake is negligible compared to network latency. The 2 KB additional handshake bytes is comfortably within MTU; no fragmentation concerns.

Migration checklist

1. Inventory all TLS endpoints. Group by criticality.
2. Pilot one origin server with hybrid TLS. Monitor handshake success rate and performance.
3. Update client allow-lists if you have policy enforcement (e.g., specific cipher suites required by HIPAA / PCI).
4. Roll out to remaining production endpoints.
5. Add hybrid TLS to your security baseline / standards document.
6. Plan for SSH and IPsec hybrid in subsequent quarter.

FAQ

What if the classical leg is broken? Should we go pure-PQ?

If a polynomial-time classical attack on X25519 is discovered (very unlikely), drop X25519 from your supported_groups and fall back to ML-KEM only. Until then, hybrid is conservative.

Is hybrid susceptible to “man-in-the-middle” attacks beyond classical?

No. The hybrid construction is provably no-worse than the stronger of its two components. MITM resistance comes from the certificate chain (signature-based authentication), not from the KEM itself.

Does hybrid require client opt-in?

No. Modern browsers (Chrome, Firefox, Safari) include hybrid groups in their default supported_groups list. Server negotiates whatever both sides support.

What’s the negotiation order?

Cloudflare/Google prefer hybrid first, then pure ECDH. Servers should match. If client’s first preference is hybrid and server supports it, hybrid is chosen. If client doesn’t support hybrid, server falls back to ECDH.

Can we monitor hybrid adoption in our traffic?

Yes. Server-side metrics for negotiated NamedGroup. Cloudflare exposes this via Web Analytics. Self-hosted: log negotiated cipher / key exchange in your TLS handler.

⚖️ Module 9 of 20. Intermediate. Module 10 covers QKD — the alternative quantum-cryptography technology, and why most security teams should care less about it than they think.