365 Architect

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.

┌─────────────────────────────────────┐
│           Client                      │
│                                     │
│  1. Generate ECDH key pair          │
│  2. Generate ML-KEM key pair        │
│                                     │
│  3. Send: ECDH_public || MLKEM_pk   │
│              ↓                      │
└─────────────────────────────────────┘
              │
              │ Network
              ↓
┌─────────────────────────────────────┐
│           Server                      │
│                                     │
│  4. Receive both keys               │
│  5. Generate ECDH share             │
│  6. Encapsulate with ML-KEM         │
│                                     │
│  7. Derive:                         │
│     ss_classical = ECDH(shared)     │
│     ss_pq = ML-KEM_decaps(ct)       │
│     ss_final = KDF(ss_classical ||  │
│                    ss_pq)           │
│                                     │
│  8. Send: ECDH_share || MLKEM_ct    │
│              ↓                      │
└─────────────────────────────────────┘
              │
              │ Network
              ↓
┌─────────────────────────────────────┐
│           Client                      │
│                                     │
│  9. Receive both responses          │
│  10. Derive ss_classical            │
│  11. Decapsulate ML-KEM             │
│  12. ss_final = KDF(ss_classical || │
│                    ss_pq)           │
│                                     │
│  [Both have 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

★★★★★
Share on LinkedIn