Quick Decision Guide
Start here. What do you need to protect?
Hybrid Mode Recommended
During transition, use hybrid mode combining classical + PQC algorithms (e.g., X25519 + ML-KEM, ECDSA + ML-DSA) for defense in depth. This protects against both classical attacks if PQC has vulnerabilities, and quantum attacks.
I need to...
- Encrypt data at rest → AES-256-GCM
- Encrypt disk/storage → AES-256-XTS
- Encrypt data in transit → TLS 1.3 + ML-KEM/ML-DSA
- Sign documents/code → ECDSA + ML-DSA (hybrid)
- Exchange keys (quantum-safe) → X25519 + ML-KEM (hybrid)
- Hash passwords → Argon2id
- Hash data/files → SHA-384 or SHA-512
- Sign firmware/software → ECDSA + ML-DSA (hybrid)
- Long-term archive signatures → SLH-DSA
Quantum Threat
RSA and ECC (ECDSA, ECDH, P-256, P-384) will be broken by quantum computers. Start transitioning to ML-KEM and ML-DSA now, especially for data with long confidentiality requirements.
Algorithm by Use Case
What algorithm to use for each security function. Quantum-safe alternatives should be deployed in hybrid mode alongside current algorithms.
| Use Case | Current Standard | Add PQC (Hybrid) | Security Level | When to Migrate |
|---|---|---|---|---|
| Symmetric Encryption Data at rest, bulk encryption |
AES-256-GCM Quantum-Safe |
No change needed | Level 5 | Already safe |
| Disk/Storage Encryption Full disk, volume encryption |
AES-256-XTS Quantum-Safe |
No change needed | Level 5 | Already safe |
| Key Exchange TLS, VPN, secure channels |
X25519 / ECDH Vulnerable |
+ ML-KEM FIPS 203 |
Level 3 | Now - 2027 |
| Digital Signatures Code signing, documents |
ECDSA / Ed25519 Vulnerable |
+ ML-DSA FIPS 204 |
Level 3 | Now - 2030 |
| High-Security Signatures Firmware, PKI, government |
ECDSA P-384 Vulnerable |
+ ML-DSA FIPS 204 |
Level 5 | Now - 2030 |
| Long-Term Signatures Archival, 50+ year validity |
RSA-4096 Vulnerable |
SLH-DSA FIPS 205 |
Level 5 | 2025 - 2030 |
| TLS/HTTPS Web traffic encryption |
TLS 1.3 + ECDHE Partial |
TLS 1.3 + ML-KEM/ML-DSA Hybrid mode |
Level 3+ | Now - 2030 |
| SSH Remote access |
Ed25519 / ECDSA Vulnerable |
+ ML-KEM + ML-DSA OpenSSH 9.x hybrid |
Level 3 | Now - 2030 |
| Password Hashing User authentication |
Argon2id Quantum-Safe |
No change needed | N/A | Already safe |
| Data Integrity Checksums, verification |
SHA-384 / SHA-512 Quantum-Safe |
No change needed | Level 3+ | Already safe |
| Message Authentication HMAC for integrity |
HMAC-SHA-256 Quantum-Safe |
No change needed | Level 1 | Already safe |
| Random Number Generation Key generation, nonces |
CSPRNG (DRBG) Quantum-Safe |
No change needed | N/A | Already safe |
Algorithm by Data Type
What to use based on what you're protecting. Use hybrid mode (classical + PQC) for key exchange and signatures.
| Data Type | Confidentiality Lifetime | Encryption | Key Exchange (Hybrid) | Signature (Hybrid) | Priority |
|---|---|---|---|---|---|
| Classified/Government National security data |
50+ years | AES-256 | X25519 + ML-KEM-1024 | ECDSA + ML-DSA-87 | Immediate |
| Healthcare Records (PHI) HIPAA protected data |
25-50 years | AES-256 | X25519 + ML-KEM | ECDSA + ML-DSA | High |
| Financial Records Banking, transactions |
10-25 years | AES-256 | X25519 + ML-KEM | ECDSA + ML-DSA | High |
| PII (Personal Data) GDPR, CCPA scope |
10-20 years | AES-256 | X25519 + ML-KEM | ECDSA + ML-DSA | High |
| Trade Secrets / IP Proprietary information |
15-30 years | AES-256 | X25519 + ML-KEM | ECDSA + ML-DSA | High |
| Legal Documents Contracts, agreements |
20-50 years | AES-256 | X25519 + ML-KEM | ECDSA + ML-DSA | High |
| Source Code Proprietary software |
10-20 years | AES-256 | X25519 + ML-KEM | ECDSA + ML-DSA | Medium |
| Internal Communications Email, chat |
5-10 years | AES-256 | X25519 + ML-KEM | ECDSA + ML-DSA | Medium |
| Session Tokens Auth tokens, JWTs |
Hours-Days | AES-256 | ECDH (current) | ECDSA (current) | Lower |
| Public Data Marketing, public docs |
N/A | Not required | Not required | ECDSA + ML-DSA for auth | Low |
Security Levels Comparison
NIST security levels with corresponding algorithms (classical and post-quantum)
Understanding NIST Security Levels
NIST defines security levels based on the computational effort required to break an algorithm. Level 1 ≈ AES-128, Level 3 ≈ AES-192, Level 5 ≈ AES-256. Higher levels provide more security but with larger key/signature sizes.
| Category | Level 1 (128-bit) |
Level 2 (~128-bit) |
Level 3 (192-bit) |
Level 5 (256-bit) |
|---|---|---|---|---|
| Key Encapsulation FIPS 203 |
ML-KEM-512 | — | ML-KEM-768 | ML-KEM-1024 |
| Digital Signatures FIPS 204 |
— | ML-DSA-44 | ML-DSA-65 | ML-DSA-87 |
| Stateless Hash Signatures FIPS 205 |
SLH-DSA-128f | — | SLH-DSA-192f | SLH-DSA-256f |
| Symmetric Encryption Classical (quantum-safe) |
AES-128 → 64-bit post-Q* |
— | AES-192 → 96-bit post-Q* |
AES-256 → 128-bit post-Q* |
| Hash Functions Classical (quantum-safe) |
SHA-256 ~85-bit collision** |
— | SHA-384 → 192-bit post-Q |
SHA-512 → 256-bit post-Q |
| Classical Signatures Quantum-vulnerable |
ECDSA P-256 Ed25519 |
— | ECDSA P-384 | ECDSA P-521 |
| Classical Key Exchange Quantum-vulnerable |
X25519 ECDH P-256 |
— | ECDH P-384 | ECDH P-521 |
* Grover's algorithm reduces symmetric key security by half against quantum computers. Use AES-256 for 128-bit post-quantum security.
** BHT algorithm reduces SHA-256 collision resistance to ~85 bits against quantum computers. For collision-critical applications, use SHA-384 or SHA-512.
Red algorithms are vulnerable to quantum attacks (Shor's algorithm) and should be used in hybrid mode with PQC alternatives.
Key and Signature Sizes
PQC algorithms have larger keys and signatures than classical algorithms. Plan for increased bandwidth and storage requirements.
| Algorithm | Public Key | Private Key | Ciphertext/Signature |
|---|---|---|---|
| ML-KEM (Key Encapsulation) | |||
| ML-KEM-512 | 800 B | 1,632 B | 768 B |
| ML-KEM-768 | 1,184 B | 2,400 B | 1,088 B |
| ML-KEM-1024 | 1,568 B | 3,168 B | 1,568 B |
| ML-DSA (Digital Signatures) | |||
| ML-DSA-44 | 1,312 B | 2,560 B | 2,420 B |
| ML-DSA-65 | 1,952 B | 4,032 B | 3,309 B |
| ML-DSA-87 | 2,592 B | 4,896 B | 4,627 B |
| SLH-DSA (Stateless Hash Signatures) | |||
| SLH-DSA-128f | 32 B | 64 B | 17,088 B |
| SLH-DSA-192f | 48 B | 96 B | 35,664 B |
| SLH-DSA-256f | 64 B | 128 B | 49,856 B |
| Classical Algorithms (for comparison) | |||
| ECDSA P-256 | 64 B | 32 B | 64 B |
| Ed25519 | 32 B | 64 B | 64 B |
| X25519 | 32 B | 32 B | 32 B |
Compliance Requirements
Algorithm requirements by regulatory framework
| Framework | Symmetric | Key Exchange | Signatures | Hash | Deadline |
|---|---|---|---|---|---|
| CNSA 2.0 NSA / National Security |
AES-256 | ML-KEM-1024 | ML-DSA-87 | SHA-384+ | 2030 prefer 2035 required |
| FIPS 140-3 US Federal |
AES-128/256 | ML-KEM (pending) | ML-DSA (pending) | SHA-256+ | Ongoing |
| PCI DSS 4.0 Payment Card |
AES-128+ | TLS 1.2+ curves | RSA-2048+ | SHA-256+ | PQC: TBD |
| HIPAA Healthcare |
AES-128+ | Per NIST | Per NIST | SHA-256+ | Follow NIST |
| SOC 2 Service Organizations |
AES-128+ | Industry standard | Industry standard | SHA-256+ | Industry practice |
| GDPR EU Privacy |
State of art | State of art | State of art | State of art | Continuous |
| eIDAS 2.0 EU Digital Identity |
AES-256 | PQC required | PQC required | SHA-256+ | 2027+ |
Performance Comparison
Operations per second (higher is better)
| Algorithm | KeyGen/s | Encaps or Sign/s | Decaps or Verify/s | Relative Speed |
|---|---|---|---|---|
| Key Encapsulation / Key Exchange | ||||
| ML-KEM-768 | ~150,000 | ~120,000 | ~110,000 | 64× faster than ECDH |
| ML-KEM-1024 | ~100,000 | ~85,000 | ~80,000 | 45× faster than ECDH |
| ECDH P-256 | ~40,000 | ~2,000 | ~2,000 | Baseline |
| Digital Signatures | ||||
| ML-DSA-65 | ~25,000 | ~10,000 | ~30,000 | Faster than RSA |
| ML-DSA-87 | ~15,000 | ~6,000 | ~18,000 | Faster than RSA |
| ECDSA P-256 | ~40,000 | ~20,000 | ~8,000 | Fast classical |
| RSA-2048 | ~300 | ~1,200 | ~40,000 | Slow keygen/sign |
| RSA-4096 | ~40 | ~200 | ~12,000 | Very slow |
| SLH-DSA-SHA2-128f | ~300 | ~500 | ~15,000 | Slower (stateless) |
| Symmetric Encryption (1KB blocks) | ||||
| AES-256-GCM | N/A | ~3 GB/s (with AES-NI) | Hardware accelerated | |
| ChaCha20-Poly1305 | N/A | ~2 GB/s | Good without AES-NI | |
Performance varies by implementation and hardware. Numbers are approximate for modern x86-64 processors with AVX2.
Deprecated Algorithms
Do not use these algorithms for new implementations
These algorithms are broken, weak, or deprecated
If you find these in your systems, prioritize migration immediately.
| Algorithm | Status | Reason | Replace With |
|---|---|---|---|
| MD5 | Broken | Collision attacks trivial | SHA-384 or SHA-512 |
| SHA-1 | Broken | Collision attacks demonstrated | SHA-384 or SHA-512 |
| RIPEMD-160 | Deprecated | Limited security margin, rarely used | SHA-384 or SHA-512 |
| DES | Broken | 56-bit key brute-forceable | AES-256-GCM |
| 3DES / TDEA | Deprecated | Sweet32 attack, slow | AES-256-GCM |
| RC4 | Broken | Statistical biases exploitable | AES-256-GCM or ChaCha20 |
| Blowfish | Deprecated | 64-bit block size vulnerable | AES-256-GCM |
| RSA-1024 | Broken | Factorable with modern resources | ECDSA + ML-DSA (hybrid) |
| DSA | Deprecated | Nonce reuse catastrophic, quantum-vulnerable | ECDSA + ML-DSA (hybrid) |
| TLS 1.0 / 1.1 | Deprecated | Multiple vulnerabilities | TLS 1.3 |
| SSL 2.0 / 3.0 | Broken | POODLE, DROWN attacks | TLS 1.3 |
| CBC mode (without AEAD) | Avoid | Padding oracle attacks | AES-256-GCM or CCM mode |
| ECB mode | Broken | Patterns visible in ciphertext | AES-256-GCM, CCM, or CTR mode |