Security
Security profiles, attack vectors, threat models, and cryptanalysis considerations for post-quantum algorithms. What's known, what's assumed, and where vigilance is still required.
NIST security levels
NIST defines five security levels benchmarked against the computational effort required to break well-studied symmetric primitives. Levels 1, 3, and 5 map to AES key-search hardness; levels 2 and 4 map to collision and preimage hardness of SHA-256 / SHA-384.
| Level | Classical hardness | Algorithms | Typical use |
|---|---|---|---|
| 1 | AES-128 key search (2128 classical; 264 quantum via Grover) | ML-KEM-512, ML-DSA-44 is Level 2* | Short-lived data; constrained devices |
| 2 | SHA-256 collision (2128 classical; 285 quantum) | ML-DSA-44 | Digital signatures requiring collision resistance |
| 3 | AES-192 key search (2192 classical) | ML-KEM-768, ML-DSA-65 | General-purpose — recommended default |
| 5 | AES-256 key search (2256 classical) | ML-KEM-1024, ML-DSA-87, SLH-DSA-256s/f | Long-term secrets; highest-sensitivity data |
* ML-DSA-44 targets Level 2 specifically (SHA-256 collision hardness), not Level 1.
Threat models
Harvest now, decrypt later
Adversaries record encrypted traffic today to decrypt once a cryptographically relevant quantum computer (CRQC) exists. This is the primary driver for urgent PQC adoption — the window for harvested data to become exploitable is already open for data with long confidentiality requirements.
- High risk: Data with 10+ year confidentiality requirements (classified, medical, legal)
- Medium risk: Financial transactions; personal data
- Lower risk: Short-lived session data; ephemeral keys
Mitigation: deploy hybrid TLS (X25519 + ML-KEM) for all sensitive traffic now. The classical component retains today's security; the PQ component covers future quantum threats.
CRQC timeline estimates
Estimates for when a quantum computer capable of breaking RSA-2048 or ECC-256 may exist vary widely. Gidney (2025) estimates the resource requirement at roughly 1,200 logical qubits / fewer than 1 million physical (noisy) qubits for RSA-2048 — a significant reduction from earlier estimates. Timeline projections:
- Conservative: 2035–2040 (most cryptographers)
- Moderate: 2030–2035
- Aggressive: 2027–2030
Begin migration now regardless of where you place that range. Cryptographic migrations take years and the harvest window is open today.
Algorithm compromise
Mathematical advances can break or substantially weaken PQC algorithms independently of quantum computers — and unlike the quantum threat, this can happen at any time. SIKE (Supersingular Isogeny Key Encapsulation) was broken in 2022 by a classical attack in hours on a laptop. Lattice-based schemes (ML-KEM, ML-DSA) have been extensively studied with no practical breaks. Hash-based schemes (SLH-DSA) rely only on the security of the underlying hash function.
Mitigation: use hybrid mode during the transition; maintain crypto agility so algorithms can be swapped without a full system redesign.
Implementation vulnerabilities
PQC algorithms introduce new implementation challenges. The larger state, polynomial arithmetic (NTT), and sampling operations have different side-channel profiles than classical RSA or ECDSA. Use vetted, audited implementations; do not roll your own.
Attack vectors by algorithm family
Lattice-based: ML-KEM and ML-DSA
| Attack type | Vector | Assessment |
|---|---|---|
| Quantum | Lattice sieving with Grover speedup | Grover provides at most quadratic speedup; depth constraints and parallelization limits make this impractical at ML-KEM / ML-DSA parameter sizes. Parameters chosen with this in mind. |
| Classical | BKZ algorithm | Best known classical lattice reduction. Complexity is well-understood; ML-KEM / ML-DSA parameters provide 2143–2254 operations of security margin. |
| Side-channel | Timing and power analysis on NTT / sampling | NTT multiplications and rejection sampling can leak timing or power information if not implemented in constant time. Implementation-dependent — use vetted libraries. |
| Implementation | Decryption failures (ML-KEM) | ML-KEM decryption failure probability is less than 2-139. Not exploitable in practice. |
Hash-based: SLH-DSA
| Attack type | Vector | Assessment |
|---|---|---|
| Quantum | Grover's algorithm against SHA-256 / SHAKE256 | Provides quadratic speedup; SLH-DSA parameter sets are sized to maintain security even with this speedup applied. |
| Classical | Hash collision / preimage | Security reduces entirely to the underlying hash function. No structural attacks are known beyond generic hash attacks. Minimal trust assumptions. |
| Side-channel | Hash function leakage | Side-channel characteristics of SHA-256 / SHAKE256 are well-studied; countermeasures are mature. |
| Implementation | Weak randomness in hedged signing | SLH-DSA uses randomized signing by default (FIPS 205 §10.3 also defines a deterministic mode). Poor randomness in the hedged mode degrades signing toward the deterministic mode — which is still key-secure by design. The real risks from weak RNG are fault attacks and side-channel exploits, not direct key leakage. Use a CSPRNG. |
Security recommendations
Key encapsulation (ML-KEM)
- Default: ML-KEM-768 (Level 3) for most applications
- Constrained environments: ML-KEM-512 (Level 1) for IoT / embedded
- Long-term secrets: ML-KEM-1024 (Level 5)
- During transition: Always combine with X25519 or P-384 in a hybrid
Digital signatures
- High-volume APIs / authentication: ML-DSA-44 or ML-DSA-65
- General-purpose (certificates, documents): ML-DSA-65 (Level 3)
- Root CAs and firmware signing: SLH-DSA (hash-based, minimal assumptions)
- Space-constrained: FN-DSA (FIPS 206, FALCON) when available
CNSA 2.0 requirements
NSA's CNSA 2.0 mandates specific algorithm choices for National Security Systems:
- KEM: ML-KEM-1024 only
- Signatures: ML-DSA-87 for general use; LMS or XMSS for firmware signing (SLH-DSA is not included in CNSA 2.0 — LMS / XMSS are the designated firmware signing algorithms)
- Hashing: SHA-384 or SHA-512
- Symmetric: AES-256
Implementation checklist
- Constant-time: Verify that the implementation is constant-time for all secret-dependent operations
- RNG: Use OS-provided CSPRNG (
getrandom,CryptGenRandom, etc.) - Zeroization: Clear secret key material from memory after use
- Public key validation: Validate all received public keys before use
- Hybrid mode: Combine PQC with a classical algorithm during the transition period
Design systems for crypto agility. Use algorithm identifiers (OIDs) and negotiate algorithms at the protocol layer. The PQC landscape will continue to evolve as cryptanalysis matures; the ability to swap an algorithm without a full redesign is itself a security property.