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.
6 min read
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.
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.
The replacements for the broken mechanisms above are standardized: NIST published FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) in August 2024, and selected HQC as a backup key-encapsulation mechanism in March 2025 — HQC is not yet standardized. NIST IR 8547, an initial public draft, proposes deprecating 112-bit-security classical public-key algorithms such as RSA-2048 after 2030 and disallowing them after 2035; it is a draft, not a final rule. Confirming whether hybrid key exchange is actually negotiated in a live handshake, rather than merely enabled in configuration, is the kind of question RelixQ's PQC Lab is built to answer: it observes handshakes read-only, with consent, rather than relying on configuration review alone.
Marking a lesson complete only updates this browser.