Skip to content

PATTERN Cited by 1 source

Encryption-before-authentication sequencing

Pattern

When migrating an entire cryptographic stack to a new generation (e.g. classical → post-quantum), deploy encryption (KEMs) before authentication (signatures) because their threat models have fundamentally different time profiles.

Rationale

Property Encryption (KEMs) Authentication (Signatures)
Threat window Today — HNDL captures ciphertext now for future decryption Q-Day — forgery requires a live CRQC
Retroactivity Captured traffic is permanently exposed Past signatures cannot be retroactively forged
Dependency chain Short — endpoint negotiation only Long — CAs, CT logs, root stores, clients all must upgrade
Performance impact Minimal (hybrid ML-KEM faster than TLS 1.2) Significant (ML-DSA signatures much larger)
Ecosystem readiness High — 2/3 of browser traffic uses PQ KEMs (2026) Low — early pilots only

The urgency gradient is clear: every day of delay on encryption means more HNDL-captured traffic that can never be un-captured. Authentication delay only matters if Q-Day arrives before the upgrade — a different (but accelerating) risk curve.

EO 14409 instance

The executive order encodes this pattern directly: - Dec 2030 — PQ encryption (key establishment) - Dec 2031 — PQ authentication (digital signatures)

But Cloudflare warns the one-year gap is tight given the authentication dependency chain. Both efforts should proceed concurrently, with encryption simply deploying first.

Anti-pattern: sequential gating

Treating encryption and authentication as sequential phases where authentication work doesn't begin until encryption is "done" wastes the calendar time available. The correct approach is concurrent engineering with staggered deployment.

Seen in

Last updated · 559 distilled / 1,651 read