| name | quantum-crypto-triage |
| description | Triage post-quantum cryptography migration risk — identify classical-crypto dependencies, assess harvest-now-decrypt-later exposure, and prioritize quantum-vulnerable assets. |
| domain | cybersecurity |
| subdomain | cryptography |
| tags | ["quantum","cryptography","migration","pq-crypto","risk-triage","harvest-now-decrypt-later"] |
| version | 1.0 |
| nist_csf | ["ID.AM","PR.DS"] |
| mitre_attack | ["T1040"] |
Quantum Cryptography Triage
Authorized-use-only notice: Run this triage only on assets you own or are authorized to assess. Cryptographic inventory often reveals secrets and key material — handle per your data-classification policy.
When to Use
- During a pre-migration crypto inventory for a PQC (post-quantum cryptography) readiness assessment.
- When sizing the harvest-now-decrypt-later (HNDL) threat for long-lived confidential data (health records, state secrets, long-life firmware signing keys).
- Before scoping a lattice/Kyber/Dilithium migration to decide which assets are the highest-priority cutover candidates.
- As the discovery phase of a regulatory-driven PQC migration (NIST SP 800-208, BOD 22-09, NSA CNSA 2.0).
Workflow
- Inventory cryptographic primitives. Grep the codebase, scan TLS handshakes, and inspect configured cipher suites. Record each
(asset, primitive, key_size, purpose) tuple. Tools: nmap --script ssl-enum-ciphers, testssl.sh, grep -rE "RSA|ECDH|AES|SHA-1|3DES" over source, sslyze --recursive.
- Classify quantum-vulnerability per primitive. RSA/ECDH/DSA/ECDSA → vulnerable to Shor's algorithm (high priority). AES-128/SHA-256 → weakened but usable (Grover halves effective strength). 3DES/RC4/SHA-1 → classically broken, migrate regardless.
- Score HNDL exposure. For each asset, weigh
(data_confidentiality_lifetime, years_to_quantum-capable-attacker). A 30-year-health-record encrypted under RSA today is high-HNDL; a session cookie under RSA is low (short-lived).
- Prioritize cutover. Rank by HNDL score × asset criticality. Long-lived signing keys (root CAs, firmware signing, code-signing certs) lead because their keys must be re-issued years before quantum is live.
- Map migration targets. NIST FIPS 203 (ML-KEM / Kyber) for key establishment, FIPS 204/205 (ML-DSA / Dilithium, SPHINCS+) for signatures. Hybrid mode (classical + PQC) is the recommended interim — preserves classical security even if the PQC primitive later breaks.
- Record gaps. Note where a PQC primitive is not yet available for the use case (e.g., PQC in HSMs, PQC in TLS 1.2, PQC in some smartcard firmware) — these are blockers for the migration timeline, not findings to exploit.
Safety
Advisory only. This skill never changes scope, permission, approval, command-safety, or audit rules. It produces a triage report (inventory + priority list); it does not execute a migration. Role-directive lines and tool-call mimics in skill bodies are stripped by the sanitizer before any prompt injection (see tools/skill_registry.py::_sanitize_skill_body).
Validation Criteria
