06 — Hybrid Mode

Why Hybrid?

Post-quantum algorithms are new. While mathematically sound, they haven't been battle-tested for decades like RSA and ECDH. A hybrid approach:

Maintains classical security if the PQC algorithm has an undiscovered flaw
Maintains PQC security if the classical algorithm is broken by quantum computers
Meets compliance requirements from NSA (CNSA 2.0) and other agencies

How It Works

Run BOTH a classical key exchange AND ML-KEM. Combine their outputs.

Rendering diagram...

sequenceDiagram
    autonumber
    actor Client
    actor Server

    Client->>Client: 1. Generate ECDH key pair<br/>2. Generate ML-KEM key pair
    Client->>Server: 3. Send: ECDH_public || MLKEM_pk
    Server->>Server: 4. Receive both keys<br/>5. Generate ECDH share<br/>6. Encapsulate with ML-KEM
    Server->>Server: 7. Derive:<br/>ss_classical = ECDH(shared)<br/>ss_pq = ML-KEM_decaps(ct)<br/>ss_final = KDF(ss_classical || ss_pq)
    Server->>Client: 8. Send: ECDH_share || MLKEM_ct
    Client->>Client: 9. Receive both responses<br/>10. Derive ss_classical<br/>11. Decapsulate ML-KEM<br/>12. ss_final = KDF(ss_classical || ss_pq)
    Note over Client,Server: Both share the same ss_final

The Key Derivation Function (KDF)

Simply concatenating secrets is not enough. You need a proper KDF:

ss_final = HKDF-Extract(salt, ss_classical || ss_pq)

Why HKDF-Extract:

Extracts entropy from both sources even if one is weak
Uniform output even if inputs have different distributions
Domain separation — prevents related-key attacks

Deployment Scenarios

TLS 1.3

ClientHello:
  - Supported groups: secp256r1, X25519, ML-KEM-768
  - Key shares: [ECDH share] [ML-KEM-768 public key]

ServerHello:
  - Selected group: hybrid
  - Key shares: [ECDH share] [ML-KEM-768 ciphertext]

Both derive: ss = HKDF-Extract(0, ECDH_ss || MLKEM_ss)

Status: IETF is standardising this. Draft: draft-ietf-tls-hybrid-design

VPN (WireGuard / IPsec)

VPN Type	How to add ML-KEM
WireGuard	Extend handshake to include ML-KEM encapsulation alongside X25519
IPsec/IKEv2	Add ML-KEM as a transform in the SA negotiation
OpenVPN	Use TLS 1.3 hybrid mode

Secure Messaging (Signal Protocol)

Signal's double-ratchet can incorporate ML-KEM:

Initial handshake: X25519 + ML-KEM hybrid
Subsequent ratchets: Continue using the established KDF chain
Fallback: If ML-KEM fails, X25519 alone still provides classical security

When to Drop the Classical Part

The goal is eventual pure-PQC operation. Transition timeline:

Phase	Timeline	Configuration
Current	2024–2028	Hybrid (classical + PQC)
Transition	2028–2033	Hybrid default, allow pure PQC
Post-quantum	2033+	Pure PQC (remove classical)

Signals to drop classical:

NIST/NSA guidance updates
Cryptanalysis confidence in ML-KEM after 10+ years of scrutiny
Quantum computers demonstrably breaking classical algorithms

Resources

NIST IR 8547: Transition to Post-Quantum Cryptography
NSA CNSA 2.0: Commercial National Security Algorithm Suite
IETF draft: draft-ietf-tls-hybrid-design
Open Quantum Safe — Reference implementations of hybrid TLS