A look at the latest post-quantum signature standardization candidates

Why NIST is running another signature competition

On October 24, 2024, NIST advanced fourteen post-quantum signature schemes to the second round of its “signatures on ramp” program. The agency has already standardized four post-quantum signature algorithms — ML-DSA, SLH-DSA, XMSS, and LMS — and is drafting a standard for a fifth, Falcon. That raises an obvious question: why keep adding more?

Part of the answer is that the existing standards cover only two families of approaches: lattice-based and hash-based signatures. The on-ramp candidates explore other hardness assumptions — code-based, isogeny-based, and multivariate — plus a range of design trade-offs around key size, signature size, and verification speed. Not every deployment has the same constraints, and NIST wants a broader menu before the quantum threat fully materializes.

For TLS in particular, the practical challenge is bytes on the wire. Our 2021 measurements showed how certificate sizes balloon with post-quantum signatures, and that pressure has only grown. Today, on more than half of QUIC connections we observe, almost half of the data sent is certificates alone.

The migration timeline differs for the two halves of TLS cryptography. Key agreement needs post-quantum protection now to defeat harvest-now-decrypt-later attacks; roughly 18% of human requests to Cloudflare-proxied websites already use post-quantum key agreement. Signature migration is less urgent — there is no stored-ciphertext risk for signatures — but it is the harder engineering problem, and it must be complete before a large quantum computer exists.

Where signatures appear in a TLS handshake

A TLS connection authenticates the server through several distinct signatures, each with its own constraints. The handshake begins with the server signing the protocol transcript up to that point. That signature is generated online, on every new connection, so its cost is a direct latency factor.

Alongside the transcript signature, the server sends its leaf certificate, signed by an intermediate CA, which in turn is signed by a root CA (or another intermediate). The leaf must also carry at least two signed certificate timestamps from certificate transparency logs — services like crt.sh and Merkle Map rely on those to prove public logging. Servers may additionally staple an OCSP response showing the certificate has not been revoked.

The result: a minimum of five signatures and two public keys travel over the wire to establish a fresh TLS session, before counting the OCSP staple. All of those except the transcript signature are created ahead of time — they are offline signatures. For those, verification speed dominates because signing happens once but verification happens on every connection. For the online handshake signature, what matters is minimizing the combined signing-plus-verification time.

Key sizes matter only for the leaf and intermediate certificates, whose public keys are transmitted during the handshake. The CA-chain signatures have no such constraint: a scheme with a larger public key is acceptable if it buys a smaller signature. Handshake signatures, by contrast, weigh both the public key and the signature size in the connection setup cost.

How the On-Ramp Candidates Compare

The table below sits the newly progressing candidates against the algorithms NIST already standardized (or is about to). CPU figures come from the signatures zoo and should be treated as rough guidance only — real-world performance varies with platform and implementation, and the on-ramp schemes are still evolving. Some will speed up and shrink as implementations mature; others may get slower or larger as attacks surface. Falcon signing is flagged with a ⚠️ because fast, side-channel-secure signing requires floating-point arithmetic that is hard to get right. LMS signing also carries a ⚠️ because it needs state management and the listed signing time assumes a 32MB cache.

None of these algorithms beat classical elliptic curve signatures across the board. Some are competitive in one dimension but pay for it elsewhere.

The Standardized Options Already Have Baggage

ML-DSA (FIPS 204, formerly Dilithium) is the most practical post-quantum signature scheme standardized today. It is light on the CPU and reasonably simple to implement, but the signatures and public keys are large: 2.4kB and 1.3kB respectively at the AES-128 security level. Adding ML-DSA to a TLS handshake costs 14.7kB on the wire — two 1312-byte public keys plus five 2420-byte signatures.

SLH-DSA (FIPS 205, formerly SPHINCS⁺) is strictly worse in size (adding 39kB) and computationally heavier for both signing and verification. Its virtue is that it relies only on hashes, giving it security assumptions that are far better understood than lattice-based schemes. Even its lowest security level is generally trusted more than the higher levels of many other candidates.

Falcon (soon to be FN-DSA) looks much better than both on paper. The catch is signing: fast signing requires fast floating-point arithmetic, which is notoriously difficult to make timing side-channel secure. Constant-time signing with emulated floating-point is about twenty times slower, making Falcon poorly suited to online signatures. Verification is simple and needs no floating-point arithmetic. Leaning into that strength by pairing ML-DSA for handshake signatures with Falcon for everything else adds only 7.3kB. Falcon also lacks a middle security level — if Falcon-512 is found weaker than expected, the next step is Falcon-1024, which doubles public key and signature sizes to roughly 11kB of added handshake data.

The stateful hash-based schemes XMSS^(MT) and LMS/HSS were the first post-quantum signatures standardized. They inherit the same strong hash-based security as SLH-DSA, but with a major operational constraint: each keypair preallocates a finite number of one-time signature slots. For the listed LMS variant that is about a million slots, and reusing a slot lets anyone forge signatures from that slot. Managing which slots are used — the "state" — is a serious operational burden, what Adam Langley famously called a "huge foot-cannon."

Key generation is also expensive: preparing each slot costs roughly as much as one signature verification, so preparing all million takes a couple of hours on a single core. A popular CA like Let’s Encrypt issues over four million certificates daily, so one intermediate with a million slots is nowhere near enough. XMSS^MT and HSS solve that internally by adding more intermediate layers. Finally, these schemes have a non-repudiation limitation: the listed LMS instance gives 192 bits of resistance against forgery but only 96 bits against the signer themselves finding a single signature that verifies two different messages.

Even where stateful hash-based signatures or Falcon are usable, the added bytes hurt performance. NIST’s motivation for the second competition is to find something that beats both ML-DSA and Falcon in deployability.

Alternatives to Structured Lattices

Half the new candidates actually perform worse than ML-DSA when measured purely on speed. That is deliberate: NIST worries that the ecosystem is over-reliant on structured lattices and wants a general purpose scheme that is not lattice-based yet still beats SLH-DSA's performance. Several candidates target exactly that gap.

Code-Based Signatures

CROSS and LESS both derive from code-based problems. CROSS builds on a variant of the syndrome decoding problem; its signatures are close to SLH-DSA in size but with much better signing times. LESS is based on the newer linear equivalence problem. It beats SLH-DSA on signature size but needs much larger public keys, and its verification times are especially problematic for TLS. LESS's underlying problem is fresh, so there may be room for improvement as analysis progresses.

MPC-in-the-Head Schemes

Five submissions — Mirath, MQOM, PERK, RYDE, and SDitH — use the multi-party computation in the head (MPCitH) paradigm. The concept dates back to Picnic from the previous NIST competition. In essence, the signer simulates a multi-party computation that splits a secret key x into shares and computes a shared result, then reveals just enough intermediate values through Fiat–Shamir to prove knowledge of x without revealing it.

Picnic originally produced 32kB signatures and leaned on LowMC, a block cipher designed for efficient MPC. Improved versions reached 12kB, but SLH-DSA won out because it was smaller and rested on better-studied hash functions. The MPCitH candidates that advanced all offer variants with signatures comparable to or smaller than SLH-DSA while signing considerably faster, at the cost of higher verification times. RYDE and SDitH are essentially code-based under the hood, using variants of syndrome decoding as their trapdoor.

MPCitH has seen remarkable gains in recent years, and further improvements seem likely. The open questions are whether signature sizes can shrink without making verification unacceptably slow, and whether each candidate's underlying trapdoor withstands deeper scrutiny.

FAEST

FAEST takes a different tack: its security reduces to AES itself. Assuming the analysis holds, that places it on footing as conservative as SLH-DSA, yet it beats the MPCitH candidates on performance and SLH-DSA on every metric. At the AES-128 level its signatures are bigger than ML-DSA, but as a hedge against improvements in lattice attacks it becomes attractive — FAEST's EM-128f variant has combined key and signature sizes close to ML-DSA-65 (which totals 5.2kB) with a slight performance edge for the lattice scheme.

FAEST is built on the 2023 VOLE-in-the-Head paradigm. Those techniques are new and likely not fully exploited yet, and they may well spill over into the MPCitH submissions. Applied to less conservative trapdoors, the approach could plausibly close the gap with ML-DSA. Whether it can reach Falcon's territory remains to be seen.

The Smaller, Faster Contenders

HAWK

HAWK improves on Falcon substantially: no floating-point arithmetic, simpler signing, and much faster signing overall, which makes it suitable for online signatures. Using HAWK adds just 4.8kB to the handshake. It also avoids the operational complexity of mixing two schemes — relying on a single algorithm reduces both the algorithmic attack surface and the chance of implementation mistakes. It shares Falcon's downside of missing a middle security level: HAWK-1024 doubles the sizes to 9.6kB. Its main caveat is reliance on a newer security assumption, the lattice isomorphism problem.

SQISign

SQISign is an isogeny-based scheme, an area that drew attention for the wrong reasons when SIKE was broken badly late in the previous competition. SQISign rests on a different problem and achieves remarkably small signatures and public keys — smaller even than RSA-2048. The tradeoff is computational expense: both signing and verification are very slow, and signing is hard to make timing side-channel secure. Even with improvements, it is hard to see signing becoming fast enough for TLS handshakes. If larger signatures could buy faster verification, that trade on the verification side might eventually make SQISign relevant for the non-handshake signatures in TLS.

UOV and Structured Multivariate Schemes

UOV is a long-established multivariate scheme with huge public keys (67kB) but tiny signatures (96 bytes) and excellent signing and verification speeds. Those characteristics suit use cases where public keys are already known. In TLS, using UOV for SCTs and the root CA — whose public keys are not transmitted during connection setup — alongside ML-DSA for other signatures brings handshake overhead down to 7.2kB, marginally better than a Falcon-plus-ML-DSA combination. Pairing UOV with HAWK instead trims the added bytes to 3.4kB. The advantage would grow if the certificate transparency ecosystem starts demanding more SCTs. The size of UOV public keys is palatable for the limited number of CT logs and even for several hundred root CAs, but not for thousands of intermediate certificates, even with intermediate suppression.

Structured multivariate variants that add mathematical structure to UOV for better size tradeoffs have a poor track record: GeMMS and Rainbow both fell to attacks. QR-UOV's most TLS-relevant variant has 24kB public keys and 157-byte signatures, but current verification times are unacceptably high. Even with room for implementation improvements, its combined key plus signature size keeps it out of direct competition with ML-DSA or Falcon. QR-UOV's real rival is UOV itself, which has unwieldy public keys. Although QR-UOV has not been attacked directly yet, a closely related scheme has recently been weakened and another broken.

SNOVA and MAYO both allow a granular tradeoff between public key and signature size, which is useful when deciding what gets transmitted over the connection. Combining MAYO_one for leaf and intermediate certificates with MAYO_two for everything else adds 3.5kB; SNOVA does the same job with just 2.8kB. Both sign and verify excellently. Security is the obvious concern: a new generic attack on underdefined multivariate systems forced the MAYO team to adjust parameters slightly, and SNOVA has absorbed three separate attacks. The SNOVA team says parameters can be adjusted to compensate, but the pattern is cautionary.

The broad takeaway is that promising candidates exist to cut the wire cost imposed by ML-DSA and Falcon. None of the practical ones will eliminate the added bytes entirely. The question that remains is how many extra bytes TLS can tolerate.

Byte Counts and the Real Cost of Quantum-Ready Certs

Cloudflare currently terminates roughly 15 million TLS connections per second. Swapping every certificate chain for ML-DSA would consume about 1.8 Tbps of bandwidth — roughly 0.6% of total network capacity. The bandwidth itself is manageable; the more pressing issue is latency.

Measurements from 2021 show that adding more than 10kB to certificate chains triggers a noticeable jump in client and middlebox failures. Chains with less than 9kB of overhead still slow TLS handshakes by about 15%. That regression is borderline acceptable but risky: if it discourages early adoption, the industry may delay deployment until post-quantum migration becomes urgent.

Chrome has set a tighter budget, targeting no more than 10% regression in handshake time. The browser is already seeing a 4% slowdown from post-quantum key agreement alone — roughly 1.1kB of extra server-to-client data and 1.2kB client-to-server — a proportionally larger impact than Cloudflare's 15% for 9kB, likely because upload links are slower than downloads.

Some argue handshake time is the wrong metric. Session resumption avoids resending certificates entirely, and typical page loads transfer far more than the +10kB a post-quantum chain would add. Amazon researchers simulated large ceritificate chains on data-heavy TLS 1.3 connections and found that the handshake penalty disappears once a connection carries multiple requests and hundreds of kilobytes.

Are such connections the norm? Looking at QUIC traffic carrying at least one HTTP request, 37% are resumptions — they reuse key material and skip certificate transmission entirely. For non-resumed connections, the median server-to-client transfer is just 7.8kB (551kB average), and the average is dragged up by a small set of data-heavy flows. Only 15.8% of all QUIC connections move more than 100kB.

Current median certificate chains compress to about 3.2kB. On more than half of non-resumed QUIC connections, certificates account for nearly 40% of all transferred bytes. Replacing classical signatures with ML-DSA would more than double the total bytes on those connections. This is still a proxy — the real question is user-facing impact like largest contentful paint or monthly data caps — but the direction is clear for a large share of traffic.

Where the Candidates Stand

Compared with the 2021 field, today's signature schemes show substantial improvement across families, and progress continues. History is also a warning: several algorithms considered in 2021 have since been broken, so novelty carries risk.

For TLS today, HAWK, SNOVA, and MAYO are each clear wins over ML-DSA and Falcon in implementation and performance. They are also young schemes, and the lack of maturity means they need a fallback. UOV is an older design, but its large public keys make it unsuitable as a standalone option — better as a complement to a general-purpose signature.

The core tension remains: even the best drop-in certificate replacement will materially weaken performance on at least half of TLS connections, given current usage patterns.

There is an alternative: redesign how TLS authentication works to use fewer signatures outright. Possible paths include omitting intermediate certificates, using a KEM for handshake authentication instead of a signature, or the more ambitious approach of eliminating offline signatures altogether via Merkle-tree certificates. These directions appear in earlier Cloudflare analysis and could yield a post-quantum Internet with fewer bytes on the wire.

Near-term expectations: browsers and Cloudflare will keep investigating end-user impact. Once certificate authorities support the new algorithms — likely by 2026 — ML-DSA certificates will be offered at no cost, but only as opt-in until cryptographically relevant quantum computers are close, so traffic avoids unnecessary latency before that point. Longer-term work continues on WebPKI changes that deliver post-quantum security without the performance tradeoff.

Certificates are not the immediate concern, though. Encryption is. X25519MLKEM768, the post-quantum key agreement, is already deployed broadly across the industry, including by major browsers. Connections to Cloudflare can already be verified against harvest-now/decrypt-later at pq.cloudflareresearch.com.