Day 28: Phase 3 Final Challenge

Phase 3 · August 4, 2026

Agenda (3 hours)

• Complete pqc-demo (90 min): Wire up all subcommands into a polished binary
• Finalize roadmap (60 min): All sections complete, reviewed, ready to send
• Phase 3 reflection (30 min): What changed? What's still fuzzy?

This is the capstone day for Phase 3. The two deliverables represent everything you've learned distilled into working code and actionable guidance.

pqc-demo: Final Binary Spec

pqc-demo
├── kem       -- ML-KEM-768 keygen, encaps, decaps; print key sizes + shared secret
├── dsa       -- ML-DSA-65 keygen, sign, verify; print key/sig sizes
├── hybrid    -- X25519 + ML-KEM-768 combined KEM; print both secrets, combined HKDF output
├── bench     -- Run kem/dsa/hybrid N times, report mean latency + sizes in a table
└── tls       -- Start a rustls-aws-lc-rs server (X25519MLKEM768), connect a client, print negotiated group

All subcommands must compile cleanly on stable Rust with aws-lc-rs and rustls-aws-lc-rs.

pqc-demo: Suggested main.rs Structure

use clap::{Parser, Subcommand};

#[derive(Parser)]
#[command(name = "pqc-demo", about = "Post-quantum crypto demonstrations")]
struct Cli {
    #[command(subcommand)]
    command: Commands,
}

#[derive(Subcommand)]
enum Commands {
    Kem,
    Dsa,
    Hybrid,
    Bench { #[arg(short, default_value_t = 100)] n: u32 },
    Tls,
}

fn main() {
    let cli = Cli::parse();
    match cli.command {
        Commands::Kem    => demo::kem::run(),
        Commands::Dsa    => demo::dsa::run(),
        Commands::Hybrid => demo::hybrid::run(),
        Commands::Bench { n } => demo::bench::run(n),
        Commands::Tls    => demo::tls::run(),
    }
}

pqc-demo: bench Output Format

When you run pqc-demo bench --n 1000, aim for output like:

Algorithm          Op         Iters  Mean (µs)  Pub key    Priv key   Extra
---------------------------------------------------------------------------
ML-KEM-768         KeyGen      1000      42.3    1184 B     2400 B     —
ML-KEM-768         Encaps      1000      56.1       —          —    1088 B (ct)
ML-KEM-768         Decaps      1000      61.8       —          —       —
ML-DSA-65          KeyGen      1000     210.4    1952 B     4032 B     —
ML-DSA-65          Sign        1000     580.2       —          —    3293 B (sig)
ML-DSA-65          Verify      1000     190.6       —          —       —
X25519+ML-KEM-768  Combined    1000     102.5    1216 B        —    1120 B (ct)

This table becomes Appendix A of your migration roadmap.

pqc-migration-roadmap.md: Completion Checklist

Go through each section — is it complete?

• [ ] §1 Executive Summary — written last; 3–5 sentences, non-cryptographer readable
• [ ] §2 Threat Assessment — assets at risk, crypto inventory, HNDL window, quantum timeline
• [ ] §3 Algorithm Recommendations — ML-KEM-768, ML-DSA-65, AES-256-GCM/SHA-384, rationale
• [ ] §4 Migration Architecture — Phase A/B/C with dates and blockers
• [ ] §5 Dependency Map — AWS service table, library table, HSM gaps
• [ ] §6 Performance Impact — handshake overhead, cert size analysis, CA throughput
• [ ] §7 Compliance Calendar — CNSA 2.0 milestones, NIST deprecations, internal dates
• [ ] §8 Open Questions — everything you need to verify when you return
• [ ] Appendix A — bench output table from pqc-demo
• [ ] Appendix B — algorithm reference table (algorithm, FIPS, key sizes, sig sizes)

Appendix B: Algorithm Reference Table

Add this to the roadmap verbatim (fill in any blanks):

Phase 3 Reflection

Answer these four questions in writing (anywhere — a notebook, a comment, a doc):

1. What was most surprising? (One thing you did not expect to learn.)
2. What is still fuzzy? (One concept you could not confidently explain to a colleague.)
3. How does this change your mental model of the provisioning service? (Before vs. after.)
4. What is the single most urgent thing your team should do? (One sentence, actionable.)

These answers are not for anyone else — they're for you to calibrate what Phase 4 and beyond need to reinforce.

Phase 3 in One Sentence Per Week

Complete these:

• Week 1: "Quantum computers threaten classical crypto because _______________."
• Week 2: "ML-KEM works by _______________ and ML-DSA's security comes from _______________."
• Week 3: "Hybrid key exchange is necessary because _______________ and the wire format looks like _______________."
• Week 4: "The migration path for my provisioning service is _______________, blocked on _______________ until _______________."

What You've Built: Phase 3 Deliverables

By end of today you should have:

mob_learning/
├── pqc-demo/           ← Rust binary: kem, dsa, hybrid, bench, tls subcommands
└── pqc-migration-roadmap.md   ← Complete, tech-lead-ready migration plan

pqc-demo demonstrates that you can work with PQC algorithms in Rust at a production-relevant level.

pqc-migration-roadmap.md demonstrates that you understand not just the algorithms but the migration strategy for a real AWS provisioning service — the thing your team actually needs.

Looking Ahead: Phase 4 (Aug 5–25)

SPIFFE/SPIRE and workload identity

The question Phase 4 answers: how do services authenticate to each other at cloud scale without managing static certificates?

SPIFFE defines a URI-based workload identity (spiffe://trust-domain/path).
SPIRE implements it: a short-lived X.509 SVID issued automatically on attestation.

Why this matters for you: a Lambda provisioning service is a workload. SPIRE can issue it a short-lived cert tied to its IAM role, function ARN, or OIDC token — eliminating the long-lived static credentials that make HNDL attacks valuable.

Phase 4 also intersects PQC: SPIRE SVIDs will eventually need ML-DSA signing.

Challenge Assignment

1. Complete pqc-demo — all five subcommands compile and produce correct output
2. Run pqc-demo bench --n 1000 and paste the output table into pqc-migration-roadmap.md Appendix A
3. Finalize all sections of pqc-migration-roadmap.md — every section filled in
4. Write the four reflection answers (anywhere)
5. Complete the "one sentence per week" summaries above

When done: read the roadmap from top to bottom as if you are your tech lead seeing it for the first time. Would you want to act on it? Would you trust the recommendations?