Build a cryptographic inventory/CBOM with OpenSSL 3.5+, deploy hybrid post-quantum key exchange (X25519MLKEM768) on TLS/VPN/SSH endpoints, generate ML-KEM/ML-DSA keys and PQC/hybrid certificates, and prioritize migration by harvest-now-decrypt-later (HNDL) exposure per NIST SP 1800-38. Use when inventorying enterprise cryptography for quantum-readiness, enabling hybrid PQC key exchange, or issuing and verifying PQC/hybrid certificates.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
Build a cryptographic inventory/CBOM with OpenSSL 3.5+, deploy hybrid post-quantum key exchange (X25519MLKEM768) on TLS/VPN/SSH endpoints, generate ML-KEM/ML-DSA keys and PQC/hybrid certificates, and prioritize migration by harvest-now-decrypt-later (HNDL) exposure per NIST SP 1800-38. Use when inventorying enterprise cryptography for quantum-readiness, enabling hybrid PQC key exchange, or issuing and verifying PQC/hybrid certificates.
Scope and Authorization: This skill describes defensive cryptographic-migration engineering on systems you own or operate. Cryptographic discovery scanning can touch sensitive key material and production traffic — run inventory tooling only with authorization and in line with your organization's change-management and data-handling policies.
Overview
A cryptographically relevant quantum computer (CRQC) running Shor's algorithm will break the public-key cryptography that secures almost all of today's communications and signatures: RSA, finite-field and elliptic-curve Diffie-Hellman (DH/ECDH), and ECDSA. Symmetric primitives (AES) and hashes (SHA-2/3) are only weakened (Grover gives a quadratic speedup, mitigated by larger key/output sizes), but asymmetric algorithms are catastrophically broken. The most urgent threat is harvest-now, decrypt-later (HNDL): adversaries capturing encrypted traffic today to decrypt once a CRQC exists, which puts long-lived secrets (health records, state secrets, intellectual property, root-of-trust keys) at risk now.
On 13 August 2024 NIST finalized the first post-quantum standards: FIPS 203 (ML-KEM, Module-Lattice KEM, formerly CRYSTALS-Kyber) for key establishment, FIPS 204 (ML-DSA, Module-Lattice digital signatures, formerly CRYSTALS-Dilithium), and FIPS 205 (SLH-DSA, the stateless hash-based signature scheme SPHINCS+). The migration playbook (NIST SP 1800-38, Migration to Post-Quantum Cryptography) is: (1) build a cryptographic inventory / CBOM, (2) prioritize by HNDL exposure and crypto-agility, (3) deploy hybrid schemes (a classical algorithm AND a PQC algorithm combined, e.g. X25519MLKEM768) so a break in either leg does not compromise the session, and (4) re-key and rotate.
This skill maps to ATT&CK T1573 – Encrypted Channel: the same cryptographic channels adversaries abuse for stealthy C2 are the channels defenders must make quantum-resistant; understanding the algorithms in use is foundational to both attack detection and defensive migration. The NIST CSF outcome is PR.DS-02 (data-in-transit protection) — and by extension data-at-rest for HNDL-sensitive stores.
When to Use
When building an enterprise cryptographic inventory / Cryptography Bill of Materials (CBOM) for quantum-readiness.
When prioritizing which systems must migrate first based on data lifetime and HNDL exposure.
When enabling hybrid post-quantum key exchange (X25519MLKEM768) on TLS endpoints, VPNs, or SSH.
When issuing PQC or hybrid certificates and testing PQC signature verification.
When evaluating crypto-agility — the ability to swap algorithms without re-architecting applications.
Prerequisites
OpenSSL 3.5.0 or later, which ships native ML-KEM, ML-DSA, and SLH-DSA support:
openssl version # expect 3.5.0+
openssl list -kem-algorithms | grep -i mlkem
openssl list -signature-algorithms | grep -i mldsa
For OpenSSL 3.0–3.4, the Open Quantum Safe oqs-provider plus liboqs:
(Optional) A CBOM generator: CycloneDX cdxgen, or cbomkit-theia for container/directory crypto discovery.
Objectives
Produce a cryptographic inventory (CBOM) of algorithms, key sizes, certificates, and protocols in use.
Classify assets by quantum vulnerability and HNDL exposure and prioritize migration.
Stand up and verify hybrid X25519MLKEM768 key exchange on a TLS endpoint.
Generate ML-KEM and ML-DSA keys and a PQC/hybrid certificate, and verify signatures.
Establish a crypto-agility baseline and a re-keying / rotation plan.
MITRE ATT&CK Mapping
ID
Official Technique Name
Relevance
T1573
Encrypted Channel
Migration secures the encrypted channels (TLS/VPN/SSH) that protect data in transit; cryptographic inventory of these channels also underpins detection of adversary-controlled encrypted C2.
T1573.002
Encrypted Channel: Asymmetric Cryptography
RSA/ECDH key exchange — the exact asymmetric primitives broken by a CRQC and replaced by ML-KEM hybrids.
T1573.001
Encrypted Channel: Symmetric Cryptography
AES and other symmetric ciphers; quantum-weakened by Grover, mitigated by 256-bit keys rather than replacement.
Workflow
1. Confirm PQC algorithm availability
openssl version
# List quantum-safe KEMs and signatures available in this OpenSSL build
openssl list -kem-algorithms | grep -Ei 'mlkem|kyber'
openssl list -signature-algorithms | grep -Ei 'mldsa|dilithium|slhdsa|sphincs'
openssl list -tls-groups 2>/dev/null | grep -Ei 'mlkem'
If using oqs-provider on OpenSSL 3.0–3.4, activate it in openssl.cnf:
Generate a CycloneDX CBOM from a code repo or container with cbomkit-theia / cdxgen:
# Directory / container image crypto discovery
cbomkit-theia dir ./myapp --output cbom.json
# or with cdxgen (Java keystores, certs, source-level algorithms)
cdxgen -t java --include-crypto -o cbom.json ./myapp
Enumerate TLS algorithms and certificate signature schemes across live endpoints with the helper agent.py scan (below), and the public-key strength of any certificate:
For each inventoried asset, record: algorithm, key size, where the key lives, data sensitivity, and data lifetime. Prioritize migration where data_lifetime_years + migration_time > years_until_CRQC (Mosca's inequality). Long-lived confidential data over public networks ranks highest; ephemeral internal traffic ranks lower. Hash-based signature roots-of-trust (firmware signing) are also high priority because they protect long-lived trust anchors.
Reload and verify with the s_client command from step 7 against the live host.
9. Establish crypto-agility and a rotation plan
Centralize algorithm selection (config, not code), record key/cert expiry, and schedule re-keying. Re-run the inventory (step 2) on a cadence to confirm no quantum-vulnerable-only algorithms remain on prioritized assets, and track residual RSA/ECDH usage to zero on high-HNDL paths.
