Home / Discover / Algorithm Performance

PQC Algorithm Performance Reference

Key sizes, signature sizes, and performance characteristics of NIST-standardized post-quantum algorithms compared to classical cryptography.

At a Glance

PQC algorithms are computationally fast but produce larger keys and signatures than classical algorithms. The trade-off is straightforward: slightly more bandwidth in exchange for quantum resistance.

⚡
Speed is not the bottleneck

ML-DSA-65 signs in ~3-5ms and verifies in ~2-3ms. For most applications, PQC latency is negligible compared to network I/O.

📦
Size is the main impact

ML-DSA-65 signatures are ~3.3 KB (vs 64 bytes for ECDSA). Plan for larger JWTs, certificates, and TLS handshakes.

Digital Signatures — ML-DSA (FIPS 204)

Replaces RSA and ECDSA for signing operations. Used in JWT tokens, code signing, certificates, and transaction authentication.

Algorithm NIST Level Public Key Signature Private Key Sign Verify Use Case
ML-DSA-44 2 1,312 bytes 2,420 bytes 2,560 bytes ~2 ms ~1 ms IoT, constrained devices
ML-DSA-65 Recommended 3 1,952 bytes 3,309 bytes 4,032 bytes ~4 ms ~2 ms General purpose, JWT, API auth
ML-DSA-87 5 2,592 bytes 4,627 bytes 4,896 bytes ~6 ms ~3 ms Firmware signing, highest security

Compared to Classical Algorithms

Algorithm Type Public Key Signature Sign Verify Quantum Safe?
ECDSA P-256 Classical 64 bytes 64 bytes ~0.1 ms ~0.3 ms No
RSA-2048 Classical 256 bytes 256 bytes ~1 ms ~0.05 ms No
ML-DSA-65 PQC 1,952 bytes 3,309 bytes ~4 ms ~2 ms Yes
Impact: ML-DSA-65 is ~40x slower to sign than ECDSA, but still under 5ms. For JWT-based APIs handling 100-500 req/sec, this is not a bottleneck. Key and signature sizes increase ~30-50x, which affects JWT header size and certificate chain size.

Key Encapsulation — ML-KEM (FIPS 203)

Replaces ECDH and Diffie-Hellman for key exchange. Used in TLS handshakes, VPN tunnels, and encrypted messaging.

Algorithm NIST Level Public Key Ciphertext Shared Secret Keygen Encaps Use Case
ML-KEM-512 1 800 bytes 768 bytes 32 bytes <1 ms <1 ms Lightweight key exchange
ML-KEM-768 Recommended 3 1,184 bytes 1,088 bytes 32 bytes <1 ms <1 ms TLS, general purpose
ML-KEM-1024 5 1,568 bytes 1,568 bytes 32 bytes <1 ms <1 ms Highest security

TLS Handshake Impact (Hybrid X25519MLKEM768)

Key Exchange Client Hello Extra Server Hello Extra Total Handshake Overhead Latency Impact
X25519 (classical) 0 bytes 0 bytes Baseline Baseline
X25519MLKEM768 (hybrid) ~1.2 KB ~1.1 KB ~2.3 KB extra <1 ms
Impact: Hybrid PQC TLS adds ~2.3 KB to the handshake and negligible latency. Once the session is established, data transfer is identical (AES-256-GCM). This is the lowest-effort, highest-impact PQC migration step.

Hash-Based Signatures — SLH-DSA (FIPS 205)

Conservative, hash-based signatures for long-lived artifacts. Used for root CA certificates, firmware signing, and archival documents where security must last decades.

Algorithm Public Key Signature Sign Verify Trade-off
SLH-DSA-SHA2-128s 32 bytes 7,856 bytes ~200 ms ~10 ms Small key, slow sign, small signature
SLH-DSA-SHA2-128f 32 bytes 17,088 bytes ~10 ms ~1 ms Small key, fast sign, large signature
SLH-DSA-SHA2-256s 64 bytes 29,792 bytes ~1,000 ms ~15 ms Strongest, very slow sign
When to use SLH-DSA: Only for signing operations that happen infrequently but must remain secure for 20+ years (root CA certs, firmware). For high-volume signing (JWT, API auth), use ML-DSA instead.

Choosing the Right Algorithm

Use Case Recommended Algorithm FIPS Standard Why
JWT / API authentication ML-DSA-65 FIPS 204 Good balance of security (Level 3) and speed (~4ms sign)
TLS key exchange X25519MLKEM768 FIPS 203 Hybrid: backward compatible, <1ms overhead, browser-supported
Code / container signing ML-DSA-65 FIPS 204 General-purpose, CNSA 2.0 compliant
Firmware signing ML-DSA-87 FIPS 204 Highest security level (Level 5), NSA recommended for firmware
IoT device auth ML-DSA-44 FIPS 204 Smallest keys/signatures, suitable for constrained devices
Root CA certificates SLH-DSA-SHA2-128s FIPS 205 Conservative hash-based security for 20+ year lifetime
Email encryption ML-KEM-768 + AES-256-GCM FIPS 203 KEM for key exchange, symmetric for message encryption
VPN / inter-service encryption ML-KEM-1024 FIPS 203 Highest security for long-lived encrypted channels

Measure on Your Hardware

After installing the Qudo provider, run these commands to measure PQC performance on your own infrastructure.

# Benchmark ML-DSA-65 signing speed
openssl speed -seconds 3 mldsa65

# Benchmark ML-KEM-768 key encapsulation
openssl speed -seconds 3 mlkem768

# Compare all ML-DSA variants
openssl speed -seconds 3 mldsa44 mldsa65 mldsa87

# Time a single key generation
time openssl genpkey -algorithm ML-DSA-65 -out /dev/null

# Time a single sign + verify cycle
echo "test" > /tmp/data.txt
openssl genpkey -algorithm ML-DSA-65 -out /tmp/key.pem
time openssl pkeyutl -sign -rawin -inkey /tmp/key.pem -in /tmp/data.txt -out /tmp/sig.bin
openssl pkey -in /tmp/key.pem -pubout -out /tmp/pub.pem
time openssl pkeyutl -verify -rawin -pubin -inkey /tmp/pub.pem -in /tmp/data.txt -sigfile /tmp/sig.bin

Performance varies by hardware. The numbers on this page are measured on Apple M-series silicon with the Qudo FIPS provider. x86_64 Linux servers typically show similar or faster results.

Qudo PQC Developer Portal · Algorithm Performance Reference