CLOUDFLARE 2026-07-09

Why we cannot wait for better post-quantum signature algorithms¶

Summary¶

Cloudflare surveys the full landscape of post-quantum signature algorithms — both the standardised general-purpose ML-DSA and the nine candidates advancing to NIST's third round of the "signatures on-ramp" competition. The central argument: none of the newer, better-performing algorithms (FN-DSA, SQIsign, MAYO, SNOVA, HAWK, FAEST, MQOM, SDitH) will be standardised and widely deployed before 2030–2035, yet the post-quantum migration deadline is 2029–2031. ML-DSA, despite its larger signature/key sizes, is the only option available today and must be deployed now. The post makes the case that the search for better algorithms remains crucial for second-generation deployments, anonymous credentials, and systems where ML-DSA's sizes are genuinely problematic.

Key takeaways¶

No all-star replacement exists. Ed25519 dominates on every metric simultaneously; post-quantum signatures fragment into "specialists" (excellent on one axis, problematic on others) and "generalists" (balanced but larger than classical). ML-DSA-44 is the best generalist available today.
ML-DSA-44 is 40–75× larger on the wire than Ed25519 (1,312 B pubkey + 2,420 B signature vs 32 B + 64 B), but has fast signing/verification and balanced trade-offs. It provides ~160-bit security, more than the 128-bit minimum.
FN-DSA (Falcon) has better sizes but critical implementation hazards. Smaller signatures (666 B) and keys (897 B), but signing requires floating-point arithmetic that is hard to make side-channel-safe. No consistent test vectors across implementations. Deterministic signing from two slightly different implementations leaks partial private key material. Widely available not before ~2033.
SQIsign has near-classical sizes (148 B sig, 65 B pubkey) but is too slow for online use. Signing is hard to implement securely and very slow (~300× ML-DSA baseline). Best suited for offline signing (CA certificates, DNSSEC). Only brute-force attacks are known (good security signal), but the mathematical attack surface is large. Wide availability unlikely before 2035.
UOV has tiny signatures (96 B) but enormous public keys (66 kB). Useful only where keys are pre-distributed (root certificates in browsers). Security track record is reasonable but the 2025 "wedges" attack removed ~15 bits. Parameters can be adjusted but key size grows cubically with security level (446 kB at 256-bit security).
MAYO is the most promising structured multivariate for general use. 454 B signatures with 1,420 B pubkey; stable design with no attacks found on its specific "whipping" structure. Offers granular security-level tuning (unlike FN-DSA/HAWK which lack a middle level). NIST expects an extra round — standardisation ~2031, product availability not before ~2034.
Proof-of-knowledge schemes (FAEST, MQOM, SDitH) enable anonymous credentials. The general-purpose zero-knowledge proof underlying them can build blind signatures and anonymous credentials — capabilities that ML-DSA cannot provide. FAEST's security is as conservative as SLH-DSA (relies only on hash function hardness). First standard possible ~2030.
Stateful hash-based signatures (LMS) are niche. Small signatures (1,112 B) with fast verification, but require stateful signing (foot-cannon: reusing a one-time key breaks security) and have hard signature-count limits (~1M). Useful only in constrained scenarios with careful state management.
The deployment timeline forces action now. ML-DSA went from NIST selection (2022) to final standard (2024) to first protocol integrations (2025–2026) to expected WebPKI availability (early 2027). Even FN-DSA, the closest competitor, won't be widely available before 2033. For any system with a post-quantum deadline before 2035, ML-DSA deployment cannot wait.
Downgrade attacks require a transition period beyond deployment day. Supporting both PQ and classical signatures creates a downgrade attack surface. The safest mitigation is disabling classical crypto entirely, which takes years in distributed systems like the WebPKI. Starting early is critical.

Operational numbers¶

Algorithm	Public key (B)	Signature (B)	Signing time (×ML-DSA baseline)	Verification time (×ML-DSA baseline)
Ed25519	32	64	0.15	1.3
RSA-2048	272	256	80	0.4
ML-DSA-44	1,312	2,420	1 (baseline)	1 (baseline)
FN-DSA-512	897	666	3 ⚠️	0.7
HAWK-512	1,024	555	0.25	1.2
SQIsign-I	65	148	300 ⚠️	50
MAYO-one	1,420	454	2.1	0.4
UOV (Is-pkc)	66,576	96	0.3	2.4
FAEST (EM-128f)	32	5,060	4.2	9
SLH-DSA-128s	32	7,856	14,000	40
LMS (M24_H20_W8)	48	1,112	2.9 ⚠️	8.4

Estimated availability timeline¶

Algorithm family	NIST standard (est.)	Wide product availability (est.)
ML-DSA	August 2024 (done)	2026–2027 (in progress)
FN-DSA (Falcon)	TBD (draft pending)	Not before 2033
Multivariate (MAYO/SNOVA)	~2031	Not before 2034
SQIsign (isogeny)	~2032+ (likely 4th round)	Not before 2035
Proof-of-knowledge (FAEST/MQOM/SDitH)	~2030	~2031–2032

Architectural trade-offs and design decisions¶

Specialist vs generalist selection: No single PQ algorithm dominates all metrics. System designers must profile their specific constraints (online vs offline signing, pre-distributed vs on-the-wire keys, signature count limits, state management capability) and select accordingly.
Security margin hedging: Lattice cryptanalysis continues to improve slowly. ML-DSA-44 targets 160-bit security (above the 128-bit minimum) to hedge. FN-DSA-512 targets only 128 bits with no middle level — any future attack improvement forces a jump to the full 256-bit FN-DSA-1024.
Compensating controls during migration gap: Systems where ML-DSA's sizes are genuinely problematic may need to accept a performance cost or deploy compensating controls (restricted access, tunneling, monitoring) until smaller PQ signatures arrive in the 2030s.
Protocol re-engineering > algorithm waiting: The WebPKI is being re-engineered (via Merkle Tree Certificates) to perform better with PQ signatures than the current classical system. Systemic redesign is more productive than waiting for smaller algorithms.

Caveats¶

NIST round-3 candidates can still make significant changes; performance numbers may shift.
HAWK's security is under active threat — a June 2026 paper suggests the lattice isomorphism problem (LIP) underlying HAWK may be attackable, though an error was found in the paper.
SNOVA's design has been repeatedly broken and restructured; its stability is uncertain.
Timeline estimates assume no acceleration in quantum hardware development (which could shorten deadlines further).