{"slug": "why-we-cannot-wait-for-better-post-quantum-signature-algorithms", "title": "Why we cannot wait for better post-quantum signature algorithms", "summary": "Cloudflare warns that post-quantum signature algorithms under development will not be ready in time for the migration to quantum-safe cryptography, forcing reliance on the already-standardized ML-DSA despite its drawbacks. The company targets full post-quantum security by 2029, while NIST advances nine new signature schemes to the third round of evaluation.", "body_md": "RSA and ECC, cryptographic algorithms that we’ve all relied on for decades, are __vulnerable__ to the attack of sufficiently advanced quantum computers. Such quantum computers do not exist yet, but they seem to be coming __sooner__ than expected. Luckily, the solution is already available: migrate to ML-KEM encryption and ML-DSA signatures, which are designed to be resistant to quantum attack. They were standardized __in 2024__ by the U.S. National Institute of Standards and Technology (NIST) after an eight-year open international competition.\n\nThe migration to post-quantum cryptography is in full swing now. At the time of writing, the majority of traffic handled by Cloudflare is already using ML-KEM encryption, and is thus secured against the threat to data posed by __harvest-now-decrypt-later__ attacks. But encryption is only one part of the equation: to be fully secure against quantum computers capable of breaking classical cryptography, we aim to deploy post-quantum signatures to protect authentication systems from unauthorized access. We are __targeting 2029__ for Cloudflare to be fully post-quantum secure.\n\nML-DSA, the best all-around post-quantum signature scheme standardized today, has its downsides: it’s much larger on the wire, and many __tricks__ we were able to perform with RSA and ECC simply cannot be done with ML-DSA. There are better post-quantum signature schemes on the horizon: last month, NIST __announced__ that it is advancing nine post-quantum signature schemes to the third round of the “__signatures on-ramp__”. And a draft standard for __FN-DSA__ (née Falcon), which was picked from the previous competition, is expected imminently.\n\nWe have been very interested in advances in post-quantum signature algorithms, and wrote about the progress in __2021__, __2022__, __2024__, and __2025__. In this blog post we’ll treat you to the latest developments in great detail.\n\nBut first we have to deal with the elephant in the room: These new signature algorithms will not be ready in time for the PQ transition — not even close, as we __will see later on__. The problem is arriving too soon for us to wait. ML-DSA is available today, and it will have to do for the first migration. As Eric Rescorla __wrote__ in 2024:\n\n*You go to war with the algorithms you have, not the ones you wish you had.*\n\nNonetheless, the search for better post-quantum signature algorithms is crucial for several reasons, and we firmly believe it is still the best use of NIST’s limited resources.\n\nLet’s have a look at the signature algorithms in detail. After that we’ll look at the timeline for their availability, and the reasons why we still need them.\n\nIn the table below, we compare the candidate signature algorithms that progressed to the third round (marked by 🤔), with classical algorithms vulnerable to quantum attack (marked by ❌), and the post-quantum algorithms that are already standardized ( ✅) or soon will be (📝). Each candidate proposes several variants. We list the most relevant variants to TLS, the protocol used to secure connections on the Internet. To explore all variants, check out __Thom Wigger__’s __signatures zoo__.\n\n|\n|\n|\n|\n**Sizes** (bytes)\n|\n**CPU time** (lower is better)\n|\n**Family**\n|\n**Name** variant\n|\nA\n|\nPublic key\n|\nSignature\n|\nSigning\n|\nVerification\n|\n|\nElliptic curves\n|\nEd25519\n|\n❌\n|\n32\n|\n64\n|\n0.15\n|\n1.3\n|\n|\nFactoring\n|\nRSA 2048\n|\n❌\n|\n272\n|\n256\n|\n80\n|\n0.4\n|\n|\nLattices\n|\nML-DSA 44\n|\n✅\n|\n1,312\n|\n2,420\n|\n1 (baseline)\n|\n1 (baseline)\n|\n|\nSymmetric\n|\nSLH-DSA 128s\n|\n✅\n|\n32\n|\n7,856\n|\n14,000\n|\n40\n|\nSLH-DSA 128f\n|\n✅\n|\n32\n|\n17,088\n|\n720\n|\n110\n|\nSLH-DSA 128-24\n|\n📝\n|\n32\n|\n3,856\n|\n7,000,000 ⚠️\n|\n4\n|\nLMS M24_H20_W8\n|\n✅\n|\n48\n|\n1,112\n|\n2.9 ⚠️\n|\n8.4\n|\n|\nLattices\n|\nFN-DSA 512\n|\n📝\n|\n897\n|\n666\n|\n3 ⚠️\n|\n0.7\n|\n|\nLattices\n|\nHAWK 512\n|\n🤔\n|\n1,024\n|\n555\n|\n0.25\n|\n1.2\n|\n|\nProof of knowledge\n|\nMQOM L1-gf16-fast-5r\n|\n🤔\n|\n60\n|\n3,280\n|\n8\n|\n20\n|\nSDitH SDitH2-L1-gf2-fast\n|\n🤔\n|\n70\n|\n4,484\n|\n15\n|\n40\n|\nFAEST EM-128f\n|\n🤔\n|\n32\n|\n5,060\n|\n4.2\n|\n9\n|\n|\nIsogeny\n|\nSQIsign I\n|\n🤔\n|\n65\n|\n148\n|\n300 ⚠️\n|\n50\n|\n|\nMultivariate\n|\nMAYO one\n|\n🤔\n|\n1,420\n|\n454\n|\n2.1\n|\n0.4\n|\nMAYO two\n|\n🤔\n|\n4,912\n|\n186\n|\n1.1\n|\n0.8\n|\nQR-UOV\nI-(127 156 54 3)\n|\n🤔\n|\n24,225\n|\n200\n|\n9.3\n|\n20\n|\nSNOVA (24,5,4)\n|\n🤔\n|\n1,016\n|\n248\n|\n1.2\n|\n1.7\n|\nSNOVA (25,8,3)\n|\n🤔\n|\n2,320\n|\n165\n|\n1\n|\n1.5\n|\nSNOVA (37,17,2)\n|\n🤔\n|\n9,842\n|\n124\n|\n0.8\n|\n1.3\n|\nUOV Is-pkc\n|\n🤔\n|\n66,576\n|\n96\n|\n0.3\n|\n2.4\n|\nUOV Ip-pkc\n|\n🤔\n|\n43,576\n|\n128\n|\n0.3\n|\n2\n|\n\nA few more remarks on this table: Most candidates have multiple variants in every security level. We show the most relevant variants for TLS at the 128-bit security level, the gold standard for security. CPU times are taken from the __signatures zoo__ in June 2026, which collected them from the round two submission documents and later advances. Candidates are allowed to make changes for the third round, which will influence these numbers. Some will improve (both in compute and size), whereas others will regress to counter new attacks. Check out the zoo for the latest numbers. We marked FN-DSA and SQIsign signing with a ⚠️️, as both are hard to implement in a fast and __timing side-channel secure__ manner. LMS signing has a ⚠️, as secure LMS signing requires keeping state across signatures, and the listed signing time assumes a 32MB cache. The 128-24 variant of SLH-DSA is marked with a ⚠️️ as it’s meant to create fewer than 224 signatures.\n\nOne thing that stands out immediately is that the quantum-vulnerable elliptic curves signature algorithm Ed25519 is by far the best all-around choice (ignoring its quantum vulnerability): it has the best numbers in almost every single metric, including public key size, signature size, and signing time. It’s only beaten on verification time, but it’s more than fast enough for the vast majority of applications.\n\nThis is quite different than the roster of post-quantum algorithms. Instead of a single \"all-star\" algorithm, we have roughly two categories of schemes: the \"specialists\" that approach our trusty elliptic curve signatures on some metrics, but are problematic on others, which make them great in the right deployment scenario. Then there are the “generalists”, such as ML-DSA, which don’t perform as well as elliptic curves on all metrics, but so far as downsides go, are pretty balanced.\n\nLet’s start with the specialists.\n\n### SQIsign: small signatures / slow signing\n\nIf you just look at the bytes on the wire, then **SQIsign** looks like an almost perfect drop-in replacement for elliptic curve cryptography. With signatures of 148 bytes and public keys of 65 bytes, it beats RSA-2048. Unfortunately there is no free lunch: SQIsign has three weak points. First, it’s the most complex algorithm on the docket. Secondly, its signature creation and verification is quite slow. Finally, it’s difficult to implement signature creation in a timing side-channel secure way and doing so comes with a performance penalty to boot.\n\nThat doesn’t sound great so far, but it was much worse: when we had a __look back in 2024__, there was not yet any timing side-channel secure implementation and signature verification was 20x slower. Furthermore there has been welcome progress on simplifying the scheme.\n\nDespite these dramatic improvements, it is unlikely (side-channel secure) signing will be fast enough in the foreseeable future to be used in typical *online* cases such as the TLS handshake. However, for *offline* cases, such as CA signatures or DNSSEC, where it’s the verification time that’s more important than the signing time, SQIsign might have an application.\n\nBut the topic we should really discuss is security. SQIsign is based on __isogenies__. Rather famously, SIKE, another algorithm based on isogenies, got broken __badly__ in a late stage of the first NIST PQC competition that standardized ML-DSA. SIKE is often brought up as a cautionary example showing that post-quantum cryptography could break suddenly. This requires some nuance. First, there were already concerns about SIKE’s security, and in particular the *torsion points* that led to the break. Because of these concerns, SIKE was not selected for standardization, but deferred to an additional __round__ of evaluation before it was broken. (Indeed, this is an example of the NIST process working well.) SQIsign doesn’t use torsion points, and there is no similar concern as there was for SIKE.\n\nOne other notable security property is that the best known attacks on SQIsign are generic brute force, just like with classical attacks on well-selected elliptic curves. This is quite different from RSA, lattices, and multivariate where the attack algorithms have been slowly improving, pushing the parameters towards bigger signatures. Nonetheless, the mathematics behind isogenies is very rich, and compared to the other algorithms, there is a lot of *mathematical attack surface*. Still, its security seems more sound than the structured multivariate algorithms we’ll discuss later.\n\nSQIsign is an algorithm with tremendous potential. It’d be a shame to standardize it too early. To the authors, we’d like to share the following wishlist:\n\nIdeally verification time is decreased even further, even if this trades off against signing time and signature size: SQIsign signatures are already small enough, and offline signing time has some slack anyway.\n\nThe timing side-channel secure implementation should be the default, especially if signing time is decreased further, which would tempt some online signing applications.\n\nBut above all, our wish is for SQIsign to be simplified.\n\n### UOV: tiny signatures / huge public keys\n\n**UOV** (unbalanced oil and vinegar) is a classic multivariate signature algorithm originally proposed in 1999. It has tiny signatures: only 96 bytes. The trade-off? A huge public key: 66kB. That wouldn’t help for a TLS server certificate, whose public key is transmitted over the wire when setting up a connection, but it would be a help for cases where the public key is predistributed.\n\nLet’s take the WebPKI as an example. A typical browser trusts about a hundred root certificates and 30 certificate transparency logs, whose public keys would add up to about 8MB when using UOV.\n\n*The public keys and signatures in a typical TLS connection.*\n\nSince the root certificate is transmitted to clients out of band, one idea is to use a UOV signature there. But this is not a slam dunk; because of its size, a UOV root certificate would be impractical to be cross-signed where the root is used as an intermediate. At the same time, cross signs and intermediates become less attractive anyway with any larger post-quantum signatures. This encourages more root certificates to be included directly with clients. This would again favor UOV, but to a point: if the number of root certificates grows above a thousand, we’d be dealing with more than 66MB of key material, which would make up a substantial portion of the browsers’ download size (e.g., 90MB for Firefox 151.)\n\nWhat about the security? Over the years, many variants of UOV have been proposed that use some extra mathematical structure to reduce the size of the public key. These *structured multivariate* schemes have had a spotty track record with schemes such as __Rainbow__ and __GeMMS__ being broken quite badly. It is important to distinguish these from UOV itself, whose security track record is much better, but not perfect.\n\nAs with many cryptographic schemes, there were growing pains in the early years, as basic attacks and parametrization pitfalls were discovered. In fact, the “U” in UOV is a remnant of that: it stands for *unbalanced*, which is a fix to a parameter-setting mistake in the 1997 oil-and-vinegar scheme on which UOV is based: the original scheme had an equal number of *oil* and *vinegar *variables in the quadratic system of equations used as the public key, which turns out to allow for __an attack__. In case you’re curious about the colorful name: the system of equations contains vinegar x vinegar and oil x vinegar, but no oil x oil terms. It’s like vinaigrette with small separate oil droplets. Back to the history: from 2005 to 2020 was a quiet period for multivariate signatures: understanding of UOV grew, but there weren’t any new attacks on typical parameters.\n\nThis changed in 2020 with the __discovery__ of the *intersection attack* which built on the ideas of the original attack on balanced oil-and-vinegar. The intersection attack removes about 30 bits of security from a then-proposed 128-bit parameter set. A considerable blow, but not fatal: slightly adjusting parameters mitigates the attack completely, with minor increase in key and signature size.\n\nA bigger shock was the 2025 __publication__ of the idea to use __wedges__ to attack multivariate schemes. The initial impact on UOV was minor: only a few bits (again at the 128-bit security level.) The worry was that this idea came out of left field, and it wasn’t clear how far the approach could be taken. That concern was partly justified: the wedges idea was very fruitful and several subsequent attacks have been built on it, reducing security by about 15 bits. However, it also became __clear__ that the wedges attack and generalizations can be seen as a special case of an *intersection attack* over truncated rings — thus much more familiar than we thought. Again, these attacks can be mitigated with only minor increases in key and signature size.\n\nWhat to make of all of this? Such a history of attacks is not uncommon: over the last 25 years lattices have seen larger reductions in security, although this has calmed down over the recent years. Notwithstanding, lattice-based cryptography deployed in production today uses conservative parameter sets well above 128-bits to hedge against future cryptanalysis. We’d want to do the same with UOV. Signature size only grows linearly with the security level, costing just 260 bytes even at the 256-bit security level. Unfortunately, the public key size is cubic in security level: 446kB for 256-bit. Conveniently, UOV (as most multivariate schemes) has a lot of flexibility in picking parameter sets at various intermediate security levels.\n\nUOV is a foundational scheme with narrow but real use cases. Going forward, we’d like to see a parameter set with a bit of margin above 128 bits, say 160 bits, to hedge against future cryptanalytic improvements.\n\n### QR-UOV: small signatures / large public keys\n\nLike SNOVA and MAYO which we’ll discuss later on, **QR-UOV** is a structured multivariate scheme: it’s a variant of UOV that adds more structure to the public key to reduce its size. The gains are modest: at best we’re looking at 12kB public keys, but signature verification is impractically slow for that particular parameter set. The more realistic parameter sets start at 24kB public keys.\n\nWith respect to security, QR-UOV is the only multivariate scheme that did not have to adjust its original (round one) parameters in response to new attacks. This is somewhat surprising as any attack on UOV can also be applied to QR-UOV. The explanation is that the attacks do apply, but the natural parameters for QR-UOV happen to make them ineffective. On the other hand, there were already several attacks known that use the specific extra structure that QR-UOV adds: indeed, for some of the parameter sets, the structure-specific attacks are the best attacks. This should be contrasted with MAYO, where there is no known attack against the extra structure MAYO adds. (We’ll get back to MAYO and SNOVA later in this post.)\n\nCompared to last round, QR-UOV signing and verification time improved significantly, but it is still comparatively slow. All in all, QR-UOV is a hard sell: it adds exploitable structure to UOV without pushing key sizes down to general-purpose sizes.\n\n#### Stateful hash-based signatures\n\nThe very first standardized post-quantum signature algorithms are the stateful hash-based __LMS, HSS__ and __XMSS__(MT). They have very small public keys, and for many parameter sets the signatures are much smaller than those of ML-DSA-44. To boot, their security is based on that of hashes, which are well-understood and already a cornerstone of cryptography. That makes hash-based signature algorithms a very conservative choice, and there is no need to hedge with higher security levels.\n\nSo, what’s the catch?\n\nThere are two. The big one is keeping the eponymous state. These stateful hash-based signature schemes are built out of one-time-signature keys which are collected into Merkle trees. The signer has to keep track of which one-time-signature keys have been used, which can be as simple as just a counter. If the signer mucks it up, though, and accidentally uses the same one-time-signature key twice on a different message, then anyone can __likely__ use those two signatures to create their own signature on any message. You have to keep a lot in mind to keep the state correctly. Some considerations: you want to make sure that updates are written to storage before handing out the signature; you don’t want the old state to be restored from a backup; and you can’t export/import a private key from one place to another without agreeing on how to split or keep the state. The state is, as Adam Langley __pointed out__ several years ago, a huge foot-cannon.\n\nAnother downside is that the most competitive parameter sets can only create a modest number of signatures. The 1,112 byte signatures (as listed in the table above) can only be used to create about a million signatures. You can explore the trade-offs with this __calculator__.\n\nTogether this leaves a very small niche for stateful hash-based signatures: signers have to be able to keep state; signature size has to be a real concern; and signers have to be OK with a hard limit on the number of signatures.\n\n#### SLH-DSA: conservative security / large and slow\n\n**SLH-DSA** is a hash-based signature that doesn’t have the low signature limit and avoids the problem of keeping the state. The basic idea is to make the number of one-time-signature keys so large that you can pick one at random without having to worry about using the same one twice, since the chance of picking the same one twice is diminishingly small. SLH-DSA is a bit more efficient than that, by replacing the one-time-signature key as a building block with a few-time-signature key, where security degrades gracefully if keys are occasionally reused. It still comes at a cost. SLH-DSA has two variants, one that optimizes for small signature size, and one that optimizes for fast signing. The size-optimized one is not small at all at 8kB, and the signing-optimized one is even slower than SQIsign.\n\n##### Fewer signature variants of SLH-DSA\n\nNIST has __proposed__ to standardize an additional parameter set for SLH-DSA with much smaller signatures, but that can only be used to create about 16 million signatures before security reduces. At 3.8kB the signatures are still larger than those of ML-DSA-44, but the combined public key and signature size is very close. The parameter set was chosen to make signature verification fast at the cost of signing time. The signing time is very bad indeed.\n\nSo why ever use SLH-DSA? The selling point is the conservative security. For a long-term trusted key that is hard to replace, it could make sense if the application can stomach the large signature and slow verification of the standardized variants or the slow signing time of the newly proposed one. There are two more caveats to add. First, it’s better to set things up so that key algorithms are not burned-in and can be replaced after the fact. And secondly, in most cases systems (such as secure connections with TLS) do not just depend on signatures, but also on key agreement. There is no hash-based key agreement mechanism, so we end up needing to trust something less conservative, like lattices, anyway.\n\n### FN-DSA: small key and signatures / subtle signing\n\nComparing the numbers, FN-DSA-512 (née Falcon) looks much better than ML-DSA-44 on almost every metric: faster verification, smaller public key, and much smaller signatures at 666 bytes. Signing is three times slower, but it’s still 25x faster than RSA-2048. To boot it’s already picked to become FIPS 206. So why don’t we consider FN-DSA to be a general-purpose algorithm?\n\nIt’s because it’s difficult to implement FN-DSA signing securely. The most well-known sharp edge of FN-DSA is that it is most naturally and efficiently implemented using hardware-accelerated __floating-point arithmetic__. This is a first for a cryptographic standard. One big challenge with it is that we have little experience implementing fast floating-point arithmetic in a side-channel safe way. What we know so far is that it’s subtle and not very robust: a safe implementation of FN-DSA signing using the Floating-Point Unit (FPU) for one processor might not be safe for another. Instead of relying on the FPU, the floating point operations can be emulated. This is easier to get right, but about 20 times slower, making it about as slow as RSA-2048. There has been some welcome __progress recently__ to implement FN-DSA signing safely using fixed-point arithmetic, which is much faster than the floating-point emulation. So just use that and FN-DSA is good to go? This presumes a level of awareness that might not be warranted. Anecdotally at conferences, every time we saw a presenter compare post-quantum signature algorithms including FN-DSA in benchmarks, they couldn’t answer whether floating-point emulation was used.\n\nAnother consequence of using floating points is that it’s difficult to make test vectors for signing. Just one example of this is that the outcome of *a+(b+c)* and *(a+b)+c* are only guaranteed to be close, but not the same. That means that to have useful test vectors, the FN-DSA specification would need to be very precise on the order of floating-point operations. Another example is *a*b+c*, which can be computed in two steps (multiply and then add), or at once using __fused-multiply-add__ (FMA). The latter is faster, but again gives a slightly different answer as rounding happens only once. Not all processors support FMA, but for those that do, compilers typically automatically use FMA for the performance boost. There are also mathematical optimizations that cause trouble. For instance, the reference implementation computes a value (norm) in a faster roundabout way using __Parseval’s theorem__. Mathematically the answer is exactly the same, but as floating-points are only an approximation, the resulting value is ever so slightly different. Similarly, the safe fixed-point arithmetic implementation gives slightly different results.\n\nWhy is this a problem? It is because it is still the humble test vector that catches most implementation bugs in practice. Other more refined methods like formal verification will certainly catch more, but test vectors are hard to beat in simplicity.\n\nAnother surprising sharp edge from not having a fixed implementation is the following. From two deterministic signatures created by slightly different implementations from the same private key, one can __derive parts of that private key__. FN-DSA does not use deterministic signatures, instead adding a randomizer to thwart this. There is a tension with testing: you need a deterministic interface to test signing, but you don’t want that to be used to create actual signatures.\n\nHow to deal with the wiggle room in the FN-DSA specification will undoubtedly be a point of discussion. The discrepancy between the implementations might actually have a silver lining: NIST could decide to generate the test vectors (__CAVP__) from the fixed-point arithmetic implementation. That the more risky floating-point implementation wouldn’t pass the test vectors would be a feature, not a bug, as it would steer implementations towards the safer fixed-point version!\n\nYou can read about a few other interesting sharp edges in __this blog post__. Stepping back from the specifics, the main point is that FN-DSA is a complicated scheme. It’s not a surprise that it took NIST a __couple of years__ (not counting the current limbo) just to write the draft standard. It’ll take longer than usual for the final standard to come out and for cryptographic libraries to add support. FN-DSA is farther away than it seems. We’ll compare timelines later in this blog post.\n\nIf the numbers are still very tempting, there is one last thing you should be aware of: FN-DSA-512 is parametrized for 128-bit security compared to ML-DSA-44’s generous 160 bits. If lattice cryptanalysis improves, there is no middle security level: the next step-up is all the way to FN-DSA-1024 at 256 bits. FN-DSA-1024 has double the key and signature sizes and signing and verifying times of FN-DSA-512. An FN-DSA-1024 signature is still half the size of that of ML-DSA-44, but the *public key+signature* only differs about 20%.\n\nTo close the discussion of FN-DSA, it is good to emphasize that all difficulties with FN-DSA are on the signing side: the verification of an FN-DSA signature is very straightforward.\n\n## General-purpose algorithms\n\nNow let’s turn to the algorithms that are meant to be general-purpose replacements for ML-DSA.\n\n**HAWK** is a curious case. In many aspects it’s similar to FN-DSA: a structured lattice hash-then-sign scheme with similar sizes for signatures and public keys with a missing middle security level. The main benefit of HAWK over FN-DSA is that signing is very fast and doesn’t use floating-point arithmetic, although it’s not a simple algorithm either. This comes with a trade-off: HAWK is based on and introduces a new security assumption, the *lattice isomorphism problem *(LIP). In 2024, two years after the introduction of HAWK, it was discovered that this problem is __easy to solve__ in the special case of totally real number fields, which aren’t used in HAWK or any other cryptography. In 2025, this attack was __extended__ to a broader class of number fields. This hasn’t yet applied to HAWK, but it’s getting closer. A new paper __published__ in June 2026 suggests there is a way to extend the attack to HAWK. An error has been found in the paper, although it’s yet unclear how fundamental it is to the approach. Regardless, the trajectory is concerning.\n\nEven ignoring the potential attacks, HAWK faces some headwinds: its additional security assumption prevents it from displacing FN-DSA, but its practical benefits (especially considering the lack of middle security level) fall short of that of the structured multivariate candidates. It also doesn't increase diversity in security assumptions, an outcome that NIST is hoping for.\n\n### Proof-of-knowledge schemes\n\nFAEST, MQOM, and SDitH all share a similar overall structure. Their public keys are instances of some hard problem and their secret keys are the solutions.\n\nA **FAEST** public key is the AES-encryption of a known plaintext under a secret key.\n\n**MQOM** gets its name from the Multivariate Quadratic problem, which is closely related to (but more conservative than) the cryptographic assumptions underlying the multivariate schemes. The public key is a system of quadratic equations, and the secret key is a solution to that system of equations.\n\n**SDitH** is based on the hardness of the Syndrome Decoding problem for random linear codes. This problem is related to the code-based schemes submitted to the original NIST competition, but these were eliminated in the third round.\n\nIn all cases, a signature is a __zero-knowledge proof__ that the signer knows the solution of that hard problem, while at the same time (almost as an afterthought) acknowledging the message-to-be-signed as part of the proof.\n\nMany signature schemes are zero-knowledge proofs like this behind the scenes, notably ML-DSA, SQIsign, and Ed25519. Why don’t we group those with *proof of knowledge* schemes too?\n\nThe difference is generalizability: the __zero-knowledge proof used for ML-DSA__ is only able to prove something about a specific LWE problem as used in ML-DSA: the proof uses mathematical structure in the key. There are __ways__ to create zero-knowledge proofs using lattices for any general statement, but those proof systems are very different from ML-DSA, and would create rather larger signatures on the order of 50kB.\n\nIn contrast, the proof system used in FAEST, MQOM, and SDitH can be used to prove arbitrary statements. For instance, FAEST can be modified to use the hard problem of MQOM instead. This leads to a more efficient scheme called __KuMQuat__. (We’ll get to some performance numbers later on.) Conversely, MQOM can be adjusted to use AES as the hard problem.\n\nThis flexibility is great for two reasons. First, it doesn’t require any specific mathematical structure in the hard problem used, and thus we can pick a very conservative problem such as breaking AES. Some problems lead to a more efficient signature than others, as we see with MQ as used in MQOM. MQ is still quite a conservative assumption: it does not contain the hidden subspace used in UOV and thus the other multivariate signatures. Neither the __intersection nor wedges attacks__ apply to it. In fact, the MQ-problem is NP-hard. To be secure, one still needs to pick the correct size of the problem, and although MQ has been studied for quite a while, it certainly has not seen the same scrutiny as deployed algorithms like AES.\n\nThe second and greater benefit is that we’re able to create much more than just a plain signature scheme from a general zero-knowledge proof system: we can create __blind signatures__ and even full-fledged anonymous credentials.\n\nHere it’s good to note a limitation: the size of the proofs for all three grows linearly with the statement proven. In technical terms: they’re not *succinct* like __STARKs__ and __LaBRADOR__, which outperform them handily for large statements. It’s another example where sometimes it’s better to pick the approach that’s not optimal asymptotically.\n\nBack to advantages: apart from the hard problem chosen, and the security of hash functions, these three schemes don’t require any further security assumption. This makes FAEST as conservative as SLH-DSA.\n\nSo what’s the difference except for the chosen hard problem? These schemes started off quite differently, but have been improving and converging since the first round. The proof system in MQOM is a bit simpler than FAEST, but it also does not perform as well: __KuMQuat__ (FAEST+MQ) outperforms MQOM.\n\nTalking about performance, let’s start with a comparison to SLH-DSA. All three schemes have variants that outperform any standardised SLH-DSA parameter set and often by a good margin. SLH-DSA does have one distinct advantage: the verification routine is simpler to implement.\n\nAgainst ML-DSA-44 the comparison is more interesting. All schemes have a smooth trade-off between runtime and signature size. To illustrate, here are trade-offs __reported__ for KuMQuat (FAEST+MQ.) Verification times are close to signing times.\n\nKuMQuat can be parametrized to have somewhat smaller signatures than ML-DSA-44 at the cost of long signing (and verification) runtime. At the other end, it can have similar signing time as ML-DSA-44, at the cost of larger signatures, although the public key+signature size is still similar.\n\nThese schemes have improved quite a bit over the years, and we expect some improvements still. Although they won’t improve upon ML-DSA as dramatically as some of the other schemes considered, their conservative security and especially their potential for broader applications like anonymous credentials make them very appealing. To showcase the flexibility of the underlying zero-knowledge proof system, we’d like each scheme in this category to present numbers on how well they’d perform with a different underlying hard problem.\n\n### Structured multivariate: MAYO versus SNOVA\n\nLike QR-UOV discussed earlier, MAYO and SNOVA are variants of UOV that add extra structure to the public key to reduce its size. MAYO and SNOVA take two different approaches: SNOVA makes aggressive bets to get the best performance, whereas MAYO treads carefully with a conservative design.\n\nSNOVA does have impressive performance. Its main parameter set has 248 byte signatures (smaller than RSA-2048!) with only a 1kB public key. It beats every other post-quantum scheme on public key+signature size and has great runtime.\n\nMAYO’s performance is nothing to scoff at either. MAYOone has the best verification time and its 454 byte signatures are still smaller than those of FN-DSA-512, HAWK-512, and RSA-4096. Combined with its 1,420 byte public key, MAYOone does slightly fall behind FN-DSA-512 and HAWK-512. However, MAYO takes the lead again if we ask for some security margin. FN-DSA and HAWK have a missing middle security level and thus need to bump all the way to the 256-bit security, whereas MAYO’s granularity can add extra security at the cost of slightly increasing public key and signature sizes.\n\n| **Security**\n| **Public key **\n| **Signature**\n| **PK + Sig**\n|\n**HAWK-1024**\n| 256 | 2,440 | 1,221 | 3,661 |\n**FN-DSA-1024**\n| 256 | 1,793 | 1,280 | 3,079 |\n**MAYO at 174 bit security**\n| 174 | 1,600 | 550 | 2,150 |\n\nIf that wasn’t good enough, both MAYO and SNOVA allow for a trade-off between signature and public key size. Thus, we can get even smaller signatures for public keys that are transmitted ahead of time. Pushed to the extreme, MAYO becomes UOV.\n\nSo far we have discussed performance. What about the security? MAYO adds a “whipping” structure on top of UOV: any attack on UOV will also work for MAYO, but there might be attacks specific to the whipping structure of MAYO. So far no attacks on the whipping structure, and thus on MAYO specifically, have been found. The worst that has happened is that some UOV attacks have affected some MAYO variants more than typical UOV parameter sets, due to the UOV parameter choices that are natural for MAYO.\n\nThis is in stark contrast to SNOVA. SNOVA has been hit quite hard on its specific structure several times. In response, the SNOVA team has not just tweaked parameters, but continuously changed the actual structure. Every time, they take the leap forward and propose a new SNOVA with even better performance. We noted this __last year__ and the pattern has continued, whereas MAYO’s basic design is stable.\n\nFurthermore, the structure SNOVA uses __can be__ __seen__ as a special form of the whipping map that MAYO uses. That means that any MAYO-specific attack would apply to SNOVA, but not the other way around.\n\nAll in all, we’ve seen a lot of progress on the understanding of multivariate security. NIST __wrote__ that they expect an extra round before standardizing a multivariate scheme. That seems prudent. To us, it’s unclear whether SNOVA would be ready by then, but MAYO so far seems to have matured well.\n\nNow, let’s have a look ahead and sketch when these new signature algorithms might become usable.\n\n### Progress for ML-DSA so far\n\nIt’s illustrative to look at ML-DSA.\n\nNovember 2017 | Submitted to the competition |\nJanuary 2019 | Progressed to the second round |\nJuly 2020 | Progressed to third round |\nJuly 2022 | Selected for standardization |\nAugust 2023 | Initial public draft |\nAugust 2024 | Final NIST standard |\nOctober 2025 | ML-DSA certificate standard (RFC 9881) |\nApril 2025 | OpenSSL 3.5.0 adds support for ML-DSA |\nAugust 2025 | Debian Trixie released with OpenSSL 3.5.0 |\nDecember 2025 | TLS IANA codepoint for ML-DSA registered |\nMarch 2026 | First CMVP certificates for ML-DSA module |\nJuly 2026 (expected) | Hybrid ML-DSA certificate standard |\nAugust 2026 (expected) | RFC for use of ML-DSA in TLS |\nEarly 2027 (expected) | Availability first ML-DSA certificates in WebPKI |\n\nAfter NIST selected Dilithium to become ML-DSA, it took a year to draft a proposal for the standard, and another year for the algorithm standard to be published. The algorithm standard is not enough: protocols need to agree on how to integrate ML-DSA. For certificates that took another year. That’s not the end of it: software needs to add support for ML-DSA and its integration into protocols.\n\nThese steps are not purely sequential: work on software implementation of ML-DSA started before the final standard. Also, protocol integration standards are often “done” before they’re a final standard. For instance, the use of ML-DSA in TLS is done, but at the time of writing it’ll take a couple of months before the RFC for that is out. Notably OpenSSL jumped the gun and added support for ML-DSA before the IANA codepoints were assigned. Notably missing still is agreement on which hybrid signatures should be used in TLS (__or at all__), for which (at the time of writing) no IANA code points have been assigned.\n\n### When will these new signature algorithms be ready for use?\n\nSo where does that leave us for new signature algorithms? If the **FN-DSA** draft is released today, and it progresses at the same rate as ML-DSA, then we’d perhaps have some early software support in early 2029, but no significant deployment. Looking at the time it took to write the FN-DSA draft standard, it is likely that the final standard, protocol integrations, and software support will progress slowly as well. We would not expect FN-DSA to be widely available before 2033.\n\nThe progress in cryptanalysis of **multivariate** schemes gave NIST pause: they wrote that they expect multivariate to at least take another round of about two years. On the other hand, multivariate schemes are reasonably easy to implement. That means we might see a multivariate NIST standard in 2031, and wider product availability not earlier than 2034.\n\nNIST is more confident in the security of **SQIsign** than that of multivariate. Not unlike FN-DSA, SQIsign is a difficult scheme to standardise and implement. At the same time, a lot of progress is made in simplifying SQIsign. It seems likely that SQIsign will make large changes for the third round, and will thus require a fourth round of evaluation. In either case, wide availability before 2035 seems unlikely.\n\nAs discussed __above__, **HAWK** occupies an awkward middle ground between FN-DSA and structured multivariate candidates. If it were standardized, which seems unlikely even before the recent progress in cryptanalysis, we wouldn’t expect product availability before 2034.\n\nThat leaves the *proof of knowledge* algorithms **MQOM**, **SDitH**, and **FAEST**. We’ve seen dramatic improvements to these schemes over the rounds. If that rate of change holds, it’ll require another round, but if it’s stable now, a proof of knowledge algorithm will be the first new NIST standard to see the light in 2030. If it’s out this early, it’ll likely not outperform ML-DSA dramatically. Nonetheless, it’ll still be very welcome to build anonymous credentials and other primitives beyond signatures.\n\nSo, should you wait on one of these signatures for your post-quantum migration? Given recent advances in quantum hardware and software, we don’t believe we can afford to wait. At Cloudflare, we’re aiming to be __fully migrated by 2029__. None of these signatures will be out in time. Deadlines of most regulators vary between 2030 and 2035. These did not account for recent progress, and we expect them to be adjusted. We saw just this with the __June 2026 US executive order__ setting a 2031 deadline. Even if deadlines weren’t changed, we wouldn’t advise waiting.\n\nWhy? Deploying post-quantum signatures in 2034 to beat a 2035 deadline is not enough. In a system of any reasonable size, you can’t upgrade everything all at once. You’ll need a transition period where both post-quantum and traditional signatures are supported. And supporting both allows for a downgrade attack. The most straightforward way to prevent such downgrades is to disable classical cryptography. That will take time, and is frankly not even an option in many sufficiently distributed systems like the WebPKI. We will cover how to deal with downgrades in a future blog post. In the meantime __here__ is some reading if you’re curious. In any case, dealing with downgrades will take time.\n\nIt seems clear these new post-quantum signature algorithms will not be ready to use in time for the first migration. So why bother?\n\nWe’ve had __50 years__ to weave public key cryptography all through our digital society. We have a few short years left to make it all quantum secure. For most of these upgrades the procedure is clear: drop in post-quantum cryptography. Easier said than done: it’s a monumental task. But then there are cases that are fundamentally harder. There's no all-star signature in a post-quantum world, and there are cases where the size of ML-DSA is a problem. With enough resources and stakeholder agreement, systems can be re-engineered to work well with these larger signatures. Indeed, thanks to ongoing re-engineering, the post-quantum WebPKI is shaping up to __perform better__ than the quantum-vulnerable one of today. It is unrealistic to expect that this will happen for every system before it’s too late. Some will have to accept a performance cost. Others will need to deal with the security gap in other ways, such as restricting access, tunneling, more monitoring, or a myriad of other measures that are costly on their own. Once smaller post-quantum signatures arrive, these compensating controls can be removed, and full efficiency and security restored.\n\nAn indirect, but no less important benefit of the ongoing NIST competition is its help in furthering post-quantum cryptography beyond basic primitives: it isn’t just key agreement and signatures that are quantum vulnerable. There is a long tail of __fancy ____cryptographic primitives__ out there used in production, such as anonymous credentials, PAKEs, and threshold signatures to name a few. For most, post-quantum variants are not readily available or are understudied. For some, the same goal can be achieved without fancy cryptography, but with a regrettable regression in subtle privacy goals. NIST cannot run a competition to define a post-quantum standard for each of these specific primitives, but luckily the signatures competition has been a huge help here.\n\nThe most clear example is FAEST. Although designed as a signature scheme, its underlying machinery (VOLEitH) can be repurposed in combination with a multivariate scheme like MAYO, to create an efficient __post-quantum anonymous credential__. Without the signatures competition, VOLEitH wouldn’t be as developed and vetted as it is today.\n\nMany of the candidate schemes briefly point out their usefulness apart from signatures. We hope to see more of the indirect applications of these schemes highlighted.\n\nDespite great signatures and more advanced cryptography on the horizon, we should not forget the task at hand: staying secure in the immediate future.", "url": "https://wpnews.pro/news/why-we-cannot-wait-for-better-post-quantum-signature-algorithms", "canonical_source": "https://blog.cloudflare.com/ml-dsa-will-have-to-do/", "published_at": "2026-07-09 13:06:44.256634+00:00", "updated_at": "2026-07-09 13:06:46.321083+00:00", "lang": "en", "topics": ["ai-policy"], "entities": ["Cloudflare", "NIST", "ML-DSA", "ML-KEM", "FN-DSA", "HAWK", "Eric Rescorla", "Thom Wigger"], "alternates": {"html": "https://wpnews.pro/news/why-we-cannot-wait-for-better-post-quantum-signature-algorithms", "markdown": "https://wpnews.pro/news/why-we-cannot-wait-for-better-post-quantum-signature-algorithms.md", "text": "https://wpnews.pro/news/why-we-cannot-wait-for-better-post-quantum-signature-algorithms.txt", "jsonld": "https://wpnews.pro/news/why-we-cannot-wait-for-better-post-quantum-signature-algorithms.jsonld"}}