PQC Algorithm Comparison
At a Glance -- NIST Standardised Algorithms
| Property | ML-KEM-768 (FIPS 203) | ML-DSA-65 (FIPS 204) | SLH-DSA-SHA2-128s (FIPS 205) | FN-DSA-512 (Draft FIPS 206) |
|---|---|---|---|---|
| Purpose | Key Encapsulation | Digital Signature | Digital Signature | Digital Signature |
| Mathematical Basis | Module Lattices (MLWE) | Module Lattices (MLWE) | Hash functions (Merkle trees) | NTRU Lattices |
| NIST Security Level | 3 (AES-192 equiv.) | 3 (AES-192 equiv.) | 1 (AES-128 equiv.) | 1 (AES-128 equiv.) |
| Public Key Size | 1,184 bytes | 1,952 bytes | 32 bytes | 897 bytes |
| Secret Key Size | 2,400 bytes | 4,032 bytes | 64 bytes | 1,281 bytes |
| Ciphertext / Signature Size | 1,088 bytes (ciphertext) | 3,293 bytes (signature) | 7,856 bytes (signature) | 666 bytes (signature) |
| Key Generation | Fast (microseconds) | Fast (microseconds) | Slow (milliseconds) | Slow (seconds for keygen) |
| Encapsulation / Signing | Fast | Fast | Fast | Fast |
| Decapsulation / Verification | Fast | Fast | Fast | Fast |
| Standardisation Status | Final (Aug 2024) | Final (Aug 2024) | Final (Aug 2024) | Draft (expected 2025) |
Parameter Sets -- ML-KEM (Key Encapsulation)
| Parameter Set | Security Level | Public Key | Secret Key | Ciphertext | Shared Secret |
|---|---|---|---|---|---|
| ML-KEM-512 | 1 (AES-128) | 800 bytes | 1,632 bytes | 768 bytes | 32 bytes |
| ML-KEM-768 | 3 (AES-192) | 1,184 bytes | 2,400 bytes | 1,088 bytes | 32 bytes |
| ML-KEM-1024 | 5 (AES-256) | 1,568 bytes | 3,168 bytes | 1,568 bytes | 32 bytes |
Tip: ML-KEM-768 is the recommended default for most applications. Use ML-KEM-1024 only when defending against an adversary with nation-state quantum computing capability and extreme long-term confidentiality requirements.
Parameter Sets -- ML-DSA (Digital Signature)
| Parameter Set | Security Level | Public Key | Secret Key | Signature |
|---|---|---|---|---|
| ML-DSA-44 | 2 (SHA-256 equiv.) | 1,312 bytes | 2,560 bytes | 2,420 bytes |
| ML-DSA-65 | 3 (AES-192) | 1,952 bytes | 4,032 bytes | 3,293 bytes |
| ML-DSA-87 | 5 (AES-256) | 2,592 bytes | 4,896 bytes | 4,595 bytes |
Parameter Sets -- SLH-DSA (Hash-Based Signature)
SLH-DSA comes in 12 parameter sets combining hash function (SHA-256 / SHAKE256), security level (128/192/256), and tradeoff (f = fast signing / s = small signature):
| Parameter Set | Security Level | Public Key | Signature | Signing Speed |
|---|---|---|---|---|
| SLH-DSA-SHA2-128f | 1 | 32 bytes | 17,088 bytes | Fast |
| SLH-DSA-SHA2-128s | 1 | 32 bytes | 7,856 bytes | Slow |
| SLH-DSA-SHA2-192f | 3 | 48 bytes | 35,664 bytes | Fast |
| SLH-DSA-SHA2-192s | 3 | 48 bytes | 16,224 bytes | Slow |
| SLH-DSA-SHA2-256f | 5 | 64 bytes | 49,856 bytes | Fast |
| SLH-DSA-SHA2-256s | 5 | 64 bytes | 29,792 bytes | Slow |
Warning: SLH-DSA signature sizes are significantly larger than ML-DSA. Use SLH-DSA when you need conservative security assumptions (hash functions only, no lattice assumptions) or as a fallback if lattice-based schemes are ever broken.
Comparison with Classical Algorithms
| Algorithm | Type | Key Size | Signature/Ciphertext | Quantum Safe |
|---|---|---|---|---|
| RSA-2048 | Signature / Encryption | 256 bytes (pub) | 256 bytes | No |
| ECDSA P-256 | Signature | 64 bytes (pub) | 64 bytes | No |
| X25519 | Key Exchange | 32 bytes (pub) | 32 bytes | No |
| AES-256 | Symmetric | 32 bytes | N/A | Yes (Grover halves security) |
| SHA-256 | Hash | N/A | 32 bytes | Yes (Grover halves security) |
| ML-KEM-768 | Key Encapsulation | 1,184 bytes (pub) | 1,088 bytes | Yes |
| ML-DSA-65 | Signature | 1,952 bytes (pub) | 3,293 bytes | Yes |
| SLH-DSA-128s | Signature | 32 bytes (pub) | 7,856 bytes | Yes |
When to Use Each Algorithm
ML-KEM (FIPS 203)
- Use for: TLS key exchange, VPN tunnel establishment, key wrapping, hybrid encryption
- Strengths: Fast, well-understood lattice security, compact enough for most protocols
- Considerations: Larger keys than ECDH; requires protocol changes for the KEM paradigm (encapsulate/decapsulate vs. DH)
ML-DSA (FIPS 204)
- Use for: Code signing, document signing, certificate signing, authentication tokens
- Strengths: Fast signing and verification, reasonable signature sizes, strong security margin
- Considerations: Signature sizes ~50x larger than ECDSA; may impact bandwidth-constrained protocols
SLH-DSA (FIPS 205)
- Use for: Root-of-trust signing, firmware signing, long-lived certificates, conservative fallback
- Strengths: Security relies only on hash function properties (extremely well-understood), tiny public keys
- Considerations: Very large signatures, slow key generation; not suitable for high-throughput signing
FN-DSA (Draft FIPS 206)
- Use for: Bandwidth-constrained signatures, embedded systems, protocols needing smallest PQ signatures
- Strengths: Smallest signatures of any PQ signature scheme; fast verification
- Considerations: Complex implementation (requires careful floating-point handling or isochronous Gaussian sampling); key generation is slow
Hybrid Mode Recommendations
During the transition period, NIST and many standards bodies recommend running PQC algorithms alongside classical algorithms (hybrid mode):
| Use Case | Recommended Hybrid | Standard Reference |
|---|---|---|
| TLS 1.3 Key Exchange | X25519 + ML-KEM-768 | RFC 9758 (X25519MLKEM768) |
| Code Signing | ECDSA P-256 + ML-DSA-44 | IETF draft-ietf-lamps-pq-composite |
| S/MIME Email | RSA-2048 + ML-KEM-768 | IETF draft-ietf-lamps-kyber-certificates |
| Certificate Authority | ECDSA P-384 + ML-DSA-65 | NIST SP 800-131B (pending) |
Note: Hybrid mode ensures that if either the classical or post-quantum algorithm is broken, the other still provides protection. This is the recommended approach during the transition period.
Performance Benchmarks (Approximate)
Based on reference implementations on modern x86-64 hardware:
| Operation | ML-KEM-768 | ML-DSA-65 | SLH-DSA-128s | RSA-2048 | ECDSA P-256 |
|---|---|---|---|---|---|
| Key Generation | 30 us | 60 us | 3 ms | 150 ms | 40 us |
| Encapsulate / Sign | 40 us | 120 us | 60 ms | 4 ms | 50 us |
| Decapsulate / Verify | 40 us | 120 us | 3 ms | 60 us | 80 us |
Tip: ML-KEM and ML-DSA are in the same performance ballpark as classical algorithms for most operations. The transition cost is primarily in bandwidth (larger keys and signatures), not computation time.