Chapter 56 — Project 4: a post-quantum readiness audit

Brief

Produce the deliverable a real organisation needs to start its PQC migration (Part 6): a complete cryptographic inventory of SecureShop, a risk-ranked migration plan, and a working proof-of-concept of hybrid key exchange plus a crypto-agile signature path.

Phase 1 — Cryptographic inventory

   Enumerate EVERY use of cryptography across SecureShop:
     - TLS: every endpoint (shop, admin, orders-api, DB, monitoring,
       webhooks out). Protocol, cipher, KEX group, cert key type/size,
       signature alg. (openssl s_client / testssl.sh / sslyze in a loop.)
     - SSH: host + user key types; Kex/Ciphers/MACs. (ssh-audit.)
     - Application: JWT alg; password hash; any AES/RSA/ECDH in code;
       token generation; HMAC usage. (grep + dependency review.)
     - At rest: DB/disk/backup encryption; how keys are wrapped (KMS?).
     - Secrets manager: its own transit + storage crypto.
     - Supply chain: artifact signing (your Ch 22 tool), image signing,
       package signature verification.
     - Third parties: payment gateway, email, CDN -- what do their APIs
       use, and do you pin anything?

   For each row record: component | algorithm | key size/params | key
   location | who can rotate it | data confidentiality lifetime |
   HNDL-sensitive? (does 2035 disclosure matter?) | quantum-vulnerable?
   (RSA/DH/ECC = yes; AES-256/SHA-384 = no) | crypto-agile? (algorithm in
   config vs hard-coded).

Phase 2 — Risk ranking and migration plan

   Prioritise by  (secrecy-lifetime) x (exposure) x (difficulty-to-change).
   Produce a phased plan mapping to Ch 25's playbook:

     Phase 0  inventory (Phase 1 above) -- done
     Phase 1  confirm symmetric/hash are already PQ-safe (AES-256,
              SHA-384+) -- list any that aren't
     Phase 2  crypto-agility gaps: every place an algorithm is hard-coded,
              every stored blob without an algo/version tag, every key
              store without an abstraction -> concrete tickets
     Phase 3  enable hybrid KEX (X25519MLKEM768) on TLS endpoints,
              starting with the HNDL-sensitive customer path; measure
              handshake size/latency/CPU and any middlebox breakage
     Phase 4  PQ signatures: plan ML-DSA-65 for artifact/image signing
              (hybrid with Ed25519 first); SLH-DSA for anything with a
              decade-plus verifier lifetime (none in SecureShop unless you
              added the IoT scanners -- if so, prioritise)
     Phase 5  deprecate classical-only per NIST IR 8547 dates (2030/2035)

   For each item: owner, dependency (library/CA/vendor), effort, target
   quarter, and the risk if deferred.

Phase 3 — Proof of concept

   1. HYBRID TLS: stand up shop.securesh.op with OpenSSL 3.5+ (or a
      Caddy/nginx build that supports it) negotiating X25519MLKEM768.
      Prove it with `openssl s_client -groups X25519MLKEM768` and a
      packet capture showing the larger ClientHello. Benchmark vs X25519
      (handshakes/sec, bytes on the wire, p50/p99 latency).

   2. HYBRID SSH: confirm `mlkem768x25519-sha256` (or
      `sntrup761x25519-sha512`) is negotiated between two modern OpenSSH
      endpoints; pin it in sshd_config; show the negotiated kex in `ssh -v`.

   3. CRYPTO-AGILE SIGNING: extend the Ch 22/26 release tool so the
      manifest carries `sig_alg` and supports ed25519, ml-dsa-65, and
      hybrid-ed25519-mldsa65. Demonstrate a migration: sign a release
      ed25519-only, then re-sign as hybrid; show an old verifier still
      accepts the ed25519 sig while a new verifier requires both.
      Tabulate key/sig sizes and sign/verify timings.

   4. ML-KEM by hand: one `openssl pkeyutl -encap/-decap` round trip,
      HKDF the shared secret to an AES-256 key, encrypt a file with it.

Deliverable

~/sec-lab/projects/p4-pq-audit/ with: inventory.csv (or a table in report.md), migration-plan.md (phased, owned, dated), the PoC configs and scripts, benchmark numbers, and an executive summary a non-cryptographer manager can act on.

Definition of done

• Inventory covers TLS, SSH, app-layer, at-rest, secrets, and supply-chain crypto — nothing hand-waved as "probably fine".
• Every row is classified quantum-vulnerable / PQ-safe and HNDL-sensitive / not, with a one-line justification.
• The plan is risk-ranked by the stated formula, phased per Chapter 25, and every item has an owner and a target.
• Working hybrid TLS and hybrid SSH, proven with s_client/ssh -v and a capture, with benchmarks vs classical.
• The release tool signs and verifies ed25519, ML-DSA-65, and hybrid, with a demonstrated migration path.
• An executive summary that states the actual business risk (what data, decrypted when, matters) in plain language.

Rubric (/100)

   Inventory completeness & accuracy ......... 30
   Correct quantum-vuln / HNDL classification  15
   Risk-ranked, phased, owned migration plan . 20
   Working hybrid TLS + SSH with evidence .... 15
   Crypto-agile signing PoC + migration demo . 15
   Executive summary (plain-language risk) ... 5