[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71CXYVTH0RPR9TGMDGV6CB6":3,"skill-same:01M71CXYVTH0RPR9TGMDGV6CB6":91},{"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":18,"publishedAt":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":64,"commitSha":65,"skillDirectory":66,"forksCount":14,"repositoryHtmlUrl":67,"repositoryHomepageUrl":6,"ownerHtmlUrl":68,"ownerBlogUrl":6,"ownerDescription":69,"updatedAt":70,"install":71,"resources":84},"01M71CXYVTH0RPR9TGMDGV6CB6","postquantum-post-detect",null,"Assesses organizational readiness for post-quantum cryptography migration per NIST FIPS 203\u002F204\u002F205 standards. Performs cryptographic inventory scanning to identify quantum-vulnerable algorithms (RSA, ECDH, ECDSA), evaluates hybrid TLS configurations with X25519MLKEM768, and validates CRYSTALS-Kyber (ML-KEM) and CRYSTALS-Dilithium (ML-DSA) readiness. Implements crypto-agility assessment using oqs-provider for OpenSSL. Use when planning or executing the transition from classical to post-quantum cryptographic algorithms across enterprise infrastructure.","DCx7C5\u002Fai-marketplace","DCx7C5","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F42419559?v=4","01M71C01G2AZV3NTNGWAWSHJPP","DC","01M71C01GQW6G50S2BYMS7PP3E",0,"MIT","https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fcrypto\u002Fpostquantum\u002Fpost\u002Fdetect\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"detect","postquantum post detect","post","CRYSTALS-Kyber","PQC","NIST","read","scanning","transition","across","crypto-agility","ml-dsa","ml-kem","Bash","post-quantum","when","cybersecurity","tls","assessment","inventory","2026-11-10 10:12:30",false,"---\nname: postquantum-post-detect\ndescription: Assesses organizational readiness for post-quantum cryptography migration per NIST FIPS 203\u002F204\u002F205 standards. Performs cryptographic inventory scanning to identify quantum-vulnerable algorithms (RSA, ECDH, ECDSA), evaluates hybrid TLS configurations with X25519MLKEM768, and validates CRYSTALS-Kyber (ML-KEM) and CRYSTALS-Dilithium (ML-DSA) readiness. Implements crypto-agility assessment using oqs-provider for OpenSSL. Use when planning or executing the transition from classical to post-quantum cryptographic algorithms across enterprise infrastructure.\ndomain: cybersecurity\nsubdomain: cryptography\ntags:\n- post-quantum\n- PQC\n- CRYSTALS-Kyber\n- ML-KEM\n- ML-DSA\n- FIPS-203\n- FIPS-204\n- hybrid-TLS\n- crypto-agility\nnist_csf:\n- PR.DS-01\n- PR.DS-02\n- PR.DS-10\nmodel: sonnet\nmaxTurns: 20\ntools: [Read, Bash, Glob, Grep]\ncve:\n- CVE-2021-26855\ncapec: []\n---\n\n# Performing Post-Quantum Cryptography Migration\n\n## When to Use\n\n- When assessing organizational readiness for the NIST post-quantum cryptography transition\n- When building a cryptographic inventory to identify quantum-vulnerable algorithms across infrastructure\n- When evaluating hybrid TLS 1.3 configurations using X25519MLKEM768 key exchange\n- When testing CRYSTALS-Kyber (ML-KEM) and CRYSTALS-Dilithium (ML-DSA) algorithm support\n- When implementing crypto-agility to support both classical and post-quantum algorithms\n- When preparing migration roadmaps aligned with NIST IR 8547 deprecation timelines\n- When configuring oqs-provider with OpenSSL 3.x for post-quantum algorithm support\n\n## Prerequisites\n\n- Python 3.8+ with `cryptography`, `requests`, `pyOpenSSL` libraries\n- OpenSSL 3.0+ (3.5+ recommended for native ML-KEM\u002FML-DSA support)\n- oqs-provider for OpenSSL (for hybrid TLS testing with older OpenSSL)\n- Network access to target servers for TLS assessment\n- Administrative access for infrastructure scanning\n- Familiarity with PKI, TLS, and cryptographic protocols\n\n## Core Concepts\n\n### NIST Post-Quantum Cryptography Standards\n\nNIST published three finalized PQC standards on August 13, 2024:\n\n| Standard | Algorithm | Renamed To | Purpose | Based On |\n|----------|-----------|------------|---------|----------|\n| FIPS 203 | CRYSTALS-Kyber | ML-KEM | Key Encapsulation Mechanism | Module lattice |\n| FIPS 204 | CRYSTALS-Dilithium | ML-DSA | Digital Signatures | Module lattice |\n| FIPS 205 | SPHINCS+ | SLH-DSA | Digital Signatures (backup) | Stateless hash |\n\n**ML-KEM (FIPS 203)** -- Primary standard for key exchange and encryption. Replaces\nRSA and ECDH for key establishment. Three security levels: ML-KEM-512, ML-KEM-768,\nML-KEM-1024.\n\n**ML-DSA (FIPS 204)** -- Primary standard for digital signatures. Replaces RSA and\nECDSA for signing. Three security levels: ML-DSA-44, ML-DSA-65, ML-DSA-87.\n\n**SLH-DSA (FIPS 205)** -- Backup signature standard using hash-based approach. Intended\nas fallback if lattice-based ML-DSA is found vulnerable. Larger signatures but\nconservative security assumptions.\n\n### Quantum-Vulnerable Algorithms\n\nThese classical algorithms are vulnerable to quantum attack via Shor's algorithm:\n\n| Algorithm | Usage | Quantum Threat | Migration Priority |\n|-----------|-------|---------------|-------------------|\n| RSA-2048\u002F4096 | Key exchange, signatures, encryption | Shor's algorithm breaks factoring | Critical |\n| ECDH (P-256, P-384) | TLS key exchange | Shor's algorithm breaks ECDLP | Critical |\n| ECDSA | Code signing, TLS certificates | Shor's algorithm breaks ECDLP | Critical |\n| DSA | Legacy signatures | Shor's algorithm breaks DLP | Critical |\n| DH (Diffie-Hellman) | Key exchange | Shor's algorithm breaks DLP | Critical |\n| AES-128 | Symmetric encryption | Grover's halves key strength | Medium (upgrade to AES-256) |\n| SHA-256 | Hashing | Grover's reduces to 128-bit | Low (still adequate) |\n\n### NIST Migration Timeline (IR 8547)\n\n- **2024**: Standards published, migration planning should begin\n- **2030**: Deprecation of quantum-vulnerable algorithms for most federal systems\n- **2035**: Complete removal of quantum-vulnerable algorithms from NIST standards\n- **Now**: \"Harvest now, decrypt later\" attacks make early migration essential for\n  long-lived secrets and data requiring long-term confidentiality\n\n### Hybrid TLS Key Exchange\n\nDuring the transition period, hybrid key exchange combines a classical algorithm with\na post-quantum algorithm. If either algorithm is secure, the connection remains protected.\n\n```\nHybrid Key Exchange: X25519MLKEM768\n  = X25519 (classical ECDH) + ML-KEM-768 (post-quantum)\n\nClient Hello:\n  supported_groups: X25519MLKEM768, X25519, secp256r1\n  key_share: X25519MLKEM768\n\nServer Hello:\n  selected_group: X25519MLKEM768\n  key_share: X25519MLKEM768\n\nShared Secret = KDF(X25519_shared || MLKEM768_shared)\n```\n\n## Instructions\n\n### Phase 1: Cryptographic Inventory Scanning\n\nThe first step in PQC migration is discovering all cryptographic algorithm usage\nacross the enterprise. This includes TLS configurations, certificates, code libraries,\nkey stores, and protocol configurations.\n\n```python\n# Scan TLS endpoints for quantum-vulnerable algorithms\npython scripts\u002Fagent.py --action scan_tls \\\n    --targets targets.txt \\\n    --output tls_inventory.json\n```\n\nThe scanner identifies:\n- TLS protocol versions in use\n- Key exchange algorithms (RSA, ECDH, DH -- all quantum-vulnerable)\n- Certificate signature algorithms (RSA, ECDSA)\n- Cipher suite configurations\n- Certificate key sizes and expiration dates\n\n### Phase 2: Crypto-Agility Assessment\n\nEvaluate the organization's ability to swap cryptographic algorithms without\nmajor infrastructure changes:\n\n```python\n# Assess crypto-agility readiness\npython scripts\u002Fagent.py --action assess_agility \\\n    --scan-results tls_inventory.json \\\n    --output agility_report.json\n```\n\nKey assessment areas:\n1. **Protocol flexibility**: Can TLS configurations be updated without downtime?\n2. **Library versions**: Do deployed crypto libraries support PQC algorithms?\n3. **Certificate infrastructure**: Can CA issue PQC certificates?\n4. **Key management**: Can KMS handle larger PQC key sizes?\n5. **Hardware constraints**: Can HSMs support PQC operations?\n\n### Phase 3: Hybrid TLS Readiness Testing\n\nTest whether infrastructure supports hybrid key exchange with X25519MLKEM768:\n\n```python\n# Test hybrid TLS support on target servers\npython scripts\u002Fagent.py --action test_hybrid_tls \\\n    --target server.example.com:443 \\\n    --output hybrid_tls_report.json\n```\n\n**OpenSSL 3.5+ (native ML-KEM support):**\n```bash\n# Test with native PQC support\nopenssl s_client -connect server.example.com:443 \\\n    -groups X25519MLKEM768\n```\n\n**OpenSSL 3.0-3.4 with oqs-provider:**\n```bash\n# Configure oqs-provider\n# \u002Fetc\u002Fssl\u002Fopenssl-oqs.cnf\n[openssl_init]\nproviders = provider_sect\n\n[provider_sect]\ndefault = default_sect\noqsprovider = oqsprovider_sect\n\n[default_sect]\nactivate = 1\n\n[oqsprovider_sect]\nactivate = 1\nmodule = \u002Fusr\u002Flibs\u002Foqs-provider\u002Foqsprovider.so\n\n# Test hybrid TLS\nOPENSSL_CONF=\u002Fetc\u002Fssl\u002Fopenssl-oqs.cnf \\\nopenssl s_client -connect server.example.com:443 \\\n    -groups x25519_mlkem768\n```\n\n**Web Server Configuration for Hybrid TLS:**\n\nApache httpd:\n```apache\nSSLEngine on\nSSLCertificateFile \u002Fetc\u002Fssl\u002Fcerts\u002Fserver.crt\nSSLCertificateKeyFile \u002Fetc\u002Fssl\u002Fprivate\u002Fserver.key\nSSLOpenSSLConfCmd Curves X25519MLKEM768:X25519:prime256v1\nSSLProtocol -all +TLSv1.2 +TLSv1.3\n```\n\nNGINX:\n```nginx\nssl_ecdh_curve X25519MLKEM768:X25519:prime256v1;\nssl_protocols TLSv1.2 TLSv1.3;\nssl_prefer_server_ciphers on;\n```\n\n### Phase 4: ML-KEM Key Encapsulation Validation\n\nValidate that ML-KEM (CRYSTALS-Kyber) key encapsulation works correctly in your\nenvironment:\n\n```python\n# Test ML-KEM key encapsulation at all security levels\npython scripts\u002Fagent.py --action test_mlkem \\\n    --output mlkem_validation.json\n```\n\nML-KEM parameter comparison:\n\n| Parameter | ML-KEM-512 | ML-KEM-768 | ML-KEM-1024 |\n|-----------|-----------|-----------|------------|\n| Security Level | NIST Level 1 | NIST Level 3 | NIST Level 5 |\n| Public Key Size | 800 bytes | 1,184 bytes | 1,568 bytes |\n| Ciphertext Size | 768 bytes | 1,088 bytes | 1,568 bytes |\n| Shared Secret | 32 bytes | 32 bytes | 32 bytes |\n| Comparable To | AES-128 | AES-192 | AES-256 |\n\n### Phase 5: ML-DSA Digital Signature Validation\n\nValidate ML-DSA (CRYSTALS-Dilithium) signature operations:\n\n```python\n# Test ML-DSA digital signatures\npython scripts\u002Fagent.py --action test_mldsa \\\n    --output mldsa_validation.json\n```\n\nML-DSA parameter comparison:\n\n| Parameter | ML-DSA-44 | ML-DSA-65 | ML-DSA-87 |\n|-----------|----------|----------|----------|\n| Security Level | NIST Level 2 | NIST Level 3 | NIST Level 5 |\n| Public Key Size | 1,312 bytes | 1,952 bytes | 2,592 bytes |\n| Signature Size | 2,420 bytes | 3,293 bytes | 4,595 bytes |\n| Secret Key Size | 2,560 bytes | 4,032 bytes | 4,896 bytes |\n\n### Phase 6: Migration Roadmap Generation\n\nGenerate a prioritized migration roadmap based on inventory and assessment results:\n\n```python\n# Generate complete migration roadmap\npython scripts\u002Fagent.py --action roadmap \\\n    --scan-results tls_inventory.json \\\n    --agility-results agility_report.json \\\n    --output migration_roadmap.json\n```\n\nThe roadmap prioritizes systems by:\n1. **Data sensitivity**: Systems handling long-lived secrets migrate first\n2. **Exposure level**: Internet-facing services before internal\n3. **Crypto-agility**: Systems that can easily swap algorithms first\n4. **Compliance requirements**: Federal\u002Fregulated systems per NIST IR 8547 timeline\n5. **Dependency chains**: Libraries and frameworks before applications\n\n## Examples\n\n### Full Assessment Pipeline\n\n```bash\n# Step 1: Scan all TLS endpoints\npython scripts\u002Fagent.py --action scan_tls --targets hosts.txt --output scan.json\n\n# Step 2: Assess crypto-agility\npython scripts\u002Fagent.py --action assess_agility --scan-results scan.json --output agility.json\n\n# Step 3: Test hybrid TLS on critical servers\npython scripts\u002Fagent.py --action test_hybrid_tls --target critical.example.com:443\n\n# Step 4: Validate ML-KEM support\npython scripts\u002Fagent.py --action test_mlkem --output mlkem.json\n\n# Step 5: Validate ML-DSA support\npython scripts\u002Fagent.py --action test_mldsa --output mldsa.json\n\n# Step 6: Generate migration roadmap\npython scripts\u002Fagent.py --action roadmap --scan-results scan.json --agility-results agility.json --output roadmap.json\n```\n\n### Quick Server Assessment\n\n```bash\n# Single server PQC readiness check\npython scripts\u002Fagent.py --action scan_tls --target server.example.com:443\n```\n\n## Validation Checklist\n\n- [ ] Cryptographic inventory covers all TLS endpoints, certificates, and key stores\n- [ ] All quantum-vulnerable algorithms (RSA, ECDH, ECDSA, DH, DSA) are identified\n- [ ] Crypto-agility assessment documents library versions and upgrade paths\n- [ ] Hybrid TLS (X25519MLKEM768) tested on representative server configurations\n- [ ] ML-KEM key encapsulation validated at target security level (768 recommended)\n- [ ] ML-DSA signature verification validated for certificate chain use\n- [ ] SLH-DSA (FIPS 205) evaluated as backup signature algorithm\n- [ ] Migration roadmap prioritizes by data sensitivity and compliance timeline\n- [ ] OpenSSL version and oqs-provider compatibility confirmed\n- [ ] Key size increases accounted for in network and storage capacity planning\n- [ ] HSM\u002FKMS compatibility with PQC algorithms verified\n- [ ] Performance impact of PQC algorithms benchmarked under production load\n- [ ] \"Harvest now, decrypt later\" risk assessed for sensitive data channels\n- [ ] Certificate Authority PQC readiness confirmed for certificate issuance\n\n## References\n\n- NIST PQC Standards: https:\u002F\u002Fcsrc.nist.gov\u002Fprojects\u002Fpost-quantum-cryptography\n- FIPS 203 (ML-KEM): https:\u002F\u002Fcsrc.nist.gov\u002Fpubs\u002Ffips\u002F203\u002Ffinal\n- FIPS 204 (ML-DSA): https:\u002F\u002Fcsrc.nist.gov\u002Fpubs\u002Ffips\u002F204\u002Ffinal\n- FIPS 205 (SLH-DSA): https:\u002F\u002Fcsrc.nist.gov\u002Fpubs\u002Ffips\u002F205\u002Ffinal\n- NIST SP 1800-38 Migration Guide: https:\u002F\u002Fwww.nccoe.nist.gov\u002Fcrypto-agility-considerations-migrating-post-quantum-cryptographic-algorithms\n- NIST IR 8547 Transition Timeline: https:\u002F\u002Fcsrc.nist.gov\u002Fpubs\u002Fir\u002F8547\u002Fipd\n- Open Quantum Safe Project: https:\u002F\u002Fopenquantumsafe.org\u002F\n- oqs-provider for OpenSSL: https:\u002F\u002Fgithub.com\u002Fopen-quantum-safe\u002Foqs-provider\n- OQS TLS Integration: https:\u002F\u002Fopenquantumsafe.org\u002Fapplications\u002Ftls.html\n- CISA PQC Migration Strategy: https:\u002F\u002Fwww.cisa.gov\u002Fsites\u002Fdefault\u002Ffiles\u002F2024-09\u002FStrategy-for-Migrating-to-Automated-PQC-Discovery-and-Inventory-Tools.pdf\n- IETF Hybrid Key Exchange Draft: https:\u002F\u002Fdatatracker.ietf.org\u002Fdoc\u002Fdraft-ietf-tls-hybrid-design\u002F\n- CycloneDX Crypto BOM: https:\u002F\u002Fcyclonedx.org\u002Fuse-cases\u002Fcryptographic-key\u002F\n","# Performing Post-Quantum Cryptography Migration\n\n## When to Use\n\n- When assessing organizational readiness for the NIST post-quantum cryptography transition\n- When building a cryptographic inventory to identify quantum-vulnerable algorithms across infrastructure\n- When evaluating hybrid TLS 1.3 configurations using X25519MLKEM768 key exchange\n- When testing CRYSTALS-Kyber (ML-KEM) and CRYSTALS-Dilithium (ML-DSA) algorithm support\n- When implementing crypto-agility to support both classical and post-quantum algorithms\n- When preparing migration roadmaps aligned with NIST IR 8547 deprecation timelines\n- When configuring oqs-provider with OpenSSL 3.x for post-quantum algorithm support\n\n## Prerequisites\n\n- Python 3.8+ with `cryptography`, `requests`, `pyOpenSSL` libraries\n- OpenSSL 3.0+ (3.5+ recommended for native ML-KEM\u002FML-DSA support)\n- oqs-provider for OpenSSL (for hybrid TLS testing with older OpenSSL)\n- Network access to target servers for TLS assessment\n- Administrative access for infrastructure scanning\n- Familiarity with PKI, TLS, and cryptographic protocols\n\n## Core Concepts\n\n### NIST Post-Quantum Cryptography Standards\n\nNIST published three finalized PQC standards on August 13, 2024:\n\n| Standard | Algorithm | Renamed To | Purpose | Based On |\n|----------|-----------|------------|---------|----------|\n| FIPS 203 | CRYSTALS-Kyber | ML-KEM | Key Encapsulation Mechanism | Module lattice |\n| FIPS 204 | CRYSTALS-Dilithium | ML-DSA | Digital Signatures | Module lattice |\n| FIPS 205 | SPHINCS+ | SLH-DSA | Digital Signatures (backup) | Stateless hash |\n\n**ML-KEM (FIPS 203)** -- Primary standard for key exchange and encryption. Replaces\nRSA and ECDH for key establishment. Three security levels: ML-KEM-512, ML-KEM-768,\nML-KEM-1024.\n\n**ML-DSA (FIPS 204)** -- Primary standard for digital signatures. Replaces RSA and\nECDSA for signing. Three security levels: ML-DSA-44, ML-DSA-65, ML-DSA-87.\n\n**SLH-DSA (FIPS 205)** -- Backup signature standard using hash-based approach. Intended\nas fallback if lattice-based ML-DSA is found vulnerable. Larger signatures but\nconservative security assumptions.\n\n### Quantum-Vulnerable Algorithms\n\nThese classical algorithms are vulnerable to quantum attack via Shor's algorithm:\n\n| Algorithm | Usage | Quantum Threat | Migration Priority |\n|-----------|-------|---------------|-------------------|\n| RSA-2048\u002F4096 | Key exchange, signatures, encryption | Shor's algorithm breaks factoring | Critical |\n| ECDH (P-256, P-384) | TLS key exchange | Shor's algorithm breaks ECDLP | Critical |\n| ECDSA | Code signing, TLS certificates | Shor's algorithm breaks ECDLP | Critical |\n| DSA | Legacy signatures | Shor's algorithm breaks DLP | Critical |\n| DH (Diffie-Hellman) | Key exchange | Shor's algorithm breaks DLP | Critical |\n| AES-128 | Symmetric encryption | Grover's halves key strength | Medium (upgrade to AES-256) |\n| SHA-256 | Hashing | Grover's reduces to 128-bit | Low (still adequate) |\n\n### NIST Migration Timeline (IR 8547)\n\n- **2024**: Standards published, migration planning should begin\n- **2030**: Deprecation of quantum-vulnerable algorithms for most federal systems\n- **2035**: Complete removal of quantum-vulnerable algorithms from NIST standards\n- **Now**: \"Harvest now, decrypt later\" attacks make early migration essential for\n  long-lived secrets and data requiring long-term confidentiality\n\n### Hybrid TLS Key Exchange\n\nDuring the transition period, hybrid key exchange combines a classical algorithm with\na post-quantum algorithm. If either algorithm is secure, the connection remains protected.\n\n```\nHybrid Key Exchange: X25519MLKEM768\n  = X25519 (classical ECDH) + ML-KEM-768 (post-quantum)\n\nClient Hello:\n  supported_groups: X25519MLKEM768, X25519, secp256r1\n  key_share: X25519MLKEM768\n\nServer Hello:\n  selected_group: X25519MLKEM768\n  key_share: X25519MLKEM768\n\nShared Secret = KDF(X25519_shared || MLKEM768_shared)\n```\n\n## Instructions\n\n### Phase 1: Cryptographic Inventory Scanning\n\nThe first step in PQC migration is discovering all cryptographic algorithm usage\nacross the enterprise. This includes TLS configurations, certificates, code libraries,\nkey stores, and protocol configurations.\n\n```python\n# Scan TLS endpoints for quantum-vulnerable algorithms\npython scripts\u002Fagent.py --action scan_tls \\\n    --targets targets.txt \\\n    --output tls_inventory.json\n```\n\nThe scanner identifies:\n- TLS protocol versions in use\n- Key exchange algorithms (RSA, ECDH, DH -- all quantum-vulnerable)\n- Certificate signature algorithms (RSA, ECDSA)\n- Cipher suite configurations\n- Certificate key sizes and expiration dates\n\n### Phase 2: Crypto-Agility Assessment\n\nEvaluate the organization's ability to swap cryptographic algorithms without\nmajor infrastructure changes:\n\n```python\n# Assess crypto-agility readiness\npython scripts\u002Fagent.py --action assess_agility \\\n    --scan-results tls_inventory.json \\\n    --output agility_report.json\n```\n\nKey assessment areas:\n1. **Protocol flexibility**: Can TLS configurations be updated without downtime?\n2. **Library versions**: Do deployed crypto libraries support PQC algorithms?\n3. **Certificate infrastructure**: Can CA issue PQC certificates?\n4. **Key management**: Can KMS handle larger PQC key sizes?\n5. **Hardware constraints**: Can HSMs support PQC operations?\n\n### Phase 3: Hybrid TLS Readiness Testing\n\nTest whether infrastructure supports hybrid key exchange with X25519MLKEM768:\n\n```python\n# Test hybrid TLS support on target servers\npython scripts\u002Fagent.py --action test_hybrid_tls \\\n    --target server.example.com:443 \\\n    --output hybrid_tls_report.json\n```\n\n**OpenSSL 3.5+ (native ML-KEM support):**\n```bash\n# Test with native PQC support\nopenssl s_client -connect server.example.com:443 \\\n    -groups X25519MLKEM768\n```\n\n**OpenSSL 3.0-3.4 with oqs-provider:**\n```bash\n# Configure oqs-provider\n# \u002Fetc\u002Fssl\u002Fopenssl-oqs.cnf\n[openssl_init]\nproviders = provider_sect\n\n[provider_sect]\ndefault = default_sect\noqsprovider = oqsprovider_sect\n\n[default_sect]\nactivate = 1\n\n[oqsprovider_sect]\nactivate = 1\nmodule = \u002Fusr\u002Flibs\u002Foqs-provider\u002Foqsprovider.so\n\n# Test hybrid TLS\nOPENSSL_CONF=\u002Fetc\u002Fssl\u002Fopenssl-oqs.cnf \\\nopenssl s_client -connect server.example.com:443 \\\n    -groups x25519_mlkem768\n```\n\n**Web Server Configuration for Hybrid TLS:**\n\nApache httpd:\n```apache\nSSLEngine on\nSSLCertificateFile \u002Fetc\u002Fssl\u002Fcerts\u002Fserver.crt\nSSLCertificateKeyFile \u002Fetc\u002Fssl\u002Fprivate\u002Fserver.key\nSSLOpenSSLConfCmd Curves X25519MLKEM768:X25519:prime256v1\nSSLProtocol -all +TLSv1.2 +TLSv1.3\n```\n\nNGINX:\n```nginx\nssl_ecdh_curve X25519MLKEM768:X25519:prime256v1;\nssl_protocols TLSv1.2 TLSv1.3;\nssl_prefer_server_ciphers on;\n```\n\n### Phase 4: ML-KEM Key Encapsulation Validation\n\nValidate that ML-KEM (CRYSTALS-Kyber) key encapsulation works correctly in your\nenvironment:\n\n```python\n# Test ML-KEM key encapsulation at all security levels\npython scripts\u002Fagent.py --action test_mlkem \\\n    --output mlkem_validation.json\n```\n\nML-KEM parameter comparison:\n\n| Parameter | ML-KEM-512 | ML-KEM-768 | ML-KEM-1024 |\n|-----------|-----------|-----------|------------|\n| Security Level | NIST Level 1 | NIST Level 3 | NIST Level 5 |\n| Public Key Size | 800 bytes | 1,184 bytes | 1,568 bytes |\n| Ciphertext Size | 768 bytes | 1,088 bytes | 1,568 bytes |\n| Shared Secret | 32 bytes | 32 bytes | 32 bytes |\n| Comparable To | AES-128 | AES-192 | AES-256 |\n\n### Phase 5: ML-DSA Digital Signature Validation\n\nValidate ML-DSA (CRYSTALS-Dilithium) signature operations:\n\n```python\n# Test ML-DSA digital signatures\npython scripts\u002Fagent.py --action test_mldsa \\\n    --output mldsa_validation.json\n```\n\nML-DSA parameter comparison:\n\n| Parameter | ML-DSA-44 | ML-DSA-65 | ML-DSA-87 |\n|-----------|----------|----------|----------|\n| Security Level | NIST Level 2 | NIST Level 3 | NIST Level 5 |\n| Public Key Size | 1,312 bytes | 1,952 bytes | 2,592 bytes |\n| Signature Size | 2,420 bytes | 3,293 bytes | 4,595 bytes |\n| Secret Key Size | 2,560 bytes | 4,032 bytes | 4,896 bytes |\n\n### Phase 6: Migration Roadmap Generation\n\nGenerate a prioritized migration roadmap based on inventory and assessment results:\n\n```python\n# Generate complete migration roadmap\npython scripts\u002Fagent.py --action roadmap \\\n    --scan-results tls_inventory.json \\\n    --agility-results agility_report.json \\\n    --output migration_roadmap.json\n```\n\nThe roadmap prioritizes systems by:\n1. **Data sensitivity**: Systems handling long-lived secrets migrate first\n2. **Exposure level**: Internet-facing services before internal\n3. **Crypto-agility**: Systems that can easily swap algorithms first\n4. **Compliance requirements**: Federal\u002Fregulated systems per NIST IR 8547 timeline\n5. **Dependency chains**: Libraries and frameworks before applications\n\n## Examples\n\n### Full Assessment Pipeline\n\n```bash\n# Step 1: Scan all TLS endpoints\npython scripts\u002Fagent.py --action scan_tls --targets hosts.txt --output scan.json\n\n# Step 2: Assess crypto-agility\npython scripts\u002Fagent.py --action assess_agility --scan-results scan.json --output agility.json\n\n# Step 3: Test hybrid TLS on critical servers\npython scripts\u002Fagent.py --action test_hybrid_tls --target critical.example.com:443\n\n# Step 4: Validate ML-KEM support\npython scripts\u002Fagent.py --action test_mlkem --output mlkem.json\n\n# Step 5: Validate ML-DSA support\npython scripts\u002Fagent.py --action test_mldsa --output mldsa.json\n\n# Step 6: Generate migration roadmap\npython scripts\u002Fagent.py --action roadmap --scan-results scan.json --agility-results agility.json --output roadmap.json\n```\n\n### Quick Server Assessment\n\n```bash\n# Single server PQC readiness check\npython scripts\u002Fagent.py --action scan_tls --target server.example.com:443\n```\n\n## Validation Checklist\n\n- [ ] Cryptographic inventory covers all TLS endpoints, certificates, and key stores\n- [ ] All quantum-vulnerable algorithms (RSA, ECDH, ECDSA, DH, DSA) are identified\n- [ ] Crypto-agility assessment documents library versions and upgrade paths\n- [ ] Hybrid TLS (X25519MLKEM768) tested on representative server configurations\n- [ ] ML-KEM key encapsulation validated at target security level (768 recommended)\n- [ ] ML-DSA signature verification validated for certificate chain use\n- [ ] SLH-DSA (FIPS 205) evaluated as backup signature algorithm\n- [ ] Migration roadmap prioritizes by data sensitivity and compliance timeline\n- [ ] OpenSSL version and oqs-provider compatibility confirmed\n- [ ] Key size increases accounted for in network and storage capacity planning\n- [ ] HSM\u002FKMS compatibility with PQC algorithms verified\n- [ ] Performance impact of PQC algorithms benchmarked under production load\n- [ ] \"Harvest now, decrypt later\" risk assessed for sensitive data channels\n- [ ] Certificate Authority PQC readiness confirmed for certificate issuance\n\n## References\n\n- NIST PQC Standards: https:\u002F\u002Fcsrc.nist.gov\u002Fprojects\u002Fpost-quantum-cryptography\n- FIPS 203 (ML-KEM): https:\u002F\u002Fcsrc.nist.gov\u002Fpubs\u002Ffips\u002F203\u002Ffinal\n- FIPS 204 (ML-DSA): https:\u002F\u002Fcsrc.nist.gov\u002Fpubs\u002Ffips\u002F204\u002Ffinal\n- FIPS 205 (SLH-DSA): https:\u002F\u002Fcsrc.nist.gov\u002Fpubs\u002Ffips\u002F205\u002Ffinal\n- NIST SP 1800-38 Migration Guide: https:\u002F\u002Fwww.nccoe.nist.gov\u002Fcrypto-agility-considerations-migrating-post-quantum-cryptographic-algorithms\n- NIST IR 8547 Transition Timeline: https:\u002F\u002Fcsrc.nist.gov\u002Fpubs\u002Fir\u002F8547\u002Fipd\n- Open Quantum Safe Project: https:\u002F\u002Fopenquantumsafe.org\u002F\n- oqs-provider for OpenSSL: https:\u002F\u002Fgithub.com\u002Fopen-quantum-safe\u002Foqs-provider\n- OQS TLS Integration: https:\u002F\u002Fopenquantumsafe.org\u002Fapplications\u002Ftls.html\n- CISA PQC Migration Strategy: https:\u002F\u002Fwww.cisa.gov\u002Fsites\u002Fdefault\u002Ffiles\u002F2024-09\u002FStrategy-for-Migrating-to-Automated-PQC-Discovery-and-Inventory-Tools.pdf\n- IETF Hybrid Key Exchange Draft: https:\u002F\u002Fdatatracker.ietf.org\u002Fdoc\u002Fdraft-ietf-tls-hybrid-design\u002F\n- CycloneDX Crypto BOM: https:\u002F\u002Fcyclonedx.org\u002Fuse-cases\u002Fcryptographic-key\u002F\n",{"cve":44,"name":5,"tags":46,"capec":52,"model":53,"tools":54,"domain":35,"maxTurns":58,"nist_csf":59,"subdomain":63,"description":7},[45],"CVE-2021-26855",[33,23,22,47,48,49,50,51,29],"ML-KEM","ML-DSA","FIPS-203","FIPS-204","hybrid-TLS",[],"sonnet",[55,32,56,57],"Read","Glob","Grep",20,[60,61,62],"PR.DS-01","PR.DS-02","PR.DS-10","cryptography","main","a91f1293287ffa9f4f1b8f486cd6e835a1568c84","skills\u002Fcrypto\u002Fpostquantum\u002Fpost\u002Fdetect","https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace","https:\u002F\u002Fgithub.com\u002FDCx7C5","#Python","2026-09-01 11:21:00",{"source":8,"skillName":5,"commands":72,"prompt":82,"zipAvailable":83},[73,76,79],{"tool":74,"command":75},"npx","npx skills add DCx7C5\u002Fai-marketplace --skill postquantum-post-detect",{"tool":77,"command":78},"bunx","bunx skills add DCx7C5\u002Fai-marketplace --skill postquantum-post-detect",{"tool":80,"command":81},"pnpm","pnpm dlx skills add DCx7C5\u002Fai-marketplace --skill postquantum-post-detect","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fcrypto\u002Fpostquantum\u002Fpost\u002Fdetect\u002FSKILL.md",true,[85],{"path":86,"resourceType":87,"resourceTypeDesc":88,"sizeBytes":89,"sourceHtmlUrl":90},"index.json","REFERENCE","参考文档",682,"https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fcrypto\u002Fpostquantum\u002Fpost\u002Fdetect\u002Findex.json",[92,116,136,157,179,195],{"skillNo":93,"name":94,"nameZh":6,"description":95,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":96,"categories":97,"keywords":98,"publishedAt":39},"01M71HAPZ01KQ30RKTB0FFSQ05","services-wmi-persistence-detect","Detect WMI event subscription persistence by enumerating ActiveScriptEventConsumer, CommandLineEventConsumer, and permanent subscriptions in the WMI repository.","https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fwindows\u002Fservices\u002Fwmi\u002Fpersistence\u002Fdetect\u002FSKILL.md",[],[99,19,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,35,115],"services","services wmi persistence detect","wmi","persistence","de","cm","process","activescript","event","subscriptions","commandline-consumer","repository","subscription","event-subscription","t1546.003","forensics","process-forensics",{"skillNo":117,"name":118,"nameZh":6,"description":119,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":120,"categories":121,"keywords":122,"publishedAt":39},"01M71HAK6JTTTS229T17WJMMCG","services-wmi-exec-exploit","Perform lateral movement across Windows networks using WMI-based remote execution techniques including Impacket wmiexec.py, CrackMapExec, and native WMI commands for stealthy post-exploitation during red team engagements.","https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fwindows\u002Fservices\u002Fwmi\u002Fexec\u002Fexploit\u002FSKILL.md",[],[123,99,124,101,125,126,127,35,32,128,129,28,130,131,103,132,133,25,134,135],"exploit","services wmi exec exploit","exec","remote","traffic","analysis","team","crackmapexec","native","command","lateral movement","lateral-movement","Impacket",{"skillNo":137,"name":138,"nameZh":6,"description":139,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":140,"categories":141,"keywords":142,"publishedAt":39},"01M71HAG6MHKNQV8KDZKMT4886","registry-artifact-extract","Extract and analyze Windows Registry hives to uncover user activity, installed software, autostart entries, and evidence of system compromise.","https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fwindows\u002Fregistry\u002Fartifact\u002Fextract\u002FSKILL.md",[],[143,144,145,146,147,148,35,32,149,128,150,151,103,25,152,153,154,155,156,53],"artifact","registry","registry artifact extract","extract","evidence-collection","artifact-analysis","collection","analyze","uncover","software","activity","digital-forensics","windows-registry","regripper",{"skillNo":158,"name":159,"nameZh":6,"description":160,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":161,"categories":162,"keywords":163,"publishedAt":39},"01M71HACR4A8XTWTTSXK4124AA","processes-token-impersonate-detect","Detect Windows token impersonation and privilege abuse including SeImpersonatePrivilege exploitation via Potato attacks and token stealing techniques.","https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fwindows\u002Fprocesses\u002Ftoken\u002Fimpersonate\u002Fdetect\u002FSKILL.md",[],[19,164,165,166,167,168,169,104,170,35,115,171,172,173,174,175,176,177,178,103],"processes token impersonate detect","token","processes","attacks","windows","escalation","techniques","privilege-escalation","seimpersonate","token-impersonation","printspoofer","exploitation","potato","impersonation","via",{"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":15,"licenseFileUrl":6,"sourceHtmlUrl":183,"categories":184,"keywords":185,"publishedAt":39},"01M71HAABSB4Z6QFSXEG00R4RK","processes-thread-injection-detect","Detect Windows thread injection techniques including CreateRemoteThread, QueueUserAPC, NtCreateThreadEx, and thread hijacking via process memory analysis.","https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fwindows\u002Fprocesses\u002Fthread\u002Finjection\u002Fdetect\u002FSKILL.md",[],[186,187,19,188,166,168,189,104,190,170,35,115,128,191,192,193,194,178,103,105],"thread","processes thread injection detect","injection","memory","process-injection","api","apc-injection","thread-injection","nt-api",{"skillNo":196,"name":197,"nameZh":6,"description":198,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":199,"categories":200,"keywords":201,"publishedAt":39},"01M71HA7H311V5G14WMX58HQSS","processes-hollow-technique-detect","Detect process hollowing (RunPE) by identifying processes with mismatched image paths between PEB and VAD tree, or unmapped PE headers in memory.","https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fwindows\u002Fprocesses\u002Fhollow\u002Ftechnique\u002Fdetect\u002FSKILL.md",[],[202,19,166,203,189,104,204,205,35,115,206,207,208,209,210,211,103,105,212,213],"processes hollow technique detect","tree","memory-forensics","process-hollow","peb","runpe","image","pe-header","in memory","with","mismatched","headers"]