Why we cannot wait for better post-quantum signature algorithms
Key Points
- Adopt ML-DSA now for signatures; don’t wait.
- Specialist PQ schemes trade size, speed, and implementability.
- Design for agility, side‑channel safety, and capacity impacts.
Summary
Quantum computers will eventually break RSA and ECC; encrypting traffic with ML-KEM (standardized 2024) is already practical and widely deployed, but signatures also must migrate to post-quantum schemes to prevent harvest-now–decrypt-later and to protect authentication. ML-DSA is the balanced, standardized post-quantum signature available today and is the pragmatic choice for an initial migration despite larger wire sizes and implementation trade-offs. Better “specialist” schemes (small signatures, tiny keys, faster verification, etc.) are progressing through NIST’s process, but they are not mature enough to postpone adoption. Expect a multi-year transition and design systems for agility and side-channel safe implementations; the industry target for full post-quantum posture (Cloudflare example) is 2029.
Key Points
- Practical immediate step: adopt ML-DSA for signatures now and ML-KEM for encryption — you can’t wait for future algorithms.
- Expect larger public keys and signatures; account for increased certificate and TLS handshake sizes in bandwidth, storage, and latency planning.
- Design for algorithm agility: support hybrid handshakes, multiple signature algorithms, and easy key rollovers so you can swap in improved schemes later.
- Side-channel safety is critical: some candidates (e.g., SQIsign) are hard to implement timing‑safe; prefer implementations that are explicitly side‑channel resistant or run signing in controlled/offline environments.
- Be cautious with stateful schemes (e.g., some LMS variants): only use them if you can reliably manage signing state; otherwise choose stateless schemes.
- Consider use-case fit: specialists (small signatures, large keys, or fast verification) may be ideal for offline CA/DNSSEC or pre-distributed roots; generalists like ML-DSA suit online TLS deployments.
- Monitor NIST’s on‑ramp progress (round 3 candidates and FN-DSA drafts) and bench them in your environment, but don’t postpone migration waiting for them.
- Test interoperability and performance now (signature sizes, signing/verification latency, memory and cache behavior) and update cert distribution and cross-sign strategies accordingly.
Recommendations for engineers
- Roll out ML-DSA for new certificate issuance and TLS stacks where pragmatic; use hybrid modes during transition.
- Implement or obtain side‑channel mitigations for signing operations and audit cryptographic codepaths.
- Update capacity planning for larger cert/key material and consider CDN/edge impacts for handshake and cache sizes.
- Keep CI performance tests against the signatures zoo benchmarks and follow NIST publications to evaluate new candidates as they stabilize.