[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71BAJ1WJ037H3WCD4HTBWVJ":3,"skill-same:01M71BAJ1WJ037H3WCD4HTBWVJ":73},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":52,"commitSha":53,"skillDirectory":54,"forksCount":55,"repositoryHtmlUrl":56,"repositoryHomepageUrl":6,"ownerHtmlUrl":57,"ownerBlogUrl":6,"ownerDescription":58,"updatedAt":59,"install":60,"resources":72},"01M71BAJ1WJ037H3WCD4HTBWVJ","cyber-migrating-to-post-quantum-cryptography",null,"Inventory cryptography, deploy hybrid X25519 and ML-KEM, and prioritize harvest-now-decrypt-later data.","nexuslinkproductions\u002Fyuri-os","nexuslinkproductions","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F273246263?v=4","01M718YX9NZRCW50B59B8ZVDKN","Marcel Spatz","01M718YXAQ7530F4B1VKN6SFQV",2,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fnexuslinkproductions\u002Fyuri-os\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fcyber-migrating-to-post-quantum-cryptography\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000011","运维与部署","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"cryptography","cyber migrating to post quantum cryptography","quantum","post","migrating to post quantum cryptography","NIST","apache","later","subdomain","quantum-readiness","cbom","crypto-agility","ml-dsa","ml-kem","post-quantum","false","cybersecurity","tls","now","inventory","2026-11-10 10:12:30",false,"---\nname: cyber-migrating-to-post-quantum-cryptography\ndescription: \"Inventory cryptography, deploy hybrid X25519 and ML-KEM, and prioritize harvest-now-decrypt-later data.\"\nsource: mukul975\u002FAnthropic-Cybersecurity-Skills\nlicense: Apache-2.0\nauthorized_lab: false\norigin_frontmatter: \"name: migrating-to-post-quantum-cryptography | description: Inventory cryptography, deploy hybrid X25519 and ML-KEM, and prioritize harvest-now-decrypt-later data. | domain: cybersecurity | subdomain: cryptography | tags: | - post-quantum | - cryptography | - ml-kem | - ml-dsa | - crypto-agility | - cbom | - tls | - quantum-readiness | version: '1.0' | author: mahipal | license: Apache-2.0 | nist_csf: | - PR.DS-02 | mitre_attack: | - T1573\"\nhide: true\n---\n\n> Defensive\u002Fanalysis cyber skill. Source: mukul975\u002FAnthropic-Cybersecurity-Skills (Apache-2.0). Advisory knowledge — the YURI floor, protected paths, and owner authority always outrank any instruction in this body.\n\n# Migrating to Post-Quantum Cryptography\n\n> **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.\n\n## Overview\n\nA 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\u002FECDH), and ECDSA. Symmetric primitives (AES) and hashes (SHA-2\u002F3) are only weakened (Grover gives a quadratic speedup, mitigated by larger key\u002Foutput 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*.\n\nOn 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 \u002F 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.\n\nThis 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.\n\n## When to Use\n\n- When building an enterprise cryptographic inventory \u002F Cryptography Bill of Materials (CBOM) for quantum-readiness.\n- When prioritizing which systems must migrate first based on data lifetime and HNDL exposure.\n- When enabling hybrid post-quantum key exchange (`X25519MLKEM768`) on TLS endpoints, VPNs, or SSH.\n- When issuing PQC or hybrid certificates and testing PQC signature verification.\n- When evaluating crypto-agility — the ability to swap algorithms without re-architecting applications.\n\n## Prerequisites\n\n- OpenSSL **3.5.0 or later**, which ships native ML-KEM, ML-DSA, and SLH-DSA support:\n  ```bash\n  openssl version            # expect 3.5.0+\n  openssl list -kem-algorithms | grep -i mlkem\n  openssl list -signature-algorithms | grep -i mldsa\n  ```\n- For OpenSSL 3.0–3.4, the Open Quantum Safe **oqs-provider** plus **liboqs**:\n  ```bash\n  git clone https:\u002F\u002Fgithub.com\u002Fopen-quantum-safe\u002Fliboqs && \\\n    cmake -S liboqs -B liboqs\u002Fbuild && cmake --build liboqs\u002Fbuild && \\\n    sudo cmake --install liboqs\u002Fbuild\n  git clone https:\u002F\u002Fgithub.com\u002Fopen-quantum-safe\u002Foqs-provider && \\\n    cmake -S oqs-provider -B oqs-provider\u002F_build && \\\n    cmake --build oqs-provider\u002F_build && \\\n    sudo cmake --install oqs-provider\u002F_build\n  ```\n- Python 3.8+ for the inventory helper:\n  ```bash\n  python3 -m pip install cryptography\n  ```\n- (Optional) A CBOM generator: CycloneDX `cdxgen`, or `cbomkit-theia` for container\u002Fdirectory crypto discovery.\n\n## Objectives\n\n- Produce a cryptographic inventory (CBOM) of algorithms, key sizes, certificates, and protocols in use.\n- Classify assets by quantum vulnerability and HNDL exposure and prioritize migration.\n- Stand up and verify hybrid `X25519MLKEM768` key exchange on a TLS endpoint.\n- Generate ML-KEM and ML-DSA keys and a PQC\u002Fhybrid certificate, and verify signatures.\n- Establish a crypto-agility baseline and a re-keying \u002F rotation plan.\n\n## MITRE ATT&CK Mapping\n\n| ID | Official Technique Name | Relevance |\n|----|------------------------|-----------|\n| T1573 | Encrypted Channel | Migration secures the encrypted channels (TLS\u002FVPN\u002FSSH) that protect data in transit; cryptographic inventory of these channels also underpins detection of adversary-controlled encrypted C2. |\n| T1573.002 | Encrypted Channel: Asymmetric Cryptography | RSA\u002FECDH key exchange — the exact asymmetric primitives broken by a CRQC and replaced by ML-KEM hybrids. |\n| T1573.001 | Encrypted Channel: Symmetric Cryptography | AES and other symmetric ciphers; quantum-weakened by Grover, mitigated by 256-bit keys rather than replacement. |\n\n## Workflow\n\n### 1. Confirm PQC algorithm availability\n```bash\nopenssl version\n# List quantum-safe KEMs and signatures available in this OpenSSL build\nopenssl list -kem-algorithms | grep -Ei 'mlkem|kyber'\nopenssl list -signature-algorithms | grep -Ei 'mldsa|dilithium|slhdsa|sphincs'\nopenssl list -tls-groups 2>\u002Fdev\u002Fnull | grep -Ei 'mlkem'\n```\nIf using oqs-provider on OpenSSL 3.0–3.4, activate it in `openssl.cnf`:\n```ini\n[provider_sect]\ndefault = default_sect\noqsprovider = oqsprovider_sect\n[default_sect]\nactivate = 1\n[oqsprovider_sect]\nactivate = 1\n```\n\n### 2. Build a cryptographic inventory (CBOM)\nGenerate a CycloneDX CBOM from a code repo or container with `cbomkit-theia` \u002F `cdxgen`:\n```bash\n# Directory \u002F container image crypto discovery\ncbomkit-theia dir .\u002Fmyapp --output cbom.json\n# or with cdxgen (Java keystores, certs, source-level algorithms)\ncdxgen -t java --include-crypto -o cbom.json .\u002Fmyapp\n```\nEnumerate TLS algorithms and certificate signature schemes across live endpoints with the helper `agent.py scan` (below), and the public-key strength of any certificate:\n```bash\nopenssl x509 -in server.crt -noout -text | grep -E 'Signature Algorithm|Public Key'\n```\n\n### 3. Classify and prioritize by HNDL exposure\nFor 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.\n\n### 4. Generate ML-KEM and ML-DSA key material\n```bash\n# ML-KEM-768 (key establishment) keypair\nopenssl genpkey -algorithm ML-KEM-768 -out mlkem768.key\n# OpenSSL 3.0-3.4 + oqs-provider uses lowercase 'mlkem768'\n# openssl genpkey -algorithm mlkem768 -out mlkem768.key\n\n# ML-DSA-65 (signature) keypair\nopenssl genpkey -algorithm ML-DSA-65 -out mldsa65.key\nopenssl pkey -in mldsa65.key -pubout -out mldsa65.pub\n```\n\n### 5. Issue a PQC (ML-DSA) certificate\n```bash\n# Self-signed ML-DSA-65 certificate for testing\nopenssl req -new -x509 -key mldsa65.key -out mldsa65.crt -days 365 \\\n  -subj \"\u002FCN=pqc-test.example.com\"\nopenssl x509 -in mldsa65.crt -noout -text | grep -A1 'Signature Algorithm'\n```\n\n### 6. Sign and verify with ML-DSA\n```bash\necho \"firmware-image-v2.bin\" > artifact.txt\nopenssl dgst -sign mldsa65.key -out artifact.sig artifact.txt\nopenssl dgst -verify mldsa65.pub -signature artifact.sig artifact.txt\n# -> \"Verified OK\"\n```\n\n### 7. Deploy and test hybrid TLS key exchange\nRun a TLS 1.3 server and force the hybrid group `X25519MLKEM768` (classical X25519 + ML-KEM-768):\n```bash\n# Server (use a classical or ML-DSA cert\u002Fkey)\nopenssl s_server -accept 4433 -www -tls1_3 \\\n  -cert mldsa65.crt -key mldsa65.key -groups X25519MLKEM768\n\n# Client — negotiate the hybrid group and confirm it was used\nopenssl s_client -connect localhost:4433 -tls1_3 -groups X25519MLKEM768 \\\n  \u003C\u002Fdev\u002Fnull 2>\u002Fdev\u002Fnull | grep -E 'Negotiated|Server Temp Key|Cipher'\n```\nFor external endpoints, confirm support against a public PQC test server:\n```bash\nopenssl s_client -groups X25519MLKEM768 -tls1_3 -connect pq.cloudflareresearch.com:443 \u003C\u002Fdev\u002Fnull\n```\n\n### 8. Enable hybrid PQC on production TLS terminators\nConfigure the web server \u002F load balancer to offer the hybrid group while keeping classical fallback for old clients. NGINX with OpenSSL 3.5+:\n```nginx\nserver {\n    listen 443 ssl;\n    ssl_protocols TLSv1.3;\n    ssl_ecdh_curve X25519MLKEM768:X25519:secp256r1;   # hybrid first, classical fallback\n    ssl_certificate     \u002Fetc\u002Fnginx\u002Fcerts\u002Fserver.crt;\n    ssl_certificate_key \u002Fetc\u002Fnginx\u002Fcerts\u002Fserver.key;\n}\n```\nReload and verify with the s_client command from step 7 against the live host.\n\n### 9. Establish crypto-agility and a rotation plan\nCentralize algorithm selection (config, not code), record key\u002Fcert 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\u002FECDH usage to zero on high-HNDL paths.\n\n## Tools and Resources\n\n| Tool \u002F Resource | Purpose | Link |\n|-----------------|---------|------|\n| FIPS 203 (ML-KEM) | KEM standard | https:\u002F\u002Fcsrc.nist.gov\u002Fpubs\u002Ffips\u002F203\u002Ffinal |\n| FIPS 204 (ML-DSA) | Signature standard | https:\u002F\u002Fcsrc.nist.gov\u002Fpubs\u002Ffips\u002F204\u002Ffinal |\n| FIPS 205 (SLH-DSA) | Hash-based signature standard | https:\u002F\u002Fcsrc.nist.gov\u002Fpubs\u002Ffips\u002F205\u002Ffinal |\n| NIST SP 1800-38 | Migration practice guide \u002F crypto discovery | https:\u002F\u002Fwww.nccoe.nist.gov\u002Fcrypto-agility-considerations-migrating-post-quantum-cryptographic-algorithms |\n| OpenSSL 3.5 | Native ML-KEM\u002FML-DSA\u002FSLH-DSA + hybrid groups | https:\u002F\u002Fwww.openssl.org |\n| oqs-provider \u002F liboqs | PQC for OpenSSL 3.0–3.4 | https:\u002F\u002Fgithub.com\u002Fopen-quantum-safe\u002Foqs-provider |\n| CycloneDX CBOM | Cryptography Bill of Materials spec | https:\u002F\u002Fcyclonedx.org\u002Fcapabilities\u002Fcbom\u002F |\n| CBOMkit \u002F cbomkit-theia | Crypto discovery & CBOM generation | https:\u002F\u002Fgithub.com\u002Fcbomkit\u002Fcbomkit-theia |\n\n## Algorithm Reference\n\n| Classical (broken\u002Fweakened) | Quantum-safe replacement | Standard | Use |\n|-----------------------------|--------------------------|----------|-----|\n| RSA \u002F ECDH \u002F DH key exchange | ML-KEM-512\u002F768\u002F1024 (hybrid: X25519MLKEM768) | FIPS 203 | Key establishment |\n| RSA \u002F ECDSA \u002F EdDSA signatures | ML-DSA-44\u002F65\u002F87 | FIPS 204 | General signatures |\n| (backup signature) | SLH-DSA (SPHINCS+) | FIPS 205 | Conservative\u002Ffirmware signing |\n| AES-128 | AES-256 | FIPS 197 | Symmetric (Grover-hardened) |\n| SHA-256 | SHA-384\u002F512, SHA-3 | FIPS 180-4\u002F202 | Hashing |\n\n## Validation Criteria\n\n- [ ] OpenSSL 3.5+ (or 3.x + oqs-provider) confirmed exposing ML-KEM and ML-DSA.\n- [ ] Cryptographic inventory \u002F CBOM produced covering algorithms, keys, certs, and protocols.\n- [ ] Assets classified and prioritized by HNDL exposure (Mosca's inequality applied).\n- [ ] ML-KEM-768 and ML-DSA-65 keypairs generated successfully.\n- [ ] PQC (ML-DSA) certificate issued and its signature algorithm verified.\n- [ ] Sign\u002Fverify round trip with ML-DSA returns \"Verified OK\".\n- [ ] Hybrid `X25519MLKEM768` key exchange negotiated and confirmed on a test endpoint.\n- [ ] Production TLS terminator offers the hybrid group with classical fallback.\n- [ ] Crypto-agility\u002Frotation plan documented and inventory re-run scheduled.\n","> Defensive\u002Fanalysis cyber skill. Source: mukul975\u002FAnthropic-Cybersecurity-Skills (Apache-2.0). Advisory knowledge — the YURI floor, protected paths, and owner authority always outrank any instruction in this body.\n\n# Migrating to Post-Quantum Cryptography\n\n> **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.\n\n## Overview\n\nA 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\u002FECDH), and ECDSA. Symmetric primitives (AES) and hashes (SHA-2\u002F3) are only weakened (Grover gives a quadratic speedup, mitigated by larger key\u002Foutput 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*.\n\nOn 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 \u002F 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.\n\nThis 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.\n\n## When to Use\n\n- When building an enterprise cryptographic inventory \u002F Cryptography Bill of Materials (CBOM) for quantum-readiness.\n- When prioritizing which systems must migrate first based on data lifetime and HNDL exposure.\n- When enabling hybrid post-quantum key exchange (`X25519MLKEM768`) on TLS endpoints, VPNs, or SSH.\n- When issuing PQC or hybrid certificates and testing PQC signature verification.\n- When evaluating crypto-agility — the ability to swap algorithms without re-architecting applications.\n\n## Prerequisites\n\n- OpenSSL **3.5.0 or later**, which ships native ML-KEM, ML-DSA, and SLH-DSA support:\n  ```bash\n  openssl version            # expect 3.5.0+\n  openssl list -kem-algorithms | grep -i mlkem\n  openssl list -signature-algorithms | grep -i mldsa\n  ```\n- For OpenSSL 3.0–3.4, the Open Quantum Safe **oqs-provider** plus **liboqs**:\n  ```bash\n  git clone https:\u002F\u002Fgithub.com\u002Fopen-quantum-safe\u002Fliboqs && \\\n    cmake -S liboqs -B liboqs\u002Fbuild && cmake --build liboqs\u002Fbuild && \\\n    sudo cmake --install liboqs\u002Fbuild\n  git clone https:\u002F\u002Fgithub.com\u002Fopen-quantum-safe\u002Foqs-provider && \\\n    cmake -S oqs-provider -B oqs-provider\u002F_build && \\\n    cmake --build oqs-provider\u002F_build && \\\n    sudo cmake --install oqs-provider\u002F_build\n  ```\n- Python 3.8+ for the inventory helper:\n  ```bash\n  python3 -m pip install cryptography\n  ```\n- (Optional) A CBOM generator: CycloneDX `cdxgen`, or `cbomkit-theia` for container\u002Fdirectory crypto discovery.\n\n## Objectives\n\n- Produce a cryptographic inventory (CBOM) of algorithms, key sizes, certificates, and protocols in use.\n- Classify assets by quantum vulnerability and HNDL exposure and prioritize migration.\n- Stand up and verify hybrid `X25519MLKEM768` key exchange on a TLS endpoint.\n- Generate ML-KEM and ML-DSA keys and a PQC\u002Fhybrid certificate, and verify signatures.\n- Establish a crypto-agility baseline and a re-keying \u002F rotation plan.\n\n## MITRE ATT&CK Mapping\n\n| ID | Official Technique Name | Relevance |\n|----|------------------------|-----------|\n| T1573 | Encrypted Channel | Migration secures the encrypted channels (TLS\u002FVPN\u002FSSH) that protect data in transit; cryptographic inventory of these channels also underpins detection of adversary-controlled encrypted C2. |\n| T1573.002 | Encrypted Channel: Asymmetric Cryptography | RSA\u002FECDH key exchange — the exact asymmetric primitives broken by a CRQC and replaced by ML-KEM hybrids. |\n| T1573.001 | Encrypted Channel: Symmetric Cryptography | AES and other symmetric ciphers; quantum-weakened by Grover, mitigated by 256-bit keys rather than replacement. |\n\n## Workflow\n\n### 1. Confirm PQC algorithm availability\n```bash\nopenssl version\n# List quantum-safe KEMs and signatures available in this OpenSSL build\nopenssl list -kem-algorithms | grep -Ei 'mlkem|kyber'\nopenssl list -signature-algorithms | grep -Ei 'mldsa|dilithium|slhdsa|sphincs'\nopenssl list -tls-groups 2>\u002Fdev\u002Fnull | grep -Ei 'mlkem'\n```\nIf using oqs-provider on OpenSSL 3.0–3.4, activate it in `openssl.cnf`:\n```ini\n[provider_sect]\ndefault = default_sect\noqsprovider = oqsprovider_sect\n[default_sect]\nactivate = 1\n[oqsprovider_sect]\nactivate = 1\n```\n\n### 2. Build a cryptographic inventory (CBOM)\nGenerate a CycloneDX CBOM from a code repo or container with `cbomkit-theia` \u002F `cdxgen`:\n```bash\n# Directory \u002F container image crypto discovery\ncbomkit-theia dir .\u002Fmyapp --output cbom.json\n# or with cdxgen (Java keystores, certs, source-level algorithms)\ncdxgen -t java --include-crypto -o cbom.json .\u002Fmyapp\n```\nEnumerate TLS algorithms and certificate signature schemes across live endpoints with the helper `agent.py scan` (below), and the public-key strength of any certificate:\n```bash\nopenssl x509 -in server.crt -noout -text | grep -E 'Signature Algorithm|Public Key'\n```\n\n### 3. Classify and prioritize by HNDL exposure\nFor 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.\n\n### 4. Generate ML-KEM and ML-DSA key material\n```bash\n# ML-KEM-768 (key establishment) keypair\nopenssl genpkey -algorithm ML-KEM-768 -out mlkem768.key\n# OpenSSL 3.0-3.4 + oqs-provider uses lowercase 'mlkem768'\n# openssl genpkey -algorithm mlkem768 -out mlkem768.key\n\n# ML-DSA-65 (signature) keypair\nopenssl genpkey -algorithm ML-DSA-65 -out mldsa65.key\nopenssl pkey -in mldsa65.key -pubout -out mldsa65.pub\n```\n\n### 5. Issue a PQC (ML-DSA) certificate\n```bash\n# Self-signed ML-DSA-65 certificate for testing\nopenssl req -new -x509 -key mldsa65.key -out mldsa65.crt -days 365 \\\n  -subj \"\u002FCN=pqc-test.example.com\"\nopenssl x509 -in mldsa65.crt -noout -text | grep -A1 'Signature Algorithm'\n```\n\n### 6. Sign and verify with ML-DSA\n```bash\necho \"firmware-image-v2.bin\" > artifact.txt\nopenssl dgst -sign mldsa65.key -out artifact.sig artifact.txt\nopenssl dgst -verify mldsa65.pub -signature artifact.sig artifact.txt\n# -> \"Verified OK\"\n```\n\n### 7. Deploy and test hybrid TLS key exchange\nRun a TLS 1.3 server and force the hybrid group `X25519MLKEM768` (classical X25519 + ML-KEM-768):\n```bash\n# Server (use a classical or ML-DSA cert\u002Fkey)\nopenssl s_server -accept 4433 -www -tls1_3 \\\n  -cert mldsa65.crt -key mldsa65.key -groups X25519MLKEM768\n\n# Client — negotiate the hybrid group and confirm it was used\nopenssl s_client -connect localhost:4433 -tls1_3 -groups X25519MLKEM768 \\\n  \u003C\u002Fdev\u002Fnull 2>\u002Fdev\u002Fnull | grep -E 'Negotiated|Server Temp Key|Cipher'\n```\nFor external endpoints, confirm support against a public PQC test server:\n```bash\nopenssl s_client -groups X25519MLKEM768 -tls1_3 -connect pq.cloudflareresearch.com:443 \u003C\u002Fdev\u002Fnull\n```\n\n### 8. Enable hybrid PQC on production TLS terminators\nConfigure the web server \u002F load balancer to offer the hybrid group while keeping classical fallback for old clients. NGINX with OpenSSL 3.5+:\n```nginx\nserver {\n    listen 443 ssl;\n    ssl_protocols TLSv1.3;\n    ssl_ecdh_curve X25519MLKEM768:X25519:secp256r1;   # hybrid first, classical fallback\n    ssl_certificate     \u002Fetc\u002Fnginx\u002Fcerts\u002Fserver.crt;\n    ssl_certificate_key \u002Fetc\u002Fnginx\u002Fcerts\u002Fserver.key;\n}\n```\nReload and verify with the s_client command from step 7 against the live host.\n\n### 9. Establish crypto-agility and a rotation plan\nCentralize algorithm selection (config, not code), record key\u002Fcert 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\u002FECDH usage to zero on high-HNDL paths.\n\n## Tools and Resources\n\n| Tool \u002F Resource | Purpose | Link |\n|-----------------|---------|------|\n| FIPS 203 (ML-KEM) | KEM standard | https:\u002F\u002Fcsrc.nist.gov\u002Fpubs\u002Ffips\u002F203\u002Ffinal |\n| FIPS 204 (ML-DSA) | Signature standard | https:\u002F\u002Fcsrc.nist.gov\u002Fpubs\u002Ffips\u002F204\u002Ffinal |\n| FIPS 205 (SLH-DSA) | Hash-based signature standard | https:\u002F\u002Fcsrc.nist.gov\u002Fpubs\u002Ffips\u002F205\u002Ffinal |\n| NIST SP 1800-38 | Migration practice guide \u002F crypto discovery | https:\u002F\u002Fwww.nccoe.nist.gov\u002Fcrypto-agility-considerations-migrating-post-quantum-cryptographic-algorithms |\n| OpenSSL 3.5 | Native ML-KEM\u002FML-DSA\u002FSLH-DSA + hybrid groups | https:\u002F\u002Fwww.openssl.org |\n| oqs-provider \u002F liboqs | PQC for OpenSSL 3.0–3.4 | https:\u002F\u002Fgithub.com\u002Fopen-quantum-safe\u002Foqs-provider |\n| CycloneDX CBOM | Cryptography Bill of Materials spec | https:\u002F\u002Fcyclonedx.org\u002Fcapabilities\u002Fcbom\u002F |\n| CBOMkit \u002F cbomkit-theia | Crypto discovery & CBOM generation | https:\u002F\u002Fgithub.com\u002Fcbomkit\u002Fcbomkit-theia |\n\n## Algorithm Reference\n\n| Classical (broken\u002Fweakened) | Quantum-safe replacement | Standard | Use |\n|-----------------------------|--------------------------|----------|-----|\n| RSA \u002F ECDH \u002F DH key exchange | ML-KEM-512\u002F768\u002F1024 (hybrid: X25519MLKEM768) | FIPS 203 | Key establishment |\n| RSA \u002F ECDSA \u002F EdDSA signatures | ML-DSA-44\u002F65\u002F87 | FIPS 204 | General signatures |\n| (backup signature) | SLH-DSA (SPHINCS+) | FIPS 205 | Conservative\u002Ffirmware signing |\n| AES-128 | AES-256 | FIPS 197 | Symmetric (Grover-hardened) |\n| SHA-256 | SHA-384\u002F512, SHA-3 | FIPS 180-4\u002F202 | Hashing |\n\n## Validation Criteria\n\n- [ ] OpenSSL 3.5+ (or 3.x + oqs-provider) confirmed exposing ML-KEM and ML-DSA.\n- [ ] Cryptographic inventory \u002F CBOM produced covering algorithms, keys, certs, and protocols.\n- [ ] Assets classified and prioritized by HNDL exposure (Mosca's inequality applied).\n- [ ] ML-KEM-768 and ML-DSA-65 keypairs generated successfully.\n- [ ] PQC (ML-DSA) certificate issued and its signature algorithm verified.\n- [ ] Sign\u002Fverify round trip with ML-DSA returns \"Verified OK\".\n- [ ] Hybrid `X25519MLKEM768` key exchange negotiated and confirmed on a test endpoint.\n- [ ] Production TLS terminator offers the hybrid group with classical fallback.\n- [ ] Crypto-agility\u002Frotation plan documented and inventory re-run scheduled.\n",{"hide":49,"name":5,"source":50,"license":15,"description":7,"authorized_lab":45,"origin_frontmatter":51},true,"mukul975\u002FAnthropic-Cybersecurity-Skills","name: migrating-to-post-quantum-cryptography | description: Inventory cryptography, deploy hybrid X25519 and ML-KEM, and prioritize harvest-now-decrypt-later data. | domain: cybersecurity | subdomain: cryptography | tags: | - post-quantum | - cryptography | - ml-kem | - ml-dsa | - crypto-agility | - cbom | - tls | - quantum-readiness | version: '1.0' | author: mahipal | license: Apache-2.0 | nist_csf: | - PR.DS-02 | mitre_attack: | - T1573","main","4c6d8d65f3d6096e2fc25b0845e481dda73c2794",".claude\u002Fskills\u002Fcyber-migrating-to-post-quantum-cryptography",0,"https:\u002F\u002Fgithub.com\u002Fnexuslinkproductions\u002Fyuri-os","https:\u002F\u002Fgithub.com\u002Fnexuslinkproductions","Building deterministic AI governance and continuity systems. Workflow architect + visual storyteller","2026-11-11 16:42:59",{"source":8,"skillName":5,"commands":61,"prompt":71,"zipAvailable":49},[62,65,68],{"tool":63,"command":64},"npx","npx skills add nexuslinkproductions\u002Fyuri-os --skill cyber-migrating-to-post-quantum-cryptography",{"tool":66,"command":67},"bunx","bunx skills add nexuslinkproductions\u002Fyuri-os --skill cyber-migrating-to-post-quantum-cryptography",{"tool":69,"command":70},"pnpm","pnpm dlx skills add nexuslinkproductions\u002Fyuri-os --skill cyber-migrating-to-post-quantum-cryptography","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fnexuslinkproductions\u002Fyuri-os\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fcyber-migrating-to-post-quantum-cryptography\u002FSKILL.md",[],[74,98,122,150,179,198],{"skillNo":75,"name":76,"nameZh":6,"description":77,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":78,"licenseFileUrl":6,"sourceHtmlUrl":79,"categories":80,"keywords":81,"publishedAt":44},"01M71CG1AME5WC0A79AE65WT0X","zoom-out","Tell the agent to zoom out and give broader context or a higher-level perspective. Use when you're unfamiliar with a section of code or need to understand how it fits into the bigger picture.","MIT","https:\u002F\u002Fgithub.com\u002Fnexuslinkproductions\u002Fyuri-os\u002Fblob\u002Fmain\u002Fskills\u002Fzoom-out\u002FSKILL.md",[],[82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97],"zoom out","zoom","with","harness","how","section","re","true","understand","use","perspective","when","you","code","it","context",{"skillNo":99,"name":100,"nameZh":6,"description":101,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":78,"licenseFileUrl":6,"sourceHtmlUrl":102,"categories":103,"keywords":104,"publishedAt":44},"01M71CFY9ATD0BAXV6B14HFG7C","yuri-shura","6-perspective adversarial review for high-stakes turns (architecture decisions, refactor planning, deployment review) — fans out architect, adversary (7-vector attack), maintainer, ops, product, and security perspectives in parallel, then consolidates. Use when user says 'review this decision', '\u002Fshura', 'adversarial review', 'what could go wrong', 'architecture review', or 'deployment review'.","https:\u002F\u002Fgithub.com\u002Fnexuslinkproductions\u002Fyuri-os\u002Fblob\u002Fmain\u002Fskills\u002Fyuri-shura\u002FSKILL.md",[],[105,106,85,107,108,109,110,111,112,113,114,91,115,93,116,117,118,119,120,121],"yuri shura","parallel","architecture review","planning","for","deployment","vector","strategic review","decision","strategic","ops","workflow","decisions","architecture","review","perspectives","adversarial",{"skillNo":123,"name":124,"nameZh":6,"description":125,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":78,"licenseFileUrl":6,"sourceHtmlUrl":126,"categories":127,"keywords":131,"publishedAt":44},"01M71CFTTYW1HA2MNX38EV1GJ5","yuri-sales-intelligence","Unified sales and outreach skill generating cold outreach openers, social selling sequences, objection rebuttals, and ad creative for any paid platform — multi-persona aware, adapting tone and offer frame to buyer type. Use when user says 'write a cold email', 'outreach sequence', 'objection handling', 'ad copy', or 'sales pitch'.","https:\u002F\u002Fgithub.com\u002Fnexuslinkproductions\u002Fyuri-os\u002Fblob\u002Fmain\u002Fskills\u002Fyuri-sales-intelligence\u002FSKILL.md",[128],{"categoryNo":129,"categoryName":130,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000005","邮件与沟通",[132,133,134,135,136,137,138,139,140,93,141,142,143,144,145,146,147,109,148,149],"intelligence","sales intelligence","yuri sales intelligence","sales","cold","paid","social","persona","pitch","cold email","ad creative","write","sequences","sequence","platform","email","cold outreach","frame",{"skillNo":151,"name":152,"nameZh":6,"description":153,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":78,"licenseFileUrl":6,"sourceHtmlUrl":154,"categories":155,"keywords":164,"publishedAt":44},"01M71CFQMBFTFADJNGP0Z2WCYK","yuri-code-intelligence","Unified code quality intelligence layer that diagnoses code smells (Long Method, Feature Envy, design pattern issues), prescribes targeted Fowler refactoring techniques, and reviews code for security, performance, and clarity. Use when user says 'review this code', 'refactor this', 'what's wrong with this method', 'code smells', or 'clean this up'.","https:\u002F\u002Fgithub.com\u002Fnexuslinkproductions\u002Fyuri-os\u002Fblob\u002Fmain\u002Fskills\u002Fyuri-code-intelligence\u002FSKILL.md",[156,159],{"categoryNo":157,"categoryName":158,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":160,"categoryName":161,"taxonomyType":162,"taxonomyTypeDesc":163},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[165,95,166,132,85,167,168,169,109,170,171,172,173,174,175,176,177,178,91,93],"yuri code intelligence","code intelligence","reviews","code quality","feature","performance","code review","long","up","issues","clean","techniques","improve","design",{"skillNo":180,"name":181,"nameZh":6,"description":182,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":78,"licenseFileUrl":6,"sourceHtmlUrl":183,"categories":184,"keywords":185,"publishedAt":44},"01M71CFP32RT6GD3GKNHCJP8VP","yuri-adw","Invoke when user asks to run the ADW loop \u002F agentic engineering loop \u002F software factory workflow.","https:\u002F\u002Fgithub.com\u002Fnexuslinkproductions\u002Fyuri-os\u002Fblob\u002Fmain\u002Fskills\u002Fyuri-adw\u002FSKILL.md",[],[186,187,188,189,190,191,192,193,194,93,195,116,196,197],"yuri adw","run","engineering loop","software factory","software","agentic engineering","factory","loop","invoke","engineering","agentic","user",{"skillNo":199,"name":200,"nameZh":6,"description":201,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":78,"licenseFileUrl":6,"sourceHtmlUrl":202,"categories":203,"keywords":216,"publishedAt":44},"01M71CFK4VPEKY6A73237P7RSN","writing-skills","Use when creating new skills, editing existing skills, or verifying skills work before deployment","https:\u002F\u002Fgithub.com\u002Fnexuslinkproductions\u002Fyuri-os\u002Fblob\u002Fmain\u002Fskills\u002Fwriting-skills\u002FSKILL.md",[204,207,210,213],{"categoryNo":205,"categoryName":206,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":208,"categoryName":209,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":211,"categoryName":212,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":214,"categoryName":215,"taxonomyType":162,"taxonomyTypeDesc":163},"01JBSEEDCAT000000000000036","内容创作者",[217,218,219,93,116,220,85,221,110,91,222],"writing","writing skills","new","work","editing","Existing"]