The four variables
The protection path: from data to the cryptography guarding it
The third variable: tracing a data flow to the specific cryptographic mechanism that actually protects it, and whether that mechanism is quantum-vulnerable.
7 min read · 6 min 34 sec film
What you'll be able to do
- Trace a data flow to the specific mechanism that actually protects it.
- Identify which key-establishment mechanisms Shor's algorithm breaks outright.
- Correct the misconception that forward secrecy prevents HNDL.
- Explain why hybrid key exchange is the highest-leverage current action for data in transit.
Lesson film
Watch: The protection path: from data to the cryptography guarding it
A protocol name is not a protection mechanism — and forward secrecy, the property everyone reaches for here, defends against something else entirely.
6 min 34 sec · 8 scenes
6 min 34 sec, narrated by your browser's voice. Captions and a full transcript are below — nothing here needs sound.
This is the most specific question in the chain, and the one where vague answers do the most damage.
With the player focused: Space plays or pauses, ← → seek ten seconds, Home restarts, M toggles narration.
Full transcript
1. The specific question
2. A name is not a mechanism
3. Confirm it
4. What each mechanism does
5. Forward secrecy is not this
6. The lever that exists today
7. Two things this is not
8. Takeaway
The written lesson
The third variable asks the most specific question in the chain: for this data, at this point in its life, exactly which cryptographic mechanism actually establishes confidentiality? Naming a protocol is not enough — TLS can negotiate a classical-only handshake or a hybrid one, and the difference determines almost everything that follows. Trace the flow all the way to the key-establishment mechanism it actually negotiated, not the protocol name or the cipher-suite label.
| Mechanism | Effect of quantum algorithms | Note |
|---|---|---|
| RSA key transport | Broken outright by Shor's algorithm | Captured ciphertext becomes recoverable once a CRQC exists; the strength of any symmetric key it delivered does not matter. |
| ECDH and finite-field Diffie-Hellman | Broken outright by Shor's algorithm | Applies even when the handshake is ephemeral — forward secrecy protects against a different kind of compromise and does not change this. |
Hybrid key exchange, for example X25519MLKEM768 | Not broken by either algorithm alone | Confidentiality holds unless both the classical and post-quantum mechanisms are broken; this is the recommended transition mechanism for data in transit. |
| Symmetric encryption alone (e.g. AES-256) once a key is established | Only quadratically weakened, by Grover's algorithm | NIST still considers AES-128 acceptable and treats AES-256 as having ample margin; this is rarely the actual weak point. |
Hybrid key exchange changes the picture for data in transit. Combining a classical mechanism with a post-quantum one — for example X25519MLKEM768 — keeps a session confidential unless both mechanisms are broken. It is already deployed by default in major browsers and by many servers and CDNs, which makes enabling it, wherever it is not already the default, one of the highest-leverage actions available against HNDL for traffic in transit.
NIST published FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) in August 2024, and selected HQC as a backup KEM in March 2025; HQC is not yet standardized. NIST IR 8547 remains an initial public draft. It proposes deprecating 112-bit-strength classical public-key uses such as RSA-2048 after 2030 and disallowing listed classical public-key uses after 2035; those are not final universal rules. For a live TLS path, verify the negotiated key-exchange group rather than inferring it from the protocol version or configuration alone.
- 01
Follow the content
Identify the ciphertext an adversary might store and the key that directly decrypts it.
- 02
Follow each key
For a wrapped data key, identify the wrapping mechanism, where its public and private material lives, and whether a capturable transcript or wrapped key would enable later recovery.
- 03
Follow the hops
For a connection, record the actual negotiated group separately for each relevant client, CDN, partner, and origin hop. A configuration setting is weaker evidence than a sampled negotiation.
Primary reading and claim sources
Publication status checked on the date shown. Draft guidance can change.
- RFC 10024: PQ/T Hybrid Key Agreement Mechanisms for TLS 1.3IETF · Standards-track RFC, August 2026 · checked 2026-09-26
- FIPS 203: Module-Lattice-Based Key-Encapsulation MechanismNIST · Final standard · Sections 3.1 and 8; Table 3 (parameter sizes) · checked 2026-09-26
- TR 104 016: A Repeatable Framework for Quantum-Safe MigrationsETSI · Published technical report · checked 2026-09-26
Marking a lesson complete only updates this browser.