skip to content
QUANTUM NEXUM

← forge

Compare

Status: dev — performance figures are approximate per-core AVX2 order-of-magnitude values; measure in your own environment before drawing conclusions.

Algorithm Comparison

Compare key sizes, performance, and security levels across classical and post-quantum algorithms.

Showing of 23 algorithms
Algorithm Type Security Public Key Secret Key CT/Sig Size Ops/sec Standard
RSA-2048 (KEX) Legacy KEX Vulnerable 256 B ~2,400 B 256 B ~2K Classical
ECDH P-256 Legacy KEX Vulnerable 65 B 32 B 64 B ~20K Classical
X25519 Legacy KEX Vulnerable 32 B 32 B 32 B ~50K Classical
RSA-2048 (Sig) Legacy SIG Vulnerable 256 B ~2,400 B 256 B ~2K sign Classical
ECDSA P-256 Legacy SIG Vulnerable 65 B 32 B 64 B ~30K sign Classical
Ed25519 Legacy SIG Vulnerable 32 B 64 B 64 B ~60K sign Classical
ML-KEM-512 KEM Level 1 800 B 1,632 B 768 B ~50K FIPS 203
ML-KEM-1024 KEM Level 5 1,568 B 3,168 B 1,568 B ~25K FIPS 203
ML-DSA-44 SIG Level 2 1,312 B 2,560 B 2,420 B ~10K sign / ~30K verify FIPS 204
ML-DSA-87 SIG Level 5 2,592 B 4,896 B 4,627 B ~6K sign / ~15K verify FIPS 204
SLH-DSA-SHA2-128f SIG Level 1 32 B 64 B 17,088 B ~100 FIPS 205
SLH-DSA-SHAKE-128f SIG Level 1 32 B 64 B 17,088 B ~100 FIPS 205
SLH-DSA-SHA2-192f SIG Level 3 48 B 96 B 35,664 B ~50 FIPS 205
SLH-DSA-SHA2-256f SIG Level 5 64 B 128 B 49,856 B ~30 FIPS 205
SLH-DSA-SHA2-128s SIG Level 1 32 B 64 B 7,856 B ~10 FIPS 205
SLH-DSA-SHA2-192s SIG Level 3 48 B 96 B 16,224 B ~5 FIPS 205
SLH-DSA-SHA2-256s SIG Level 5 64 B 128 B 29,792 B ~3 FIPS 205
HQC-128 KEM Level 1 2,249 B 2,305 B 4,497 B ~8K Round 4 (pending FIPS)
HQC-192 KEM Level 3 4,522 B 4,562 B 9,042 B ~5K Round 4 (pending FIPS)
BIKE-L1 eliminated 2025-03 KEM Level 1 1,541 B 5,223 B 1,573 B ~5K Not selected
BIKE-L3 eliminated 2025-03 KEM Level 3 3,083 B 10,105 B 3,115 B ~3K Not selected
Key:
  • CT = Ciphertext size (KEMs); Sig = Signature size
  • Ops/sec = approximate signing or encapsulation operations per second (single core, AVX2, order of magnitude)
  • ML-DSA Ops/sec: verification is faster than signing — both figures shown where space permits
  • HQC secret key = expanded key per round-4 submission (NIST reports 40-byte seed); HQC-128 sk = 2,305 B
  • Classical algorithms are vulnerable to quantum computers — migrate to PQ algorithms

Visual Size Comparison

See how classical and post-quantum algorithm sizes compare.

Public Key Size Comparison (bytes) — Classical vs Post-Quantum
Classical (Quantum Vulnerable)
X25519
32 B
Ed25519
32 B
ECDH P-256
65 B
RSA-2048
256 B
Post-Quantum KEMs
ML-KEM-512
800 B
ML-KEM-768
1,184 B
ML-KEM-1024
1,568 B
Post-Quantum Signatures
SLH-DSA-128
32 B
ML-DSA-44
1,312 B
ML-DSA-65
1,952 B
ML-DSA-87
2,592 B

Algorithm Selection Guide

🔑

Key Exchange / TLS

Recommended: ML-KEM-768 (hybrid with X25519)

Best balance of security and performance for TLS 1.3. ML-KEM hybrid is supported in Chrome 131+ and Firefox 132+ (standard-track; earlier builds shipped a pre-standard draft).

📜

Code Signing / Documents

Recommended: ML-DSA-65

Fast verification, reasonable signature size. Good for certificates, JWTs, software signing.

🏛

Government / FIPS

Recommended: ML-KEM-1024 + ML-DSA-87

Specified in CNSA 2.0. Required for software/browsers by 2025, networking by 2030, exclusive use by 2033; NSM-10 broader 2035 goal.

🛡

Conservative / Root CAs

Recommended: SLH-DSA (any variant)

Hash-based security assumptions. Use -s variants for smaller signatures; -f variants for faster signing.

📱

IoT / Embedded

Recommended: ML-KEM-512 + ML-DSA-44

Smallest sizes while still quantum-resistant. Consider bandwidth vs. security tradeoffs.

🔄

Transition Period

Recommended: Hybrid schemes (classical + PQ)

X25519+ML-KEM-768 for KEMs, ECDSA+ML-DSA for signatures. Protects against both classical and quantum attacks during the migration window.

Tips & Best Practices

Do

  • Use hybrid schemes during transition
  • Plan for larger key and signature sizes
  • Test performance in your environment
  • Use ML-KEM-768/ML-DSA-65 as defaults
  • Enable PQ in TLS 1.3 today (browsers support it)

Don’t

  • Use PQ algorithms without hybrid (yet)
  • Ignore bandwidth constraints
  • Assume all libraries are production-ready
  • Wait until quantum computers arrive
  • Deploy Round 4 candidates in production

Quick Start Examples

# Generate ML-KEM-768 keypair (recommended KEM, requires OpenSSL 3.5+) openssl genpkey -algorithm ML-KEM-768 -out mlkem768.key openssl pkey -in mlkem768.key -pubout -out mlkem768.pub # Generate ML-DSA-65 keypair (recommended signature) openssl genpkey -algorithm ML-DSA-65 -out mldsa65.key openssl pkey -in mldsa65.key -pubout -out mldsa65.pub # Test PQ-hybrid TLS locally (loopback example) # Terminal 1: start a test server openssl req -x509 -newkey ML-DSA-65 -keyout /tmp/srv.key \ -out /tmp/srv.crt -days 1 -nodes -subj "/CN=localhost" openssl s_server -key /tmp/srv.key -cert /tmp/srv.crt \ -accept 4433 -www -groups X25519MLKEM768 # Terminal 2: connect with PQ-hybrid key share openssl s_client -connect localhost:4433 \ -groups X25519MLKEM768 -tlsextdebug </dev/null 2>&1 \ | grep "key share" # View key information openssl pkey -in mlkem768.key -text -noout | head -20