Day 15: Why Hybrid? Cryptographic Agility and the Transition Rationale

Phase 3 · July 22, 2026

Agenda (2–3 hours)

• Read (45 min): IETF draft-ietf-tls-hybrid-design §1–3 (rationale and goals); NIST IR 8413 §3.3 (hybrid recommendations)
• Study (45 min): Hybrid construction principles, the security argument, why it's not redundant
• Challenge (45 min): Hybrid design analysis for your service

The Case for Hybrid

Pure PQC transition (switch directly to ML-KEM, drop ECDH):

• Fast migration
• Risk: if ML-KEM has an undiscovered weakness, all protection is gone
• PQC is newer and less battle-tested than 30+ years of ECDH

Hybrid approach (combine classical + PQC):

• Slower migration, more complexity
• Defense in depth: an attacker must break BOTH ECDH AND ML-KEM simultaneously
• If either is secure, the session is secure
• Endorsed by NIST, NSA, CISA, IETF, and all major TLS implementors

The hybrid period is not permanent — it's a transition strategy.
Once confidence in PQC is established (5–10 years), drop the classical component.

The Security Argument

For a hybrid KEM combining shared secrets ss_classical and ss_pqc:

combined_secret = KDF(ss_classical || ss_pqc || context)

Security properties:

• If only ECDH is secure (quantum doesn't exist / PQC broken): ss_classical is secret → combined_secret is secret ✓
• If only ML-KEM is secure (CRQC exists / ECDH broken): ss_pqc is secret → combined_secret is secret ✓
• An adversary must break both simultaneously to recover combined_secret

This is the "harvest now, decrypt later" defense: classical protects against
near-term adversaries; PQC protects against future quantum adversaries.

Cryptographic Agility vs. Hybrid

Cryptographic agility: the ability to swap algorithms without re-deploying the service.
This is often proposed as an alternative to hybrid, but it's not the same:

• Agility lets you switch from ECDH → ML-KEM later
• It does NOT protect data encrypted with ECDH today from a future CRQC
• Agility is necessary but not sufficient

Hybrid is what protects historical data.
Agility is what lets you deprecate the classical half once PQC is established.

Design for both: hybrid now, agility to shed the classical half in 5 years.

When to NOT Hybrid

There are legitimate cases for pure PQC:

• Brand-new protocols with no deployed base: start pure PQC from day one
• Constrained devices: satellite terminals with limited CPU/bandwidth where hybrid overhead is prohibitive
• Post-transition period (after ~2035): CNSA 2.0 says drop classical

For your provisioning service in 2026–2030: always hybrid for TLS.
For new internal protocols being designed today: pure PQC is acceptable with justification.

Challenge Assignment

Write the "Hybrid Strategy" section of your migration roadmap:

1. Rationale: explain in 1 paragraph why your team should use hybrid rather than pure PQC
2. Duration: when should the hybrid period end for your service? What signals would trigger dropping the classical component?
3. Protocol-by-protocol table:

Resources

• IETF draft-ietf-tls-hybrid-design: datatracker.ietf.org
• NIST IR 8413 §3.3: guidance on hybrid approaches
• AWS s2n-tls blog: "Hybrid post-quantum TLS with s2n"