Skill: Post-Quantum & Modern National Cryptography Attack

SkillSearch

Post-quantum and modern national cryptography attack surface testing covering NIST PQC candidates (ML-KEM/ML-DSA/SLH-DSA), hybrid TLS analysis, QKD/BB84 protocol attacks, Chinese national crypto (SM2/SM3/SM4/SM9) implementation flaws, lattice/hashing signature probing, and quantum-vulnerable RSA/ECC asset discovery using liboqs, GmSSL, cloudflare/circl, OQS-OpenSSL, and PQCrypto-Break.

Available today. Use it from your connected AI after setup.

Connect ahel once, and every AI you use reads what you have installed.

Then ask your AI: use the Skill: Post-Quantum & Modern National Cryptography Attack skill

What this skill tells your AI

The instructions your AI receives, as published by brucesongs/kali-claw in skills/quantum-crypto-attack/SKILL.md and read by ahel’s review.

Supplementary Files:

  • payloads.md — Command catalogue for liboqs, OQS-OpenSSL, GmSSL, cloudflare/circl, PQCrypto-Break, plus PoC code for quantum-vulnerability inventory, Shor/Grover impact modelling, ML-KEM/ML-DSA probing, hybrid TLS analysis, BB84 photon-number-splitting, SM2 side-channel, SM4 cache timing, and crypto-agility stress tests — 19 sections with real OpenSSL/GmSSL commands.
  • test-cases.md — Structured test cases (RSA/ECC quantum exposure inventory, ML-KEM Kyber parameter audit, hybrid TLS handshake analysis, GmSSL SM2/SM3 review, QKD BB84 PNS PoC, lattice side-channel timing, crypto-agility failover drill, post-quantum migration roadmap) — 12 cases across 6 categories with verification / pass-criteria checklist.
  • guides/quantum-crypto-attack-playbook.md — End-to-end playbook: scoping → quantum exposure inventory → PQC config audit → national crypto testing → QKD/protocol attacks → migration roadmap. Includes pre-assessment checklist, NIST SP 800-208 / 800-227 mapping, hybrid TLS deployment matrix, and a prioritized migration report template. Adds Side-Channel Attack Labs and QKD Implementation Audits sections.
  • guides/pqc-migration-assessment-playbook.md — Post-quantum cryptography migration assessment playbook: regulatory landscape (NIST / CNSA 2.0 / ETSI / GB/T 38636), NIST PQC timeline and algorithm selection, SNDL threat modeling, hybrid TLS rollout, KEM/signature parameter selection, SM-series migration for China compliance, crypto-agility framework, and assessment deliverables template. Includes real-world case studies (Cloudflare KEMTLS, Google CECPQ2, Signal PQXDH, Apple PQ3).
  • guides/quantum-crypto-attack-deep-dive.md — Operator's manual for hardening and operating a hybrid-PQC + lattice-signature stack in production: OpenSSL 3.x oqs-provider configuration, hybrid PKI generation, hybrid TLS server/client negotiation with wire-level capture verification, constant-timeness lab (dudect + ctgrind + ChipWhisperer TVLA), fault-injection labs (loop-abort, skipping, RNG subversion with re-encryption countermeasure), four CTF-style scenarios with worked solutions (silent downgrade, non-constant-time NTT, deterministic-signing nonce reuse, hybrid-signature chain downgrade), operational telemetry + SLO dashboard spec, crypto-agility disable drill, performance/bandwidth budgeting, and a 16-item pre-deployment checklist.

Summary

Post-quantum and modern national cryptography attack surface testing. This skill is forward-looking and preparation-focused: it does not assume a cryptographically relevant quantum computer (CRQC) exists today, but evaluates whether systems will survive the day one becomes available, and tests the implementation correctness of the post-quantum and national algorithms that defenders are racing to adopt.

Tools: liboqs, OQS-OpenSSL, GmSSL, cloudflare/circl, PQCrypto-Break, TNO Penguin, Qiskit (simulator), RsaCtfTool (ROCA), openssl s_client (TLS 1.3 groups), oqs-provider, sphincs-utils, gmssl-cli

Domain: cryptography

MITRE ATT&CK: T1040-Network Sniffing (crypto layer), T1573-Encrypted Channel (PQC analysis) — forward-looking, no canonical MITRE mapping yet

Description

This skill tests three things that defenders must get right before a Cryptographically Relevant Quantum Computer (CRQC) is announced, and one thing they must get right today:

  1. Quantum exposure inventory — Which RSA/ECC keys in the organization will become forgeable the day Shor's algorithm runs at scale? Long-lived CA keys, root signing keys, and identity-bound keys are most exposed. Data covered by "store-now-decrypt-later" (SNDL) collection is already lost if confidentiality depends on classical public-key encryption.
  2. Post-quantum cryptography (PQC) adoption correctness — The NIST PQC standards (FIPS 203 ML-KEM, FIPS 204 ML-DSA, FIPS 205 SLH-DSA) shipped in 2024. Real-world deployments use hybrid modes (classical + PQC) for transition safety. Implementation flaws — incorrect parameter sets, lattice side-channels, deterministic-signature nonce reuse, hybrid downgrade attacks — are the new attack surface.
  3. National cryptography implementation — Chinese national cryptography (SM2/SM3/SM4/SM9, mandatory in PRC government, finance, and critical infrastructure), Russian GOST, and other national suites are required in their respective markets. Their mathematical foundations are sound, but implementations (GmSSL, Tongji SSL, BabaSSL) have shipped side-channel bugs, weak curve parameters, and TLS handshake divergences.
  4. QKD/BB84 protocol attack surface — Quantum Key Distribution (BB84, E91, MDI-QKD) promises information-theoretic security but real-world deployments (commercial QKD boxes from ID Quantique, Chinese QKD backbones) have been broken by photon-number-splitting, detector blinding, and Trojan-horse attacks that exploit implementation gaps between the mathematical model and the hardware.

Core Insight: The threat model for this skill is not "an attacker breaks NIST Round 4 today." It is "a defender deploys ML-KEM-768 tomorrow and accidentally enables a downgrade-to-classical path, or ships SM4-ECB with a fixed key in a TLS stack that they believed was sound because it passed the certification." The attacker surface is implementation and migration risk, exactly as it has been for classical crypto. The math is hard; the bugs are familiar.

Key Attack Surfaces:

  • Shor-vulnerable asset inventory — RSA-2048 and ECC P-256 keys become forgeable under a CRQC with ~20M physical qubits and hours of runtime. Anything that needs to remain confidential for >10 years and uses classical public-key encryption today is already exposed to SNDL collection.
  • Grover's effect on symmetric keys — AES-128 offers ~64 bits of post-quantum security (Grover's quadratic speedup). NIST recommends AES-256 for long-term quantum-resistant confidentiality. SHA-256 offers ~128 bits post-quantum (still safe); SHA-1 is broken classically and post-quantum.
  • PQC parameter misuse — ML-KEM-512 / ML-KEM-768 / ML-KEM-1024 have different security levels (NIST Levels 1/3/5). Picking the wrong one for the threat model, or shipping a development parameter set in production, is the equivalent of shipping RSA-512 in 2010.
  • Hybrid downgrade attacks — A hybrid TLS handshake that offers x25519+mlkem768 but the server also accepts plain x25519 can be downgraded by an active MITM if the negotiation is not authenticated by the Finished message. This is the post-quantum equivalent of the POODLE/BAR-Mitzvah downgrade family.
  • Lattice side-channel — ML-KEM (Kyber) decryption and ML-DSA (Dilithium) signing involve operations (NTT, rejection sampling) that have already been shown to leak timing and power information. Cache-timing attacks on matrix-vector multiplication are the new Bleichenbacher.
  • Hash-based signature state — SLH-DSA (SPHINCS+) is stateless, but the older XMSS/LMS schemes are stateful — reusing a one-time signature key state is catastrophic. State management bugs in HSM-backed XMSS deployments are the post-quantum RNG-reuse bug.
  • QKD implementation attacks — Photon-Number-Splitting (PNS), Detector Blinding, Trojan-Horse, and After-Pulse attacks break commercial QKD hardware by exploiting the gap between the idealized single-photon source and the real attenuated-laser/detector hardware. Academic demonstrations (Lydersen 2010, Weier 2011) are reproducible.
  • Chinese national crypto (SM2/SM3/SM4/SM9) flaws — SM2 (EC-based, analogous to ECDSA+ECIES on a 256-bit curve), SM3 (256-bit hash, Merkle-Damgard like SHA-256), SM4 (128-bit block cipher, the AES counterpart), SM9 (identity-based encryption). Implementations (GmSSL, Tongji SSL, BabaSSL, Tongsuo) have shipped weak random generation, side-channel-leaky scalar multiplication, and TLS handshake incompatibilities.
  • ROCA and related RSA vulnerabilities — CVE-2017-15361 (ROCA) affected Infineon-generated RSA keys where prime generation had a detectable fingerprint enabling factorization. Although classical, ROCA is the canonical example of "your RSA key is already weaker than you think" and is a model for PQC parameter-generation bugs.

Difference from crypto-attacks: Crypto-attacks covers classical cryptographic algorithm weaknesses (RSA, AES, ECDSA, padding oracles, JWT attacks, hash length extension). Quantum-crypto-attack covers post-quantum algorithms (ML-KEM, ML-DSA, SLH-DSA), national suites (SM2/SM3/SM4/SM9, GOST), QKD protocols, and the migration risk of moving from classical to post-quantum. The boundary: if the algorithm has been a NIST standard since the 1990s and is not a national suite, it belongs in crypto-attacks; if it is post-1995 lattice-based, hash-based signature, code-based, multivariate, QKD, or a national suite, it belongs here.

Difference from vpn-attack: VPN-attack covers TLS/IPsec at the network layer (cipher suite downgrade, IKE aggressive mode, weak DH groups, VPN client exploitation). Quantum-crypto-attack covers the post-quantum TLS extensions (hybrid key exchange, X25519+ML-KEM), the national TLS variants (GM SSL, Tongji SSL), and the QKD-as-key-source deployment model. Where vpn-attack finds a weak DH group, quantum-crypto-attack finds that the hybrid PQC handshake can be downgraded.

Difference from blockchain-web3: Blockchain-web3 covers smart contract and DeFi logic bugs. The cryptography behind modern blockchains (secp256k1, Ed25519, BLS) is classical and lives in crypto-attacks — but blockchains that adopt post-quantum signatures (e.g., hash-based signatures via QuipNetwork/hashsigs-solidity, lattice-based schemes in QRL) land here. The crossover case is auditing a bridge that uses a PQC signature scheme for validator consensus.

Difference from web-xss / web-sqli: Those skills cover application-layer injection. They are not cryptographic skills. The only overlap is when an XSS exfiltrates a long-lived RSA private key from the browser — at which point the key exposure (Shor-vulnerable asset loss) is a quantum-crypto-attack finding, even though the vector was XSS.

Difference from security-misconfiguration: Security-misconfiguration covers default credentials, verbose errors, missing headers. Quantum-crypto-attack covers algorithm-agility misconfiguration (server cannot switch algorithms in an emergency), wrong PQC parameter sets, and disabled hybrid modes — which is a specialized cryptographic misconfiguration with longer-term consequences.


Use Cases

  • Post-quantum migration readiness assessment — Inventory every long-lived RSA/ECC key across the estate (CA, root, signing, identity, code-signing), classify by Shor-vulnerability and remaining confidentiality lifetime, produce a prioritized migration roadmap aligned with NIST SP 800-227 and CNSA 2.0.
  • Hybrid TLS deployment validation — Validate that a server advertising x25519_kyber768 or x25519_mlkem768 (draft-ietf-tls-hybrid-design) actually negotiates the hybrid group, rejects downgrades, and that the Finished message binds the negotiation. Used before flipping a hybrid TLS configuration to production.
  • ML-KEM / ML-DSA / SLH-DSA implementation audit — Static and dynamic review of a vendor's FIPS 203/204/205 implementation: parameter sets in use, decapsulation constant-time behavior, signature nonce handling, deterministic vs randomized signature mode, key serialization.
  • Chinese national crypto compliance & flaw testing — Test a GM SSL (GB/T 38636-2020) deployment for SM2/SM3/SM4 correctness, ECC scalar-multiplication side-channel, SM4 mode misuse (ECB with structured plaintext), and handshake divergence from RFC 8998 (TLS 1.3 with SM cipher suites).
  • QKD/BB84 protocol attack surface review — For organizations deploying commercial QKD hardware (finance, government, defense), evaluate susceptibility to photon-number-splitting, detector blinding, Trojan-horse, and side-channel attacks; recommend decoy-state and device-independent countermeasures.
  • "Store-now-decrypt-later" risk assessment — Identify data flows where long-term-confidential data (health, legal, M&A, state secrets) traverses classical public-key encryption, and quantify SNDL exposure against plausible CRQC timelines (NIST/ETSI/NSA estimates).
  • Crypto-agility stress test — Verify that a system can switch algorithms in response to a "drop everything and migrate" emergency (the "Cryptopocalypse" exercise). Can the TLS stack disable RSA in 24 hours? Can the PKI reissue every certificate under a new algorithm? This is rarely tested and routinely fails.
  • Lattice side-channel lab assessment — In an authorized lab setting, perform timing and power analysis on ML-KEM decapsulation / ML-DSA signing hardware (HSM, secure element) to detect non-constant-time NTT or rejection-sampling leakage.
  • Hash-based signature state-management audit — Audit XMSS/LMS deployments (stateful hash-based signatures per RFC 8391/8554) for state-reuse risk in HSM-backed multi-signer setups; verify SLH-DSA (SPHINCS+) deployments are stateless and parameterized correctly.
  • PQC vulnerability disclosure triage — When a new PQC implementation CVE lands (e.g., a Kyber decapsulation timing leak), rapidly determine which assets in the estate are affected and produce an emergency-patch priority list.

Core Tools

ToolPurposeCommand Example
liboqsReference C library implementing all NIST PQC candidates; foundation for OQS-OpenSSL, oqs-providergit clone https://github.com/open-quantum-safe/liboqs && cmake -B build && cmake --build build
OQS-OpenSSL / oqs-providerOpenSSL 3.x provider enabling PQC algorithms in TLS (hybrid and pure-PQC handshakes)openssl list -providers -provider oqsprovider; openssl s_client -connect h:443 -groups x25519_kyber768
cloudflare/circlGo crypto library with Kyber, Dilithium, P-256+Kyber hybrid; used to test Cloudflare-style hybrid TLS edgego test -run Kyber ./crypto/kem/kyber/...
GmSSLChinese national crypto implementation of SM2/SM3/SM4/SM9 + GM SSL (GB/T 38636); the canonical open-source 国密 stackgmssl sm2 -sign -in sm3.hash -key sm2.pem; gmssl s_client -connect h:443 -gmtls
Tongsuo / BabaSSLAlibaba/Tongsuo OpenSSL fork with SM and PQC support; production-deployed in Chinese cloud infratongsuo s_server -accept 443 -tls1_3 -ciphersuites TLS_SM4_GCM_SM3
PQCrypto-Break / TNO PenguinResearch tooling for lattice side-channel and parameter-set probing of PQC implementations./penguin --target kyber768 --mode timing --samples 100000
QiskitIBM quantum simulator for modelling Shor/Grover cost on small problem instances (educational / capacity modelling)from qiskit.algorithms import Shor; Shor(N=15).run(...)
RsaCtfTool (ROCA mode)Classical tool; ROCA detection (--attack roca) flags Infineon-fingerprint RSA keys (CVE-2017-15361)RsaCtfTool --publickey pub.pem --attack roca --private
openssl s_client (TLS 1.3 groups)Standard OpenSSL; -groups selects key exchange including PQC hybrid once oqs-provider loadedopenssl s_client -connect host:443 -tls1_3 -groups x25519_mlkem768 -msg
oqs-demos / oqs-testTest harness from Open Quantum Safe for probing which hybrid groups a public TLS server supportsoqs-test --host h --port 443 --json
gmssl-cli / GmSSL JavaCLI and Java bindings for scripting SM2/SM3/SM4 audit and cert generationgmssl genpkey -algorithm SM2 -out sm2key.pem
hash-sigs (XMSS/LMS) libsReference stateful hash-based signature libraries (RFC 8391/8554) for state-mgmt auditxmss genkey --params XMSS-SHA2_10_256 -o xmss.key

Auxiliary tooling: Wireshark (PQC TLS handshake dissector), sslscan/testssl.sh (PQC group detection via OpenSSL backend), 侧信道 analyzers (ChipWhisperer, Riscure Inspector for power side-channel lab work), Wireshark QKD dissector (commercial QKD key-sifting protocol).


Methodology

Attack Chain

[1] Quantum Exposure Inventory     [2] Shor/Grover Impact Modelling
  - RSA/ECC key discovery             - Per-key forgeability timeline
  - Key lifetime / purpose            - Symmetric key strength reduction
  - SNDL data-flow mapping            - Hash function collision horizon
  - CA / root / signing key map       - Stateful-sig state-reuse check
        |                                    |
        v                                    v
[3] PQC Config Audit                [4] National Crypto Testing
  - Hybrid TLS negotiation            - SM2/SM3/SM4/SM9 implementation
  - ML-KEM/ML-DSA/SLH-DSA params      - GM SSL / Tongji SSL handshake
  - Downgrade resistance              - Side-channel on scalar mult
  - Lattice side-channel (lab)        - SM4 mode / key hygiene
        |                                    |
        v                                    v
[5] QKD / Protocol Attacks           [6] Migration Roadmap & Reporting
  - BB84 PNS / detector blinding      - Prioritized key/cert replacement
  - Decoy-state verification          - Crypto-agility drill results
  - Side-channel on QKD hardware      - Hybrid → pure-PQC cutover plan
  - Key-sifting MITM                  - CNSA 2.0 / NIST SP 800-227 mapping

Phase 1 — Quantum Exposure Inventory

Build a complete map of every long-lived asymmetric key in the estate. Sources: PKI inventory, internal CA database, code-signing cert list, SSH CA keys, KMS/HSM key attestation, certificate transparency logs. For each key, record: algorithm, key size, generation date, expected end-of-life, data it protects, and the remaining confidentiality lifetime of that data. The output is a Shor-exposure matrix that ranks keys by risk = sensitivity × (remaining confidentiality lifetime − CRQC arrival estimate).

Phase 2 — Shor / Grover Impact Modelling

For each inventoried key, classify its post-quantum fate. RSA and ECC (any practical size) are forgeable under a CRQC — these are Shor-vulnerable. DSA, ECDSA, EdDSA, Diffie-Hellman, ECDH all collapse. Symmetric keys: AES-128 → ~64-bit post-quantum (upgrade to AES-256), SHA-256 → ~128-bit post-quantum (acceptable), ChaCha20 → ~128-bit post-quantum (acceptable). Hash-based signatures (SLH-DSA, XMSS, LMS) are not weakened by Shor. Lattice-based (ML-KEM, ML-DSA) and code-based (Classic McEliece) are designed to be quantum-resistant. The deliverable is a per-asset quantum-risk classification.

Phase 3 — PQC Configuration Audit

For systems already deploying PQC, verify the configuration is correct. Hybrid TLS: confirm the negotiated group is the hybrid (e.g., x25519_mlkem768), confirm the server rejects pure-classical downgrades, confirm the Finished message binds the group selection. Parameter sets: confirm ML-KEM-768 (NIST Level 3) or stronger is in use, not ML-KEM-512 for production. Signature schemes: confirm deterministic-mode ML-DSA is not leaking through side-channel; confirm SLH-DSA parameter sets match the threat model (fast vs small variants). Crypto-agility: confirm the system can disable an algorithm in 24 hours if a catastrophic PQC break is announced.

Phase 4 — National Cryptography Testing

For SM2/SM3/SM4/SM9 deployments (mandatory in PRC government/finance/critical infrastructure per GB/T 38636-2020 and GB/T 32918/32905/32907): audit the implementation (GmSSL, Tongsuo, BabaSSL, Tongji SSL). Check SM2 scalar-multiplication constant-timeness, SM3 collision resistance implementation (length extension on Merkle-Damgard), SM4 mode usage (GCM/CTR, never ECB), SM9 master-secret handling. Verify GM SSL handshake (ECDHE-SM2 + SM3 + SM4-GCM) is negotiated per RFC 8998, and that the deployment is not silently falling back to TLS 1.2 with RSA.

Phase 5 — QKD / Protocol Attacks

For QKD deployments (commercial ID Quantique Clavis^3, Chinese QKD backbones, quantum-secured metropolitan networks): model the BB84/E91/MDI-QKD attack surface. PNS attacks apply when the source is an attenuated laser (multi-photon pulses). Detector blinding applies to InGaAs APD detectors. Trojan-horse attacks inject light back into the source. Decoy-state protocols mitigate PNS — verify they are enabled and correctly parameterized. Device-independent QKD (DI-QKD) closes most implementation loopholes — verify whether the deployment is DI or only BB84. Note: QKD security is implementation-bound; even "mathematically proven" QKD is only as strong as its hardware.

Phase 6 — Migration Roadmap & Reporting

Synthesize findings into a prioritized roadmap aligned with NIST SP 800-227 (PQC migration), CNSA 2.0 (NSA national-security suite), and any applicable national mandates (e.g., China's 国密 compliance schedule). Rank by: (1) Shor-exposed long-lived keys, (2) SNDL data flows, (3) PQC parameter-misuse findings, (4) National crypto implementation flaws, (5) Crypto-agility gaps. Provide a hybrid → pure-PQC cutover plan with rollback, and a post-quantum readiness score (0-100) comparable across business units.

Defense Perspective

Defense MeasureDescriptionAttack Types Countered
Hybrid TLS (X25519+ML-KEM)Classical + PQC key exchange in a single handshake; PQC break does not collapse sessionPure-PQC lattice break, classical-only downgrade, SNDL on TLS sessions
ML-KEM-768 minimum parameterNIST PQC Level 3 (AES-192-equivalent); rejects weak ML-KEM-512 production useParameter-set misuse, PQC level-1 downgrade
Crypto-agility infrastructureAlgorithm registry, cert auto-rotation, kill-switch to disable an algorithm in <24hAny future catastrophic algorithm break (classical or PQC)
Constant-time lattice implConstant-time NTT, rejection sampling, matrix-vector multiply in ML-KEM/ML-DSATiming and cache side-channel on lattice operations
Decoy-state + DI-QKDDecoy-state protocol closes PNS loophole; DI-QKD closes detector attacksPNS, detector blinding, Trojan-horse on QKD hardware
SM2/SM3/SM4 with vetted libsUse GmSSL/Tongsuo with constant-time SM2 scalar mult, SM4-GCM only, RFC 8998 TLS 1.3SM scalar-mult side-channel, SM4 ECB, GM TLS handshake downgrade
AES-256 for long-term dataQuadruples post-quantum brute-force cost vs AES-128 (Grover)SNDL on symmetric-encrypted long-term data
HSM-backed XMSS state mgmtHardware-enforced monotonic state counter for stateful hash-based signaturesXMSS/LMS state-reuse catastrophic forgery
FIPS 203 errata (2026-07)Apply 2026-07 published errata to ML-KEM implementations; verify parameter sets against revised standardImplementation drift from canonical ML-KEM
FIPS 204 / FIPS 205 alignmentML-DSA + SLH-DSA — use both signatures (lattice + hash-based) for diversitySingle-algorithm catastrophic break
CNSA 2.0 commercial rollout (2026 Q4)NSA CNSA 2.0 timeline: 2026 Q4 begins commercial adoption; 2027 Q1 firmware mandatesSNDL on national-security systems
Kyber ransomware awareness (2026-03)First weaponized PQC case — defenders must update ransomware detection signatures (classical decrypt tools fail)PQC encrypted data recovery impossible
2026 PQC Standardization Status Brief
  • FIPS 203 (ML-KEM) — published 2024-08; errata revised 2026-07
  • FIPS 204 (ML-DSA) — published 2024-08; aligned with CNSA 2.0
  • FIPS 205 (SLH-DSA) — published 2024-08; hash-based fallback
  • FIPS 206 (FN-DSA / Falcon) — draft pending
  • CNSA 2.0 (NSA) — commercial timeline: 2026 Q4 begins, 2027 Q1 firmware mandates
  • 2026-03: First Kyber-based ransomware documented (CSA research note) — PQC algorithms now weaponized by attackers

Practical Steps

1. Build the Quantum Exposure Inventory

Shortened here. Read the whole file on GitHub.

Signals

GitHub stars
71
Forks
18
Last commit
Sep 2026
Advanced
Catalog kind
skill
Gateway key
quantum-crypto-attack
Source
github.com/brucesongs/kali-claw