NIST finalised the post-quantum cryptography standards in August 2024 —
ML-KEM (FIPS 203), ML-DSA (FIPS 204), SLH-DSA (FIPS 205). Regulators are
now asking for migration roadmaps. Most teams don't know where to start.
The problem isn't finding the new algorithms. It's knowing what they'll
cost you before you commit.
The number that changes everything
ML-DSA signatures are 33× larger than ECDSA:
| Algorithm | Signature size |
|---|---|
| ECDSA-P256 | 72 bytes |
| ML-DSA-44 | 2,420 bytes |
| ML-DSA-65 | 3,293 bytes |
| SLH-DSA-256s | 29,792 bytes |
That's not just a performance concern. It breaks things structurally.
What actually breaks
-DNSSEC: The UDP limit is 1,232 bytes. An ML-DSA-44 signature alone is
2,420 bytes. Your signed DNS responses will fragment — or worse, get dropped
by middleboxes that don't handle fragmented UDP.
-JWT tokens: A 2,420-byte signature plus header plus claims blows past
the 8KB HTTP header limit most API gateways enforce. Your auth tokens stop
working at the proxy layer, not at your app.
-TLS handshakes: The CertificateVerify message now spans 3 MTU packets.
Some legacy TLS stacks can't handle multi-packet handshake messages.
Embedded devices: ML-KEM-768 key generation needs ~2MB of RAM. Most
microcontrollers don't have it. IoT devices that do TLS today may simply
not be able to do PQC.
HSMs: Most hardware security modules don't support ML-KEM or ML-DSA yet.
If your private keys live in an HSM, you're waiting on vendor firmware updates.
How to find your specific blockers
I built pqc-sandbox to answer
this before you touch production.
bash
pip install pqc-sandbox
pqc-sandbox demo
Top comments (0)