◇ OpenCyber Academy
Master's · Chapter 2 · English

Chapter 2 — Quantum and post-quantum security: advanced seminar

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 2 — Quantum and post-quantum security: advanced seminar

Lesson map

Lesson 02 published. Map, example, EX008.

flowchart TD
  N0["Learning outcomes and connection"]
  N1["2.1 Harvest now, decrypt later"]
  N2["2.2 ML-KEM in one page"]
  N3["2.3 Hybrid combiners"]
  N4["2.4 Families compared"]
  N5["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Worked example"]
  EX --> Q["Exercise EX008"]

Logical drawing

flowchart LR
  N0["Learning outcomes and connection"]
  N1["2.1 Harvest now, decrypt later"]
  N2["2.2 ML-KEM in one page"]
  N3["2.3 Hybrid combiners"]
  N4["2.4 Families compared"]
  N5["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX008"]
[Learning outcomes and connection]
    |
    v
[2.1 Harvest now, decrypt later]
    |
    v
[2.2 ML-KEM in one page]
    |
    v
[2.3 Hybrid combiners]
    |
    v
[2.4 Families compared]
    |
    v
[Chapter synthesis]
    |
    v
[Worked example] --> [Exercise EX008]

Learning outcomes and connection

You will (1) explain why key establishment is migrated before signatures; (2) describe the structure of ML-KEM and of a PQ/T hybrid combiner at the level needed to reason about deployment; (3) compare post-quantum families by size and assumption; and (4) critique a seminar paper. It deepens the background of Chapter 1 and grounds the study design of Chapter 3.

2.1 Harvest now, decrypt later

An adversary who records encrypted traffic today can decrypt it later if the key exchange falls to a future cryptographically relevant quantum computer running Shor's algorithm (Shor 1997). Signatures are different: forging a signature later does not help an attacker against a session that has already ended. That asymmetry is why browsers and CDNs deployed hybrid key exchange first and why the Fragment Study concerns key shares, not certificates. Signature migration matters for long-lived trust anchors and firmware, and brings its own size problems — ML-DSA-65 signatures are 3,309 bytes (FIPS 204) — but it is a later wave.

2.2 ML-KEM in one page

ML-KEM is a key-encapsulation mechanism built on the module learning-with-errors problem, a structured variant of LWE (Regev 2009). Informally, the public key hides a secret vector behind a matrix product plus small noise; encapsulation produces a ciphertext from which only the secret-key holder can recover a shared 32-byte key, and a Fujisaki–Okamoto-style transform gives security against chosen-ciphertext attacks. ML-KEM-512, -768 and -1024 target NIST security categories 1, 3 and 5. For deployment research the essential facts are the sizes (encapsulation key 800/1,184/1,568 bytes; ciphertext 768/1,088/1,568 bytes), the speed (fast — often faster than X25519 in optimized code) and that decapsulation failure is possible but negligible at the standardized parameters. SP 800-227 gives NIST's recommendations for using KEMs.

2.3 Hybrid combiners

A PQ/T hybrid (RFC 9794) runs a post-quantum and a traditional key exchange and derives the session key from both, so that an attacker must break both. In X25519MLKEM768 the two shared secrets are concatenated — ML-KEM first, then X25519 — and fed into the TLS 1.3 key schedule (RFC 10024). The hybrid hedges two risks at once: a future quantum computer (covered by ML-KEM) and an unexpected weakness in the newer lattice assumption (covered by X25519). The breaks of Rainbow (Beullens 2022) and SIKE (Castryck and Decru 2022) are why the second hedge is taken seriously.

2.4 Families compared

Family Example Assumption Public key / ciphertext or signature Deployment note
Lattice KEM ML-KEM-768 Module-LWE 1,184 / 1,088 B Default for TLS hybrids
Code KEM HQC (selected 2025, IR 8545) Quasi-cyclic codes Several kB Backup with different assumption
Code KEM Classic McEliece Goppa codes Public keys of hundreds of kB Long-term static keys, not handshakes
Lattice signature ML-DSA-65 Module-LWE/SIS 1,952 B key / 3,309 B signature Certificates, code signing
Hash signature SLH-DSA (FIPS 205) Hash functions Small keys / 7.8–49.9 kB signatures Conservative; large

2.5 Worked example: seminar critique

The seminar paper (synthetic study "P-7") reports that "hybrid key exchange increases handshake failure by 240%". Critique: the base rate is not stated (240% of what?); the comparison is across two different weeks with a browser update in between; failures are counted per attempt, but retries inflate attempts; and there is no stratification by path. The defensible version would report absolute rates with intervals, a concurrent control and path-level results — which is the Fragment Study's design.

Write the critique in four short paragraphs, one per flaw, each ending with the design change that would fix it. That turns a list of complaints into a method, and it makes the link to the Fragment Study visible: base rates per 10,000 series, a concurrent control cohort, series rather than attempts, and results by egress path.

2.6 Common errors and limits

Each error has a concrete correction in this dissertation. Hybrid key exchange protects key establishment only, and certificates migrate later. Rates are reported per 10,000 series with Wilson intervals. ML-KEM's cost in the Fragment Study is the size of the key share, which pushes the ClientHello across a segment boundary. Standards status is dated, and should be checked again before submission.

Exercises — chapter 2

Chapter synthesis

Key establishment migrates first because recorded traffic can be decrypted later. ML-KEM is fast but large; hybrids hedge both quantum and classical surprises; and deployment claims need base rates, concurrent controls and stratification.

Continue studying — chapter 02 of 08

← Chapter 01 (draft) · Course chapter index · Chapter 03 (draft) →