Learn enough theory to understand the security claim, enough implementation to test its boundaries, and enough deployment engineering to preserve it in a real system. This closing chapter connects those skills through seven stages with exit criteria, 30 curated resource sections, and concrete 30-day, 90-day, and six-month plans with hands-on projects. Every resource below carries its own difficulty, cost, and status label — current, foundational, or archival — because the discipline this whole course has built is exactly the one you now apply to your own further reading: distinguish a claim's source, scope, status, and evidence before acting on it.
1. How to use this roadmap
The course has moved from the quantum threat through mathematics, algorithms, protocols, implementation security, performance, and migration. This final chapter is a reusable study guide. Begin at the earliest stage whose exit exercise you cannot complete. An experienced infrastructure engineer may move quickly through networking and still need time on security games; a mathematics student may have the opposite starting point.
All linked material is free to read unless an entry says otherwise; commercial books, hosted course enrollment, conference attendance, and hardware can cost money. A repository license governs reuse even when the source is publicly accessible. The plans and project exercises below are original cvam.sight course material.
Keep a learning notebook with five fields: question, source/version, assumptions, reproducible artifact, and unresolved issue. Reading time alone is a poor progress metric. A diagram you can explain, a negative test you can justify, or a measured result another person can reproduce provides stronger evidence of understanding than hours logged.
2. Seven stages and their exit criteria
| Stage | Focus | Evidence you're ready to continue |
|---|---|---|
| A | Foundations | Explain confidentiality, authenticity, probability, modular arithmetic |
| B | Applied cryptography | Trace an authenticated connection and separate its security properties |
| C | PQC mathematics | Work through noisy arithmetic and an NTT toy example |
| D | Standards | Distinguish final algorithms, protocol profiles, drafts, and errata |
| E | Implementation | Reproduce positive and negative tests with an identified build |
| F | Deployment | Produce an owned migration plan for a concrete trust boundary |
| G | Research | Critique a paper and reproduce one narrowly scoped result |
Fig. 1 — An infrastructure engineer may skip straight to D; a mathematics student may need to start at A despite deep C-level comfort. The exit exercise, not the stage letter, decides readiness.
2.1 Stage A — Foundations
Study basic cryptography, networking and TLS terminology, modular arithmetic, and discrete probability. Start with Part 2, the mathematics review in Rosulek's book below, and Part 4. Work small examples by hand before using a script. Distinguish a uniformly random sample from a predictable value that merely looks irregular.
Exit exercise: draw a browser-to-service connection, label the data being protected, and explain why encryption without authentication is insufficient. Compute a modular inverse in a small prime field and describe the probability experiment behind a security claim. Do not advance by memorizing algorithm names alone.
2.2 Stage B — Modern applied cryptography
Learn AEAD, key derivation, elliptic-curve key exchange, signatures, PKI, and TLS 1.3. Use the applied books and RFC directory (§4) to connect primitives to protocol roles. Understand nonce requirements, domain separation, certificate trust, hostname validation, and the difference between an established secret and an authenticated peer.
Exit exercise: trace a handshake from key shares through derived traffic keys and certificate verification. Identify which component protects stored traffic against a future quantum adversary and which authenticates the server. Explain why changing a signature algorithm does not retroactively protect an old recorded key exchange.
2.3 Stage C — PQC mathematics
Study lattices, LWE, Module-LWE, Module-SIS, polynomial rings, the NTT, coding theory, and hash-based signatures. Parts 4–9 supply a gradual route; Peikert's notes (§7) provide the next level. Keep the distinction between a mathematical assumption, a reduction, and concrete parameter selection explicit.
Exit exercise: reproduce the small negacyclic multiplication and NTT comparison from Part 6. Explain what noise contributes to an LWE construction, why too much noise harms correctness, and why a toy parameter set has no practical security. Compare the assumptions underlying a lattice KEM and a hash-based signature without claiming either is unconditionally secure.
2.4 Stage D — Standards
Read FIPS 203, 204, and 205 alongside SP 800-227 and the relevant final RFCs. Track FN-DSA/FIPS 206 and HQC through NIST's project pages (§3): their standardization work must not be described as an already-final FIPS at this checkpoint (Part 10). Read potential errata as potential errata, and record the version your implementation follows.
Exit exercise: create a one-page status register containing document identifier, publication state, date, algorithm role, and implementation implications. Explain why an algorithm standard, a protocol profile, and a validated cryptographic module (Part 13 §12) are different artifacts. Recheck the register before using it in procurement or architecture review.
2.5 Stage E — Implementation
Run the isolated OpenSSL laboratory (Part 15), then examine a maintained high-assurance implementation and an OQS prototype. Study test vectors, malformed input, randomness, benchmarking, and constant-time analysis. Read build flags and provider selection as part of the experiment, rather than assuming an executable name identifies its cryptographic behavior.
Exit exercise: reproduce encapsulation agreement, signature verification, modified-message rejection, wrong-context rejection, hybrid TLS, and certificate identity checks. Save public build metadata and sanitized results. Explain why tests, proofs, algorithm validation, and module validation offer different kinds of assurance (Part 13).
2.6 Stage F — Protocols and deployment
Study TLS, SSH, IPsec/IKEv2, X.509, PKI, code signing, migration, and cryptographic agility. Map termination points, verification dependencies, update paths, and rollback behavior. Use Part 16 to turn those observations into owned work packages.
Exit exercise: produce a migration plan for one real or fictional service, including client populations, key establishment, identity, suppliers, telemetry, exceptions, and retirement. Show how a successful test of the public edge differs from coverage of the origin and internal links. Define a negative test that detects unintended fallback.
2.7 Stage G — Research
Read recent papers on side channels, formal verification, new signature candidates, alternate KEMs, protocol composition, and post-quantum ratcheting. Follow a small number of primary sources consistently. Learn to identify the threat model and claimed contribution before inspecting graphs or adopting implementation advice.
Exit exercise: reproduce one small result, compare it with the paper's stated environment, and explain discrepancies. Write a review separating mathematical claims, experimental evidence, deployment assumptions, and limitations. A careful failed replication with a clear diagnosis can be more valuable than an unexplained matching number.
3. Official standards
- FIPS 203: ML-KEM Standard — NIST. Advanced; free; current final standard with a potential-errata notice. The normative starting point for ML-KEM interfaces, parameters, input checks, and decapsulation behavior.
- FIPS 204: ML-DSA Standard — NIST. Advanced; free; current final standard with potential errata. Read it for ML-DSA encoding, context handling, sampling, and verification requirements.
- FIPS 205: SLH-DSA Standard — NIST. Advanced; free; current final standard. Use it to understand SLH-DSA's layers and parameter tradeoffs rather than inferring them from SPHINCS+ summaries.
- SP 800-227: KEM Recommendations — NIST. Intermediate; free; current final guidance. Connects KEM mechanisms to safe use and the responsibilities of the surrounding application.
Read the publication landing pages before downloading PDFs: notices and revisions may be clearer there than in an old local copy. Keep a dated link in your notes.
4. NIST project pages
- Post-Quantum Cryptography project — NIST. Beginner; free; current. The primary entry point for selection decisions and standardization updates. Check FN-DSA/HQC status before describing either as final.
- Migration to PQC — NIST NCCoE. Intermediate; free; current. Useful for discovery and interoperability questions algorithm specs don't answer.
5. IETF RFCs
- RFC 9846: TLS 1.3 — obsoleting RFC 8446. Read the handshake and key schedule before adding hybrid groups.
- RFC 10024: hybrid ECDHE–ML-KEM for TLS 1.3 — the standardized groups from Part 11.
- RFC 9954: hybrid key-establishment framework — organizing terminology, Informational.
- RFC 9881: ML-DSA in X.509 — the certificate profile from Part 12.
- RFC 9370: Multiple Key Exchanges in IKEv2 — a PQ-relevant IPsec extension.
6. Recommended and free books
- Introduction to Modern Cryptography, 3rd ed. — Katz & Lindell. A rigorous route through definitions and proofs.
- A Graduate Course in Applied Cryptography — Boneh & Shoup. Free, foundational; its age means current PQC standards need separate reading.
- The Joy of Cryptography — Rosulek. Free online; builds the provable-security mindset from scratch.
Pick one main book and solve its exercises. Collecting several books without working through any of them rarely repairs a conceptual gap.
7. University lecture notes and courses
- Lattices in Cryptography — Chris Peikert. A focused bridge from linear algebra to lattice constructions.
- EECS 598, 2015 — Peikert. Archival syllabus; follow the newer notes link for corrections.
- Online Cryptography Course — Dan Boneh, Stanford. Organized path through symmetric encryption, integrity, public-key concepts.
- cvam.sight PQC course — this 18-part course, used as the applied spine.
A course certificate is optional for this roadmap. The required output is an explanation and a reproducible exercise, not a purchase.
8. Video lectures and conference talks
- Boneh's cryptography videos — start with probability review, authenticated encryption, timing-attack lessons.
- IACR video portal — verify event, author, and paper version before taking notes on a talk.
- Sixth PQC Standardization Conference — archival Sept 2025 event connecting implementations, hardware, and candidate analysis.
- NIST PQC status, MPTS 2026 — Dustin Moody. Verify subsequent announcements before treating a projected date as achieved.
Watching is most effective after a first reading: pause when a speaker skips a proof step and reconstruct that step independently.
9. Research and seminal papers
- Mosca — Cryptography in an Era of Quantum Computers — the \(S{+}M{>}Q\) framing from Part 1 §5.
- Gidney — factor 2048-bit RSA... — a resource-estimation study, not evidence such a machine exists (Part 3 §9).
- Shor · Grover — the two algorithmic threats from Part 3.
- Regev — LWE — read the reduction and parameter conditions, not only the abstract.
10. Implementation and side-channel papers
- pqm4: Benchmarking on Microcontrollers — Kannwischer et al. Its candidate roster is not today's standardized portfolio.
- Kyber round-3 specification — use FIPS 203 for final ML-KEM behavior; don't assume identical byte-level interfaces.
- KyberSlash — Bernstein et al. (Part 13 §3). Reproduce only a controlled educational example.
- HACL* — verified low-level cryptography; background for assurance methods, not a proof of every PQC implementation.
11. Open-source projects, libraries, and tools
- ACVP Server — running local vectors does not grant an official validation certificate.
- Wycheproof — verify your exact algorithm and encoding are actually covered.
- OpenSSL 3.5 docs — match manuals, release, providers, and build config when reproducing a command (Part 15).
- mlkem-native — read the proof scope and excluded attacks before a broad security claim (Part 13 §11).
- liboqs — prototype availability is not a production-readiness endorsement.
- openssl s_client · openssl verify · openssl speed — the exact commands used throughout Parts 7–15.
- pqm4 · dudect — Cortex-M4 benchmarks and statistical timing-leak testing (Part 13 §10, Part 14 §9).
- CycloneDX CBOM · CBOMkit — inventory tooling (Part 16 §4).
Maintenance is a selection criterion that must be rechecked: inspect releases, security reporting, supported platforms, and the exact revision. A recognizable project name is not a substitute for dependency ownership.
12. Communities, conferences, and researchers
- NIST PQC email list — distinguish a contributor's proposal from an adopted decision.
- IETF PQUIP working group — protocol integration discussions and archived reasoning.
- IACR conferences — CRYPTO, EUROCRYPT, ASIACRYPT, CHES.
- Chris Peikert — lattice research and surveys beyond algorithm descriptions.
Before posting a question, search the archive and identify the exact document version and unresolved point. Never include production secrets or private connection logs in a public discussion. Select authors across implementation, theory, and protocol work — following one specialty exclusively can make another layer's constraints invisible.
13. Search keywords for future research
Use Cryptology ePrint with queries such as "ML-KEM implicit rejection," "ML-DSA masking," "module lattice concrete security," "HQC decoding failure," "constant-time division," and "verified NTT." Read revision and publication information before citing a result.
Use IETF Datatracker for "hybrid key exchange," "ML-DSA TLS," "post-quantum IKEv2," and "post-quantum authentication." A search result can be an expired draft — inspect its state and successors.
For messaging, start with the ML-KEM Braid specification and search "post-quantum ratchet," "post-compromise security," and "asynchronous KEM." Record the compromise and message-delivery model alongside the mechanism.
14. A 30-day learning plan
Resource: the cvam.sight course index. Suggested effort: five to seven hours per week. These are planning estimates, not promises of mastery.
Days 1–7: Read Parts 1–3 and introductory book sections. Draw the roles of encryption, signatures, key exchange, and certificate trust. Explain harvest-now-decrypt-later without asserting a quantum arrival date. Deliver a one-page threat model and a glossary in your own words.
Days 8–14: Read Parts 4–6. Run the arithmetic toys, then change a small input and predict the output before executing. Deliver a hand-worked negacyclic product and a short explanation of LWE noise.
Days 15–21: Read Parts 7–9 and run the KEM and signature labs. Record public sizes and each negative-test outcome. Deliver a comparison of KEM and signature interfaces, including why an invalid ML-KEM ciphertext is not handled like a signature verification failure.
Days 22–30: Read Parts 11, 12, and 16. Reproduce the hybrid connection and certificate tests. Deliver a small migration inventory and a five-minute explanation of the difference between hybrid confidentiality and post-quantum authentication.
15. A 90-day learning plan
Resource: Part 15's Hands-On Lab. Plan roughly six to eight hours weekly, adjusting for prior knowledge.
Month 1: Complete the 30-day foundation path. Maintain a dated standards register and a reproducible environment manifest. Ask another engineer to follow one lab using only your notes; missing assumptions become documentation fixes.
Month 2: Work through Parts 10–15. Read one implementation paper and KyberSlash. Repeat a benchmark under controlled conditions, retain raw runs, and report variation. Deliver a report that separates functional, performance, and leakage evidence.
Month 3: Study Parts 16–18 and one deployment account (Part 17). Design a canary rollout for a test service, including telemetry and a time-limited rollback exception. Deliver an architecture decision record, evidence matrix, and presentation explaining what remains unverified — the goal is a defensible pilot proposal, not an unsupported claim of organization-wide readiness.
16. A six-month advanced roadmap
Resource: Part 13 and Peikert's notes (§7). Budget eight to ten hours weekly where feasible, and narrow the research question early.
Months 1–2: Consolidate the 90-day path's prerequisites at a deeper level. Derive selected equations, read the normative algorithm descriptions, review the implementation's validation boundaries. Build a reproducibility package another person can execute.
Month 3: Choose one specialty: constrained-device verification, constant-time arithmetic, protocol composition, or inventory coverage. Read three directly relevant papers and write a comparison of their models.
Month 4: Reproduce one baseline. Pin revisions and record failed attempts. For hardware measurements, include board and clock details; for proofs, record the statement, trusted components, and toolchain.
Month 5: Make one small extension — a new compiler comparison, a documented negative test, or a clearer coverage metric. Compare against the baseline using the same methodology. Investigate surprising results before presenting them as improvements.
Month 6: Package code, data, assumptions, and limitations into a readable report. Obtain peer review and resolve substantive feedback. A suitable outcome is a reproducible technical note or well-scoped upstream contribution — publication acceptance is neither guaranteed nor required for the learning objective.
17. Suggested hands-on projects
- Hybrid handshake evidence notebook — Intermediate. Record group, certificate algorithm, identity result, and classical-only rejection. Completion requires another person reproducing both success and failure from your notes.
- Certificate compatibility matrix — Intermediate. Test controlled chains and identities; report exact verifier versions. Completion requires explaining every rejection without disabling validation.
- Benchmark reproduction package — Advanced. Preserve raw runs, environment metadata, and a variability summary. Completion requires separating primitive throughput from end-to-end latency.
- CBOM coverage experiment — Intermediate. Seed a toy service with known cryptographic dependencies and compare discovery output against ground truth. Completion requires reporting false negatives.
- Assurance boundary review — Advanced. Read one implementation's proof and test documentation. Completion requires a table of established properties, trusted assumptions, unsupported platforms, and excluded attacks.
18. Suggested paper-reading order
- Mosca: identify the migration decision that follows from long data lifetimes. Deliver a timeline with explicitly uncertain quantities.
- Shor, then Grover: distinguish the algorithmic threats. Deliver a comparison of problem structure, query/resource assumptions, and affected cryptographic roles.
- Regev: understand the LWE foundation. Deliver a map of the reduction's inputs, assumptions, and conclusion; mark steps you cannot yet justify.
- Kyber supporting documentation, then FIPS 203: connect design rationale to the final interface. Deliver a list of historical material that must not be copied into a current implementation unchanged.
- pqm4 implementation study: learn how platform limits shape feasibility. Deliver a reproduction plan naming the hardware, compiler, and algorithm snapshot.
- KyberSlash, then HACL*: compare an implementation failure with a verification methodology. Deliver a claim-by-claim assurance analysis that does not equate the two papers' scope.
- A recent paper in your chosen specialty: inspect its revisions, code, and limitations. Deliver one reproducible result and one precise open question suitable for further work.
Where should a complete beginner actually start?
Stage A's exit exercise (§2.1): if you can draw the security roles in a browser-to-service connection and compute a modular inverse by hand, skip to Stage B. If not, start with Part 2 of this course.
Is a formal course certificate necessary to complete this roadmap?
No (§7). The required output is an explanation and a reproducible exercise — a course certificate is optional and doesn't substitute for either.
How do I know when a resource is too old to trust?
Check its labeled status (§1): current, foundational, or archival. An archival source (like Kyber's round-3 spec) is still valuable for design rationale, but FIPS 203 governs final ML-KEM behavior — never copy old byte-level interfaces from an archival source into a current implementation.
Takeaways
- Start at the earliest stage whose exit exercise you can't complete — not necessarily Stage A. The exit exercise, not the stage letter, is the actual readiness test.
- Every resource carries a status label for a reason — current, foundational, or archival changes how you're allowed to use it, especially for byte-level implementation details.
- Pick one main book and solve its exercises — collecting resources without working through any of them doesn't repair a conceptual gap.
- A reproducible artifact beats reading time as a progress metric — a diagram you can explain, a negative test you can justify, a result another person can reproduce.
- The 30/90-day/six-month plans build toward a defensible pilot proposal, not organization-wide readiness — that distinction runs through every part of this course.
- The durable skill is disciplined translation — from mathematical assumptions to standardized mechanisms, from mechanisms to implementations, from implementations to deployed systems — maintained as standards and libraries keep changing.
19. Keep the learning path connected to evidence
Before calling a stage complete, answer three questions without looking them up: what property am I trying to establish, what assumptions does it depend on, and what evidence would reveal a failure? If the answers are vague, repeat the relevant exercise rather than moving to a more fashionable algorithm.
The course's central skill is disciplined translation: from mathematical assumptions to standardized mechanisms, from mechanisms to implementations, and from implementations to deployed systems. Maintain those connections as the standards and libraries change. Your durable output is a body of explanations, tests, and owned decisions that can be revised when new evidence arrives — that's the whole course, distilled into one habit.