AI Skill Report Card
Assessing Quantum Security Readiness
Quick Start15 / 15
When asked to assess quantum security, produce these three artifacts in order:
- Quantum Risk Assessment — inventory cryptographic assets, rate exposure
- Migration Plan — concrete steps to swap vulnerable primitives for PQC
- Security Roadmap — phased timeline with milestones and owners
Minimal example request: "Assess our TLS termination layer and internal PKI for quantum risk."
Minimal response shape:
Recommendation▾
Add a third example covering a trickier edge case, e.g. an organization already claiming partial PQC adoption with misconfigured hybrid mode
Quantum Risk Assessment
- Asset: TLS 1.2 termination (RSA-2048 certs) — HIGH risk (harvest-now-decrypt-later on long-lived data)
- Asset: Internal PKI (ECDSA P-256) — HIGH risk
- Asset: AES-256 symmetric session keys — LOW risk (Grover's algorithm only halves effective strength)
Migration Plan
- Inventory all certs/keys and their data-sensitivity lifetime
- Introduce hybrid TLS (X25519 + Kyber768) at edge, dual-stack rollout
- Replace RSA/ECDSA signing with Dilithium3 or Falcon in new PKI issuance
- Re-key long-lived data stores using AES-256 (already quantum-resistant symmetric)
Security Roadmap
- Q1: Crypto inventory + risk scoring complete
- Q2: Hybrid TLS pilot on non-critical services
- Q3: PQC PKI issuance for new certs
- Q4: Full hybrid rollout, sunset pure-classical certs
Workflow14 / 15
Progress checklist for a full engagement:
- Inventory cryptographic assets (algorithms, key sizes, key lifetimes, protocols)
- Classify data sensitivity and required confidentiality lifespan
- Score quantum risk per asset (algorithm type × data lifetime × exposure)
- Map assets to applicable PQC replacements
- Identify hybrid/transitional approaches (classical + PQC combined)
- Draft migration plan with dependency ordering (infra before apps, PKI before endpoints)
- Build phased roadmap with realistic timelines and rollback plans
- Flag crypto-agility gaps (hardcoded algorithms, non-upgradable firmware/HSMs)
1. Risk Assessment Methodology
Classify each cryptographic asset along two axes:
-
Algorithm vulnerability
- Broken by Shor's algorithm (quantum computer with sufficient qubits): RSA, DSA, ECDSA, ECDH, DH
- Weakened but not broken by Grover's algorithm (effective security halved): AES, SHA-2/3, HMAC
- Already quantum-resistant: lattice-, code-, hash-, and multivariate-based schemes (Kyber, Dilithium, SPHINCS+, Falcon, Classic McEliece)
-
Data/key lifetime risk ("harvest now, decrypt later")
- How long must this data or key remain confidential/authentic?
- If lifetime > estimated years-to-cryptographically-relevant-quantum-computer (CRQC), it is at risk today, even if no quantum computer exists yet — adversaries can capture ciphertext now and decrypt later.
Risk score = f(algorithm vulnerability, data lifetime, exposure surface, replaceability difficulty).
Rate each asset: CRITICAL / HIGH / MEDIUM / LOW.
2. Migration Plan Construction
Order migrations by dependency and blast radius:
- Root of trust first — CAs, HSMs, KMS, code-signing roots (hardest to rotate, highest impact)
- Transport layer — TLS/IPsec/VPN using hybrid key exchange (classical + PQC KEM, e.g., X25519+Kyber)
- Authentication/signing — replace RSA/ECDSA signatures with Dilithium or Falcon (SPHINCS+ for high-assurance/low-agility contexts)
- Data-at-rest re-encryption — prioritize by data sensitivity lifetime, not urgency of system
- Long-tail/embedded/firmware — flag anything that can't be updated remotely as a special risk category requiring hardware refresh planning
Always recommend hybrid mode (classical algorithm + PQC algorithm combined) for the transition period — protects against both classical breaks and unforeseen PQC weaknesses.
3. Roadmap Construction
Structure as phases, not just dates (timelines shift, phase order shouldn't):
- Phase 0 – Discovery: crypto inventory, dependency mapping, risk scoring
- Phase 1 – Pilot: hybrid PQC on low-risk/non-customer-facing systems, measure performance impact (larger key/signature sizes, latency)
- Phase 2 – Core Rollout: PKI, TLS termination, VPN, critical auth paths
- Phase 3 – Long Tail: legacy systems, embedded devices, third-party dependencies
- Phase 4 – Sunset: deprecate pure-classical algorithms, enforce PQC-only where policy allows
Each phase gets: entry criteria, exit criteria, owner, rollback plan.
Recommendation▾
Include a brief reference table mapping classical algorithms to their NIST PQC replacements for quick scanning
Examples17 / 20
Example 1: Input: "We use RSA-2048 for VPN authentication and store customer financial records encrypted with AES-256 for 30 years retention." Output:
Recommendation▾
Consider trimming some prose in 'Risk Assessment Methodology' into a more compact bullet/table format to tighten conciseness further
Quantum Risk Assessment
- VPN auth (RSA-2048): CRITICAL — Shor-vulnerable, authentication breach = full trust collapse
- Financial records (AES-256, 30yr retention): MEDIUM — Grover-weakened not broken; 30-year lifetime means re-evaluate key size (AES-256 retains ~128-bit security post-Grover, acceptable) but ensure key-wrapping/KMS layer isn't RSA/ECC (check this separately — often overlooked)
Migration Plan
- Audit KMS/key-wrapping layer protecting the AES-256 keys — if RSA/ECC-wrapped, that's the real CRITICAL exposure, not the AES itself
- Migrate VPN auth to hybrid Dilithium3 + ECDSA signatures during transition
- Re-wrap data encryption keys using Kyber768 KEM instead of RSA-OAEP
- No change needed to AES-256 payload encryption itself
Security Roadmap
- Phase 0 (Month 1): Full inventory of KMS wrapping algorithms — highest-priority discovery item
- Phase 1 (Month 2-3): Hybrid VPN auth pilot on internal-only endpoints
- Phase 2 (Month 4-6): Re-wrap all financial-record DEKs with Kyber768, rotate VPN fleet-wide
- Phase 3 (Month 7+): Vendor/third-party VPN client PQC support verification
**Example 2:**
Input: "Quick check: is SHA-256 quantum-safe?"
Output: "Hash functions like SHA-256 are only weakened by Grover's algorithm, which provides a quadratic
speedup — reducing effective preimage resistance from 256 bits to ~128 bits. That remains computationally
infeasible. SHA-256 is considered quantum-resistant for the foreseeable future; no migration needed.
Contrast with RSA/ECC, which Shor's algorithm breaks entirely (exponential speedup), making those
CRITICAL priority regardless of key size."
Best Practices
- Always distinguish Shor's-algorithm-broken (asymmetric: RSA, ECC, DH) from Grover's-algorithm-weakened (symmetric: AES, SHA) — they need entirely different remediation urgency.
- Default to NIST-standardized algorithms: ML-KEM (Kyber) for key encapsulation, ML-DSA (Dilithium) for signatures, SLH-DSA (SPHINCS+) for stateless hash-based signing, FN-DSA (Falcon) where signature size matters.
- Recommend hybrid schemes during transition — never rip-and-replace classical crypto in one step.
- Treat "harvest now, decrypt later" as a present-tense threat for any data with multi-year confidentiality requirements, not a future problem.
- Emphasize crypto-agility as a roadmap deliverable itself — systems should be designed so future algorithm swaps don't require architecture changes.
- Flag embedded/firmware/HSM constraints early — these have the longest lead times and hardest rollback.
- Note performance tradeoffs explicitly: PQC keys/signatures are larger (Dilithium sigs ~2-4KB vs ECDSA ~64-96 bytes) — this affects bandwidth, storage, and protocol overhead assumptions.
Common Pitfalls
- Don't treat "no quantum computer exists yet" as "no risk today" — harvest-now-decrypt-later attacks are already happening against long-lifetime data.
- Don't recommend pure PQC replacement without a hybrid transition step — PQC algorithms are newer and less battle-tested than classical ones.
- Don't overlook the key-wrapping/KMS layer — teams often secure payload encryption (AES) while ignoring the RSA/ECC wrapping the keys.
- Don't apply uniform urgency — a signing key valid for 90 days is lower priority than a root CA valid for 20 years.
- Don't forget non-TLS cryptography: code signing, firmware signing, database encryption, backup encryption, and inter-service auth (mTLS, JWT signing) are commonly missed in inventories.
- Don't ignore third-party/vendor dependencies — your roadmap is only as fast as your slowest vendor's PQC support timeline.