Overview
The emergence of quantum computing poses a significant threat to the cryptographic algorithms that protect our digital infrastructure today. While classical algorithms like RSA and ECC have served us well for decades, they will become vulnerable to quantum attacks using Shor's algorithm.
In August 2024, the U.S. National Institute of Standards and Technology (NIST) finalized three post-quantum cryptography (PQC) standards:
- FIPS 203 - ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism)
- FIPS 204 - ML-DSA (Module-Lattice-Based Digital Signature Algorithm)
- FIPS 205 - SLH-DSA (Stateless Hash-Based Digital Signature Algorithm)
Quantum Threat
All asymmetric cryptographic algorithms currently in widespread use (RSA, ECDSA, ECDH) are vulnerable to Shor's algorithm on a cryptographically relevant quantum computer (CRQC). Organizations should begin planning their migration now, as "harvest now, decrypt later" attacks are already underway.
Classical Algorithms
These algorithms form the foundation of current cryptographic infrastructure. While symmetric algorithms like AES remain quantum-resistant (with larger key sizes), asymmetric algorithms are vulnerable to quantum attack.
RSA (Asymmetric Encryption / Signatures)
RSA security is based on the difficulty of factoring large integers. Quantum computers using Shor's algorithm can efficiently factor these numbers, breaking RSA security entirely.
| Key Size | Security Strength | Quantum Status | NIST Recommendation |
|---|---|---|---|
| RSA-2048 | 112-bit | Vulnerable | Acceptable until 2030 |
| RSA-3072 | 128-bit | Vulnerable | Good beyond 2030 |
| RSA-4096 | ~140-bit | Vulnerable | Good beyond 2030 |
Elliptic Curve Cryptography (ECC)
ECC provides equivalent security to RSA with much smaller key sizes. However, like RSA, it is vulnerable to Shor's algorithm and will be broken by quantum computers.
| Curve | Key Size | Security Strength | RSA Equivalent | Quantum Status |
|---|---|---|---|---|
| P-256 (secp256r1) | 256 bits | 128-bit | RSA-3072 | Vulnerable |
| P-384 (secp384r1) | 384 bits | 192-bit | RSA-7680 | Vulnerable |
| P-521 (secp521r1) | 521 bits | 256-bit | RSA-15360 | Vulnerable |
AES (Symmetric Encryption)
AES remains secure against quantum attacks, though Grover's algorithm effectively halves the security strength. AES-256 provides 128-bit post-quantum security, which is sufficient for most applications.
| Algorithm | Key Size | Classical Security | Post-Quantum Security | Performance |
|---|---|---|---|---|
| AES-128 | 128 bits | 128-bit | 64-bit | ~2,600 MB/s (GCM, AES-NI) |
| AES-256 | 256 bits | 256-bit | 128-bit | ~2,250 MB/s (GCM, AES-NI) |
Key Insight
Symmetric algorithms like AES-256 remain quantum-resistant. The focus of PQC migration should be on replacing asymmetric algorithms (RSA, ECC) used for key exchange and digital signatures.
ML-KEM (FIPS 203)
Post-Quantum
ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism), formerly known as CRYSTALS-Kyber, is the NIST-standardized algorithm for post-quantum key encapsulation. It is designed to securely establish shared secrets between parties, replacing vulnerable algorithms like RSA-KEM and ECDH.
ML-KEM's security is based on the Module Learning with Errors (MLWE) problem, which is believed to be computationally hard even for quantum computers.
| Parameter Set | Security Level | Public Key | Secret Key | Ciphertext | Shared Secret |
|---|---|---|---|---|---|
| ML-KEM-512 | Level 1 (128-bit) | 800 bytes | 1,632 bytes | 768 bytes | 32 bytes |
| ML-KEM-768 | Level 3 (192-bit) | 1,184 bytes | 2,400 bytes | 1,088 bytes | 32 bytes |
| ML-KEM-1024 | Level 5 (256-bit) | 1,568 bytes | 3,168 bytes | 1,568 bytes | 32 bytes |
Performance Characteristics
ML-KEM offers exceptional performance compared to classical algorithms:
- 64× faster than ECDH (P-384) for shared secret derivation
- 3,200× faster than RSA for equivalent key exchange operations
- Key encapsulation completes in under 0.3ms on modern server hardware
CNSA 2.0 Requirement
The NSA's CNSA 2.0 suite mandates ML-KEM-1024 for all classification levels. Organizations targeting federal compliance should plan for this parameter set.
ML-DSA (FIPS 204)
Post-Quantum
ML-DSA (Module-Lattice-Based Digital Signature Algorithm), formerly known as CRYSTALS-Dilithium, is the NIST-standardized algorithm for post-quantum digital signatures. It provides a general-purpose replacement for RSA and ECDSA signatures.
The numbers in the parameter set names (44, 65, 87) refer to the dimensions of the internal matrix used during key generation (e.g., ML-DSA-65 uses a 6×5 matrix).
| Parameter Set | Security Level | Public Key | Secret Key | Signature |
|---|---|---|---|---|
| ML-DSA-44 | Level 2 (128-bit) | 1,312 bytes | 2,560 bytes | 2,420 bytes |
| ML-DSA-65 | Level 3 (192-bit) | 1,952 bytes | 4,032 bytes | 3,309 bytes |
| ML-DSA-87 | Level 5 (256-bit) | 2,592 bytes | 4,866 bytes | 4,627 bytes |
Size Considerations
ML-DSA signatures are significantly larger than classical alternatives. An ECDSA P-256 signature is only 64 bytes, while ML-DSA-44 produces 2,420-byte signatures. Plan for increased bandwidth and storage requirements in your migration.
SLH-DSA (FIPS 205)
Post-Quantum
SLH-DSA (Stateless Hash-Based Digital Signature Algorithm), based on SPHINCS+, is a hash-based signature scheme that provides an alternative to lattice-based signatures. Its security relies only on the well-understood properties of hash functions.
SLH-DSA offers 12 parameter sets with two variants:
- "s" variants - Optimized for smaller signatures (slower signing)
- "f" variants - Optimized for faster signing (larger signatures)
| Parameter Set | Security Level | Public Key | Secret Key | Signature |
|---|---|---|---|---|
| SLH-DSA-SHA2-128s | Level 1 | 32 bytes | 64 bytes | 7,856 bytes |
| SLH-DSA-SHA2-128f | Level 1 | 32 bytes | 64 bytes | 17,088 bytes |
| SLH-DSA-SHA2-192s | Level 3 | 48 bytes | 96 bytes | 16,224 bytes |
| SLH-DSA-SHA2-256s | Level 5 | 64 bytes | 128 bytes | 29,792 bytes |
| SLH-DSA-SHA2-256f | Level 5 | 64 bytes | 128 bytes | 49,856 bytes |
Best Use Case
SLH-DSA is ideal for code signing and firmware validation where large signature sizes and slower signing times are acceptable. The extremely small public keys (32-64 bytes) make it attractive for systems with limited storage for public keys.
Algorithm Comparison Summary
This table provides a quick comparison of classical versus post-quantum algorithms for different cryptographic functions:
| Function | Classical Algorithm | PQC Replacement | Key Size Change | Performance Impact |
|---|---|---|---|---|
| Key Exchange | ECDH (P-256) | ML-KEM-768 | 32 → 1,184 bytes | 64× faster |
| Key Exchange | RSA-2048 | ML-KEM-1024 | 256 → 1,568 bytes | 3,200× faster |
| Digital Signature | ECDSA (P-256) | ML-DSA-44 | 64 → 1,312 bytes (pubkey) | Comparable |
| Code Signing | RSA-2048 | SLH-DSA-SHA2-128s | 256 → 32 bytes (pubkey) | Slower signing |
| Symmetric Encryption | AES-128 | AES-256 | 128 → 256 bits | ~10-15% slower |
Use Case Recommendations
TLS / Web Traffic
Secure HTTPS connections between browsers and servers
ML-KEM-768 + ML-DSA-65
VPN / Network Security
Secure tunnels and network communications
ML-KEM-1024 + AES-256
Code Signing
Software and firmware authentication
SLH-DSA-SHA2-128s or LMS/XMSS
Email Security (S/MIME)
Encrypted and signed email communications
ML-KEM-768 + ML-DSA-65
PKI / Certificates
Certificate authority and identity management
ML-DSA-87 (root CA)
National Security Systems
Classified government communications
ML-KEM-1024 + ML-DSA-87 (CNSA 2.0)
CNSA 2.0 Migration Timeline
The NSA's Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) establishes mandatory timelines for transitioning to quantum-resistant cryptography in National Security Systems:
Software & Firmware Signing
CNSA 2.0 algorithms preferred. Web browsers, servers, and cloud services should support and prefer PQC.
Networking & Operating Systems
Traditional networking equipment (VPNs, routers) should prefer CNSA 2.0 by 2026. Operating systems by 2027. New acquisitions must support PQC from January 2027.
Exclusive Use Deadline
Software signing and networking equipment must use CNSA 2.0 exclusively. All equipment that cannot support PQC must be phased out.
Legacy Systems Deadline
Web services, operating systems, and niche/constrained devices must use CNSA 2.0 exclusively. Custom applications and legacy systems must be updated or replaced.
Full Quantum Resistance
All U.S. national security systems must be fully quantum-resistant. This aligns with the White House NSM-10 directive for government-wide quantum security readiness.
Start Now
These timelines may seem distant, but large-scale cryptographic migrations typically take 5-10 years. Organizations should begin their cryptographic inventory and planning immediately.
Sources & References
-
1
NIST FIPS 203 - Module-Lattice-Based Key-Encapsulation Mechanism Standardcsrc.nist.gov/pubs/fips/203/final
-
2
NIST FIPS 204 - Module-Lattice-Based Digital Signature Standardcsrc.nist.gov/pubs/fips/204/final
-
3
NIST FIPS 205 - Stateless Hash-Based Digital Signature Standardcsrc.nist.gov/pubs/fips/205/final
-
4
CNSA 2.0 Compliance Requirements, Algorithms & Timelinessafelogic.com/compliance/cnsa-2
-
5
NIST SP 800-131A Rev. 2 - Transitioning the Use of Cryptographic Algorithmscsrc.nist.gov/pubs/sp/800/131/a/r2/final
-
6
Open Quantum Safe - ML-KEM Documentationopenquantumsafe.org/liboqs/algorithms/kem/ml-kem.html
-
7
Open Quantum Safe - ML-DSA Documentationopenquantumsafe.org/liboqs/algorithms/sig/ml-dsa.html
-
8
Commercial National Security Algorithm Suite - Wikipediaen.wikipedia.org/wiki/Commercial_National_Security_Algorithm_Suite