Post-quantum cryptography (PQC) changes how systems establish secrets and authenticate information, but "is this quantum-safe?" is not one question — it's at least four: which algorithm, which implementation, which protocol, and which deployment boundary. This first chapter builds that map before the course touches any mathematics. It walks through why migration urgency doesn't require a working quantum computer to exist yet (harvest-now-decrypt-later), what NIST has actually finalized versus what's still in draft as of September 2026, and how to read a vendor's "we support PQC" claim without being misled by it. Every current-state claim here is sourced to a primary document — a FIPS, an RFC, or a vendor engineering post — not to a press summary.
1. What you will learn
By the end of this chapter you should be able to explain why migration can be urgent before a cryptographically relevant quantum computer exists; distinguish key establishment from signatures and symmetric encryption as three separate engineering jobs; read a standards announcement without confusing "selected" with "finalized" with "deployed"; and identify which layer of a real system a given PQC change actually protects. No quantum mechanics or advanced mathematics is required here — familiarity with an HTTPS connection, a public key, and a software dependency is enough to follow along.
The course uses the September 2026 landscape as its checkpoint. Every current-state statement below has a primary source linked. A software feature is not a benchmark, an announced rollout is not universal deployment, and a standardized algorithm is not a guarantee about every implementation that claims to speak it. Those three distinctions recur throughout this course because they're exactly what determines whether an engineering decision is actually justified or just sounds justified.
2. Start with an ordinary connection
Imagine a service that accepts sensitive customer records over HTTPS and stores them in encrypted backups. It also distributes signed client updates. That short description already contains three different security jobs: protecting traffic in transit, protecting data at rest, and identifying authorized software. They may share libraries under the hood, but they don't share the same cryptographic exposure, and a PQC migration that fixes one doesn't automatically fix the others.
A captured network handshake can contain information that a sufficiently capable future attacker reconstructs into a session secret — this is the "harvest now" threat, covered in §4. A backup instead depends on how its encryption key was generated, wrapped, and stored, which is a completely different exposure path. A forged update signature could authorize new malicious code even if no old ciphertext is ever decrypted. Asking whether the service "uses quantum-safe encryption" compresses three separate questions into one label, and that compression is where migration plans go wrong.
This fictional records service is a recurring example throughout the course, used to reason about key lifetimes, certificates, deployment boundaries, and benchmarks. Its numbers are illustrative, not a measurement of any real organization — and a key point the course keeps returning to: a change at its public gateway does not automatically protect its database, its backups, or its update-signing infrastructure. Those are four separate migration projects that happen to share a vocabulary.
Fig. 1 — "We migrated to post-quantum crypto" almost always means one of these four boxes, not all four.
3. What post-quantum cryptography actually is
PQC consists of cryptographic constructions intended to resist attacks by both classical and quantum computers. They run on ordinary processors and communicate through ordinary networks — a laptop can execute ML-KEM without possessing a quantum processor of any kind. Their mathematical assumptions differ from the factoring and discrete-logarithm assumptions underlying RSA and elliptic-curve cryptography, which is exactly the property that makes them resistant to the quantum algorithms covered in §4. See the NIST PQC project overview for the canonical framing.
Quantum key distribution (QKD) is a different, unrelated subject worth naming just so it isn't confused with PQC. QKD uses physical quantum communication — photons, specialized hardware, dedicated fiber — to support key establishment, with its own equipment, channel, authentication, and operational requirements. PQC is entirely software: the subject of this course, and the thing that actually runs on the internet's existing infrastructure. Neither approach removes the need to authenticate endpoints, protect keys, or implement applications securely — a compromised process can read a plaintext record after perfectly sound cryptography has delivered it, and no amount of quantum-resistant math fixes that.
The phrase "post-quantum" describes the attacker model, not an assertion that quantum computers have already defeated deployed cryptography today, and not a claim that any PQC scheme is unbreakable. Confidence in these schemes comes from public cryptanalysis, explicit security assumptions, conservative parameter choices, careful protocol composition, and implementation evidence accumulated over years of scrutiny. Future cryptanalysis can and does revise that confidence — which is exactly why engineering needs an update path, covered in Part 16 under the name "cryptographic agility," not just a one-time algorithm swap.
4. Why Shor and Grover have completely different consequences
Peter Shor's 1994 result gives quantum algorithms for factoring integers and computing discrete logarithms. On a sufficiently capable quantum machine, these change the asymptotic difficulty class of the exact problems that RSA and Diffie–Hellman-style systems rely on for their security. Elliptic-curve cryptography relies on a discrete-logarithm problem too, in a different group — its small key sizes don't remove this structural vulnerability, they just make the classical attack harder without touching the quantum one at all. See Shor's original paper.
Think of the difference between replacing a weak door and making the same weak door thicker. Increasing a classical public-key parameter (a bigger RSA modulus) increases the resources a concrete classical attack needs, but it does nothing about the algorithmic reason for migration — Shor's algorithm doesn't care how big the number is, it changes the shape of the problem. Replacing the underlying mathematical construction is a different fix entirely. This is precisely why "just use a much larger RSA key" is not, and never was, a viable long-term PQC strategy.
Grover's algorithm, by contrast, is a generic quadratic search speedup with no special relationship to any particular cryptographic structure. Searching an unstructured space of \(N\) possibilities takes on the order of \(\sqrt{N}\) oracle queries in its idealized model. For a uniform \(k\)-bit secret, that becomes roughly \(2^{k/2}\) queries instead of \(2^k\) — a square-root speedup, not an exponential break. Critically, a "query" here is not a free CPU instruction: implementing the cryptographic check reversibly, keeping the quantum computation coherent and reliable, and managing circuit depth and parallelism all impose real physical overhead that a simple exponent-halving heuristic ignores. See Grover's original paper.
Consequently, symmetric cryptography does not need the same wholesale replacement that public-key cryptography does. AES, authenticated encryption, hash functions, HMAC, and key derivation remain essential, structurally sound components — their parameters still deserve review (doubling a key length costs little and closes the Grover gap), but there is no equivalent of "RSA is fundamentally broken by Shor" on the symmetric side. Hash preimage resistance and collision resistance are also two different security properties with two different Grover-era stories, and neither is well summarized by the common but sloppy claim that "quantum computers halve all security everywhere." Part 3 unpacks the actual resource model in detail; Part 2 first builds the primitive vocabulary needed to make that unpacking precise.
5. Harvest now, decrypt later
An attacker doesn't have to read intercepted data immediately to benefit from collecting it today. If a captured transcript remains useful for years, a later cryptanalytic improvement — quantum or otherwise — can make that old, patiently-stored ciphertext valuable retroactively. The immediate engineering question isn't "does a quantum computer exist yet," it's whether today's protection covers the entire period during which the information must stay confidential.
A useful planning model, attributed to Michele Mosca, compares three durations: \(S\), the remaining secrecy lifetime the data actually needs; \(M\), the time it will take to migrate the systems protecting it; and \(Q\), the uncertain time until a cryptographically relevant quantum computer exists. The warning condition is \(S + M > Q\). This is a heuristic for exposure, not a forecast or a probability distribution — it's a tool for structuring a conversation about risk, not a prediction engine. See Mosca's migration argument.
| Variable | Meaning | Example for the records service |
|---|---|---|
| \(S\) | How long the data must stay secret | 10 years (regulatory retention requirement) |
| \(M\) | How long the full migration will take | 4 years (every affected dependency, not just the gateway) |
| \(Q\) | Time until a relevant quantum computer exists | Unknown — genuinely uncertain, not zero |
| \(S+M\) | Combined exposure horizon | 14 years — this is the number that has to beat \(Q\) |
It does not follow from this exercise that a cryptographically relevant machine will definitely exist in fourteen years. It follows that uncertainty about \(Q\) cannot be treated as license to defer, because \(S\) and \(M\) are the parts of the equation an organization actually controls, and waiting for certainty about \(Q\) can itself consume the response time that was supposed to be available. A public weather advisory that loses sensitivity within hours and a decade-retained medical record might traverse the identical TLS protocol, but their \(S\) values — and therefore their urgency — are wildly different. A useful data inventory attaches an \(S\) value to each category of information, rather than treating "we have some encrypted disks" as a single undifferentiated risk line.
6. A KEM is not a signature
A key-encapsulation mechanism (KEM) has three conceptual operations. Key generation produces a public encapsulation key and a private decapsulation key. Encapsulation uses the public key to produce a ciphertext and a shared secret. Decapsulation uses the private key and that ciphertext to recover the same shared secret. A surrounding protocol then derives traffic keys from that secret and uses ordinary symmetric encryption for the actual data. See NIST SP 800-227 for the formal KEM interface.
Fig. 2 — Nothing here checks whose public key ek actually is. If an attacker substitutes their own ek and the sender accepts it, the math of encapsulation does not somehow authenticate the recipient — that's a separate job, covered next.
This is a conceptual flow, not a complete authenticated protocol, and that gap is deliberate and important. Key distribution and authentication are separate obligations from key establishment. Part 7 makes the ML-KEM interface exact; Part 11 shows its role inside a fully standardized hybrid TLS exchange that does handle authentication properly.
A signature instead connects a message to a signing key and a corresponding verification key. A verifier checks whether a signature is mathematically valid under that key — but it must also separately decide whether that key is trusted for the claimed purpose. A valid signature from an unknown attacker's key is not a trusted software release; it's just a valid signature from a key nobody should trust. Certificates, trust stores, policies, and signed metadata provide the context in which mathematical verification actually becomes meaningful security.
This separation explains a common deployment surprise: hybrid key establishment can fully protect captured traffic against harvest-now-decrypt-later while the certificate chain authenticating that same connection still uses classical ECDSA signatures. That's an intentional, reasonable intermediate architecture with a specific, well-understood threat boundary — but it should never be described as "complete post-quantum authentication," because it isn't. Migrating identity means separately replacing trust anchors, issuers, hardware interfaces, and relying-party behavior, none of which a KEM swap touches.
7. The standardization timeline
NIST's public PQC process began in 2016. Its 2022 selections included the algorithms that became the first three finalized standards, plus Falcon for additional signature research. In August 2024, NIST published FIPS 203, 204, and 205 as final standards. HQC was selected in March 2025 as an additional KEM built on a different, code-based mathematical family — deliberate assumption diversity, not redundancy. See the NIST project history and the HQC selection report.
The chronology matters in practice because old names persist in papers, code, configuration files, and packet captures for years after a standard finalizes. ML-KEM derives from CRYSTALS-Kyber, but a pre-standard Kyber implementation is not automatically an implementation of the final FIPS 203 standard — encoding details changed between draft rounds. Likewise ML-DSA derives from CRYSTALS-Dilithium without every earlier Dilithium variant being interoperable with it. Version and encoding are part of the interoperability contract, not cosmetic naming, and this bites real deployments that pinned an early library version.
| Algorithm / document | Role | Status as of Sep 2026 |
|---|---|---|
| FIPS 203 / ML-KEM | Module-lattice KEM | Final, Aug 13, 2024 |
| FIPS 204 / ML-DSA | Module-lattice signatures | Final, Aug 13, 2024 |
| FIPS 205 / SLH-DSA | Stateless hash-based signatures | Final, Aug 13, 2024 |
| Falcon / FN-DSA (planned FIPS 206) | Compact lattice signatures | Selected; standardization ongoing |
| HQC | Code-based KEM | Selected; standardization ongoing |
The first three rows are governed by FIPS 203, FIPS 204, and FIPS 205. Selection, draft release, final publication, implementation support, and formal module validation are five distinct milestones, and conflating any two of them is the single most common mistake in a PQC migration timeline.
8. What is still actively changing
The additional-signature evaluation entered Round 3 in May 2026. Its current roster spans different mathematical approaches and explicitly marks HAWK as withdrawn. That's a reminder to check candidate-specific status rather than repeat an earlier cohort count from memory — a candidate's withdrawal doesn't establish that an entire mathematical family has failed, only that this specific design didn't clear the bar. See the NIST Round 3 record.
Hash-based signature work is also evolving past FIPS 205. The April 2026 initial public draft of SP 800-230 proposes additional limited-use SLH-DSA parameters with a hard limit of \(2^{24}\) signatures per signing key. These are draft, constrained-use parameters — not an unrestricted replacement for the FIPS 205 families — and they're a useful reminder that a stateless signature algorithm can still carry a lifetime-use bound an operator must respect. See the SP 800-230 draft.
9. Protocol support is a separate layer again
TLS 1.3's current base specification is RFC 9846, which obsoletes the original RFC 8446. RFC 9954 explains hybrid key exchange as an Informational document — background and rationale, not a normative spec. RFC 10024 is Standards Track and specifies three exact named groups: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024. These identify precise, fully-specified constructions — they don't invite arbitrary concatenation of whatever secrets an application happens to have lying around. See RFC 9846, RFC 9954, and RFC 10024.
A hybrid construction aims to stay secure as long as either component remains secure under its own assumptions. The protocol has to specify exact ordering, encoding, validation, key derivation, transcript binding, and negotiation behavior — getting any one of these wrong quietly breaks the hybrid guarantee even if both underlying primitives are individually sound. The larger key and ciphertext sizes can also affect handshake transport and misbehaving middleboxes, which is an operational concern independent of the cryptography. Observability tooling needs to record the group actually negotiated on the wire, not merely a server configuration option or the list of algorithms a library happens to be compiled with.
For identity, RFC 9881 defines how ML-DSA is represented inside X.509 certificates. That alone doesn't settle live TLS authentication support, though: as of this writing the corresponding ML-DSA-in-TLS-handshake document remains an Internet-Draft, even with its publication process well advanced. Certificate encoding, handshake signature support, CA issuance capability, and relying-party policy all have to independently catch up before this is end-to-end usable. See RFC 9881 and the TLS ML-DSA draft.
10. What engineers can actually run today
OpenSSL is a useful native learning path with no extra dependencies. As of this checkpoint, 4.0.2 is the latest stable release, with 3.5.8 on the 3.5 LTS branch and 4.1.0-alpha1 as a prerelease. The versioned 3.5 documentation includes ML-KEM, ML-DSA, and SLH-DSA in the default provider, with openssl pkeyutl examples for their operations directly from the command line. See OpenSSL downloads, the provider documentation, and the command documentation.
Part 15's lab has you inspect the installed executable and its providers first, using isolated files and explicit version pins rather than overwriting system cryptographic libraries. An algorithm's presence in a provider doesn't demonstrate that a complete application actually uses it, that its module carries a particular validation status, or that a remote peer will interoperate with it — each of those needs a separate, direct observation, not an inference from "the library supports it."
Open Quantum Safe's liboqs remains useful for prototyping and experimentation across a wide range of candidate and standardized algorithms. PQ Code Package's mlkem-native is useful for studying a maintained, assurance-focused implementation and its stated verification coverage. Neither project's name is a substitute for checking the exact release, target platform, build configuration, and threat model you actually care about. Formal verification also has a bounded scope: a proof about constant-time arithmetic or memory safety says nothing about whether an application's authentication policy is sound. See liboqs and mlkem-native.
11. Deployment lessons before the labs
Google's public account of moving Chrome from a preliminary Kyber draft to final ML-KEM illustrates exactly why client/server coordination is the hard part, not the math. Signal's SPQR work shows that protecting the beginning of a conversation and recovering security partway through an already-running conversation are two genuinely different engineering goals, not one. Apple's PQ3 writeup supplies a third example, focused on ongoing rekeying and continuous protocol analysis rather than a one-time switch. These are dated engineering accounts of specific systems — not a global completion certificate that PQC migration is "done." See Google's account, Signal's SPQR post, and Apple's PQ3 post.
For our records service, the first useful deliverable isn't a library upgrade — it's a boundary map. Identify exactly where TLS terminates and where it starts again on the other side of any proxy, how database and backup keys are protected and by what, and who signs client releases with which key. Attach an explicit owner and update mechanism to each boundary. A gateway upgrade can be a genuinely valuable milestone while three other boundaries remain fully classical — accurate scope makes that real progress easier to communicate honestly, not less impressive.
12. Your route through the rest of the course
Parts 2–4 build the vocabulary: cryptographic primitives, the quantum threat model in full resource-cost detail, and small worked mathematical examples. Parts 5–6 map the PQC families and build lattice intuition from LWE up to Module-LWE. Parts 7–10 study ML-KEM, ML-DSA, SLH-DSA, and the algorithms beyond the first three standards. Parts 11–12 move those primitives into real TLS handshakes and X.509 digital trust. Parts 13–15 cover implementation security (side channels, faults, randomness), performance engineering, and a reproducible hands-on lab. Parts 16–18 turn all of that into migration engineering, real deployment case studies, and a sustained learning roadmap.
Read the course index for the complete sequence and current publication status. The goal isn't to memorize acronyms — by the end, you should be able to explain a protocol flow, inspect an implementation's actual assumptions, reproduce a measurement yourself, and clearly separate what a security claim establishes from what it doesn't.
A service negotiates X25519MLKEM768 but presents an ECDSA certificate. Is that "fully post-quantum"?
No. The negotiated group concerns key establishment only; the certificate and its full authentication path have to be evaluated completely separately (§6, §9). That said, this is still meaningful, real protection against passive traffic collection for harvest-now-decrypt-later purposes — it's a legitimate intermediate step, just not a complete one.
Does shipping a newer crypto library version prove a given connection used PQC?
No. The application in front of it may load a different library entirely, disable the relevant provider, or negotiate a different, classical group at runtime. The only way to know is to inspect the actual running process and the actual handshake it produced — not the library's changelog.
Should migration wait until \(Q\) — the time until a relevant quantum computer exists — is known precisely?
No (§5). That uncertainty is genuine and won't resolve on a convenient schedule, but \(S\) (how long your data needs to stay secret) and \(M\) (how long your migration will actually take) are both things you can measure today, and together they already tell you your exposure. Waiting for certainty about \(Q\) just consumes the time budget \(M\) was supposed to use.
Takeaways
- "Is this quantum-safe" is at least four separate questions: which algorithm, which specific implementation, which protocol, and which deployment boundary. Compressing them into one label is where migration plans fail.
- Shor breaks the algorithmic assumption behind RSA/ECC; Grover only halves symmetric-key exponents. These require completely different migration strategies — a full primitive swap for public-key crypto, a parameter review for symmetric crypto.
- Harvest-now-decrypt-later means migration urgency doesn't wait for a working quantum computer. The \(S + M > Q\) heuristic reframes the question around data you can actually measure today.
- A KEM establishes a shared secret; it does not authenticate anyone. Hybrid key establishment plus a still-classical certificate chain is a real, useful intermediate architecture — not complete post-quantum authentication.
- FIPS 203, 204, and 205 are final (Aug 2024). Falcon/FN-DSA and HQC are selected but still standardizing. Additional-signature Round 3 and SP 800-230's limited-use SLH-DSA parameters are still actively moving.
- Presence of an algorithm in a library is not evidence it's used in production. Inspect the running process and the negotiated handshake directly.
References & further reading
- NIST — Post-Quantum Cryptography project overview — canonical status page for the whole standardization effort.
- FIPS 203 (ML-KEM) · FIPS 204 (ML-DSA) · FIPS 205 (SLH-DSA) — the three finalized standards, Aug 2024.
- NIST IR 8545 — HQC selection report — fourth KEM, code-based, selected Mar 2025.
- Shor, "Polynomial-Time Algorithms..." · Grover, "A fast quantum mechanical algorithm..." — the two algorithms behind §4.
- Mosca — the S+M>Q migration heuristic — source for §5.
- NIST SP 800-227 — KEM usage guidance — formal KEM interface, §6.
- RFC 9846 (TLS 1.3) · RFC 9954 (hybrid rationale) · RFC 10024 (named hybrid groups) · RFC 9881 (ML-DSA in X.509) — §9 protocol references.
- liboqs · mlkem-native — §10 implementations for hands-on work.
- Google — Kyber to ML-KEM in Chrome · Signal — SPQR · Apple — iMessage PQ3 — §11 real deployment accounts.