What's better: upgrading an ECC-based protocol to ECC+PQ, or switching it to solo PQ? Here's the simplest way to see that solo PQ will be an inexcusable security disaster:
Some examples of what I've said about this before: I gave a 2016 talk recommending ECC+PQ, and I've been consistently recommending ECC+PQ since then. In 2018, I described the NIST post-quantum competition as "the largest regression ever in the quality of cryptographic software"; I said this "will not be easy to fix". In 2024, I wrote that "bugs in post-quantum software" warrant "a blanket rule of always upgrading from ECC to PQ+ECC, not discarding the ECC layer". At the beginning of June 2026, I posted a paper that uses standard techniques to estimate the number of ML-DSA keys that will be breakable because of the predictable influx of software bugs. (For ML-KEM the number will be much higher because the number of KEM keys used is much higher than the number of signature keys used, swamping any differences between ML-KEM bug rates and ML-DSA bug rates.)
To be clear, there's also the risk of a vulnerability in a PQ spec doing even more damage by affecting all of the software for that spec. But I've seen some people using pseudoscience and false claims of stability to claim that the specs for ML-KEM and ML-DSA aren't risky. Some security readers are skeptical enough to spot the warning signals in those claims, but others say "oh, okay, sounds like these experts say there's no problem" and end up fooled.
The virtue of focusing on software is that security readers are already software experts. This makes the software argument really challenging for proponents of solo PQ to respond to. The rest of this blog post goes step by step through how difficult this is:
I'll give quotes from proponents so you can see how they're struggling. I am, of course, also providing links to sources so that you can check what I'm saying.
C'mon, this wouldn't pass the laugh test. There have already been hundreds of vulnerabilities in cryptographic libraries. Software for Dilithium (ML-DSA) and Kyber (ML-KEM) has already had a variety of bugs and timing leaks, including a bug in the original official Dilithium implementation in 2017 and two timing leaks, KyberSlash1 and KyberSlash2, in every official reference Kyber implementation from 2017 through late 2023. The majority of Kyber/ML-KEM implementations issued patches for KyberSlash.
The libraries with CVEs or other bugs announced so far for ML-DSA code in 2026 include libcrux, libcrux again, libgcrypt, RustCrypto, RustCrypto again, wolfSSL, and wolfSSL again. On 24 June 2026, proponents of removing ECC from ECC+PQ called another vote for allowing that; the very next day, there was an announcement of CVE-2026-6330, an ML-KEM software bug in WolfSSL.
A large part of my work is fighting against security problems in cryptographic software: redesigning cryptography in light of implementation failures, for example, and building new tools to verify cryptographic subroutines. For larger-scale software scans, I've made many improvements over the years to the tests in SUPERCOP, tests that today are continually applied to 5036 cryptographic implementations contributed by hundreds of people. The types of software flaws caught by those tests include many of the flaws that we've seen in ML-KEM software and in ML-DSA software. But those 5036 implementations are spread across 1475 different cryptographic primitives, on average just a few implementations per primitive. A typical cryptographic library has new implementations of ML-KEM and ML-DSA that aren't covered by SUPERCOP, and has tests that are much looser than SUPERCOP's tests.
My June 2026 paper on ML-DSA bugs carefully distinguishes the state of the art from typical test practices. For example, in reviewing how the 2017 Dilithium bug happened and how easily it can happen again, my paper says "even though the technology was already readily available before 2017 to test randomness expansion inside cryptographic software, that technology is still far from universally used"; my paper gives concrete examples of what this means and why this gap persists.
Furthermore, some bugs are harder to catch, as illustrated by a May 2026 paper on various ML-DSA bugs that "survive standard testing". In principle formal verification is capable of catching all bugs, and there's even a paper claiming formal verification for some specific ML-KEM software, but the paper reports that—despite cutting corners ("we did not prove correctness of the rejection-sampling routine in the AVX2 implementation")—the verification took "almost three years" of work by a "large number of people". It's not as if typical ML-KEM software is verified, never mind the extra complications of ML-DSA software.
C'mon, this still doesn't pass the laugh test. It's not that bugs and timing leaks are always exploitable, but often they are. Many of the vulnerabilities in cryptographic libraries are severe, including not just things like buffer overflows in high-level TLS protocol handling but also 1 out of every 8 "cryptographic" vulnerabilities.
Even after decades of experience with ECC software, we continue to sometimes see exploitable ECC flaws, such as CVE-2023-6135 in Firefox. ML-KEM and ML-DSA are much newer, and the flaws announced so far are randomly throwing darts at a dartboard obscured in fog; it's not as if we know which parts of the dartboard allow exploits.
I noticed the KyberSlash flaw in mid-December 2023 and promptly announced it, saying that "I'd expect measurable, possibly exploitable, timing variations". The code author replied: "I'm curious, did you check that the code executes in variable time on any particular CPU for the input ranges that are fed into the DIV instruction (if a compiler issues a DIV)?"
I replied with a random example of a CPU with the variations and a test program to verify the variations; but this by itself doesn't imply exploitability. I then looked more closely, and by the end of that month I had posted an exploit demo for KyberSlash. Just before I posted that, another team announced a different division-related timing leak, which I named KyberSlash2, renaming the original as KyberSlash1. We joined forces and wrote a paper that included exploit demos for KyberSlash1 and KyberSlash2 on various devices.
The original Kyber paper in 2017 claimed that its software was "running in constant time, i.e., with protection against timing attacks". But KyberSlash showed that the software didn't run in constant time. The exploit demos then showed that the software was vulnerable to timing attacks. This failure took more than six years to find and fix—not an unusual length of time.
Clangover, a different timing leak triggered by an interaction between the Kyber/ML-KEM code and newer compiler behavior, was announced in 2024 and shown to be exploitable.
I've seen a few companies reacting to these demos by saying things like "We switch to new Kyber/ML-KEM keys more quickly than these demos operate so we're safe". But this is a new security claim that papers haven't looked at. Maybe rapid key rollover stops KyberSlash from being exploited; maybe not.
Optimizing attacks is labor-intensive. Papers on timing attacks and other side-channel attacks typically stop optimizing demos once the demos are fast enough that reproducing them doesn't take painfully long. But sometimes there are papers on "single-trace attacks", such as a paper suddenly showing a 27% success rate in extracting an RSA private key from a single run of OpenSSL's key generation.
Again, it's not that every software flaw is exploitable. But each new flaw in an ML-KEM library is another game of Russian roulette. See also my June 2026 paper explaining how to exploit some types of ML-DSA bugs.
Cryptographic libraries have roughly 1 CVE per 1000 lines of code, with, as I mentioned above, about 1 out of 8 cryptographic vulnerabilities being severe; i.e., there's roughly 1 severe vulnerability per 8000 lines of cryptographic code. A single ML-KEM implementation typically has above 1000 lines of code. Wikipedia lists 18 major TLS libraries and misses many further libraries that support ML-KEM. Clearly some of these libraries will be exploitable, even though we don't know which ones yet.
I think proponents of solo ML-KEM and solo ML-DSA realize how stupid it would sound to claim that the software ecosystems for those won't have any exploitable software flaws.
Instead they switch to highlighting cases where disaster didn't happen. Here's a test that can catch this flaw! Here's a library that didn't have this flaw in the first place! Here's a bug that wasn't an exploitable vulnerability! Here's a library that was exploitable but that we avoided deploying!
Um, okay. Was someone claiming that everything is going wrong everywhere all at once?
The argument for ECC+PQ over solo PQ doesn't claim that PQ software will always be exploitable. It's simply saying that the software will often have flaws, some of which will be exploitable.
Some of the severe vulnerabilities will inevitably become visible in CVEs. Some of the victims will end up looking for accountability. How are the people who endorsed elimination of ECC going to defend themselves? "It's not our fault for removing seatbelts; it's your fault for sitting in a car that crashed"?
Let's look at some actual quotes. Here's an April 2026 claim from Filippo Valsorda: "ML-KEM and ML-DSA are a lot easier to implement securely than their classical alternatives, and with the better testing infrastructure we have now I expect to see exceedingly few bugs in their implementations."
I tried asking how many "exceedingly few" is, and where this number comes from. Valsorda ignored the question. I asked again. He dodged. I asked again. He never replied.
Meanwhile he had responded to my June 2026 paper by excitedly reporting that some of the bugs discussed in the paper can be caught by tests. When I quoted where my paper had already said this, he didn't reply.
For evaluating the security consequences of changing a protocol to allow solo PQ as an alternative to ECC+PQ, we have to look at what PQ software looks like in the real world, not some fantasy world where everybody is using state-of-the-art techniques to ensure software quality. Saying that bugs and timing leaks could have been avoided doesn't change the fact that they often reach deployment.
Another distraction maneuver in the same Valsorda quote is the evidence-free comparison of ML-KEM/ML-DSA software to ECC software: "ML-KEM and ML-DSA are a lot easier to implement securely than their classical alternatives". Similarly, a November 2025 blog post from Sophie Schmieg claims without evidence that "implementationwise, ML-KEM is actually a lot simpler than elliptic curves are"; and a 1 July 2026 message from Mark Schultz-Wu claims without evidence that "lattice-based schemes are much easier to implement than RSA/ECC schemes".
Looking at actual code size in libraries tells the opposite story. Furthermore, the ECC code has had much more time for any problems to be worked out (as Schmieg briefly seems to admit: "we just haven't implemented [ML-KEM] as much as elliptic curves"). This is important for comparisons of bug rates, since each bug has about a 20% chance per year of being discovered.
Maybe AI speedups in discovering code flaws will outweigh AI speedups in producing code flaws. Maybe not. Typical ECC code has in any case already had many years for its flaws to be found and fixed, while typical ML-KEM/ML-DSA code is still in diapers.
More importantly, claiming that ML-KEM software is less likely to be flawed than ECC software simply isn't addressing the argument for using ECC+ML-KEM instead of solo ML-KEM.
Let's say 10% of ML-KEM libraries are exploitable. Many of the users of the exploitable libraries will be rescued by an ECC layer. Suppose someone claims that the ECC layer will be exploitable more often than ML-KEM, let's say 50% of the time, wildly exaggerating the observed ECC exploitability rates. This claim still means that we expect the ECC layer to rescue the other half of the users of the exploitable ML-KEM libraries. This amply justifies keeping ECC; so the claim isn't a counterargument!
PQ software will often have flaws. Some of the flaws will be exploitable. ML-KEM and ML-DSA aren't magical exceptions to this. Proponents haven't disputed these basic facts.
Consider the following quote from Uri Blumenthal:
If your data won’t remain sensitive by the time CRQC arrives - you don’t en need a hybrid. Just use your Classic ECC, experiment with PQ or not, and prepare for eventual transition at some point in the future.
If your data will remain sensitive - then the difference between “it got compromised today” and “it got compromised with CRQC” is small, and ECC won’t help at all.
This is getting away from software issues, obviously, but it still has a big obvious error that the whole audience easily sees, namely the "won't help at all" part at the end. That's outright denial of the value of delaying attacks.
We all agree that users often want data to stay confidential even after quantum computers. Doctors and their patients typically want long-term confidentiality; journalists and their sources typically want long-term confidentiality; et cetera. They want the data to stay confidential this year, and to stay confidential next year, and to stay confidential the year after that, and so on.
What Blumenthal seems to be missing is that each added year of confidentiality adds value. If the users can't get as many years of confidentiality as they want, but still get some extra years because of ECC, great!
Weakening ECC+PQ to solo PQ throws away this benefit. Millions of victims will have their keys exposed immediately to attackers who have found PQ software vulnerabilities, even if the PQ spec remains unbroken.
Think again about what happens when the victims are looking for accountability. Are the people who endorsed elimination of ECC going to defend themselves by saying "We figured that you're aiming for long-term security, and decided that if we're failing to provide long-term security then we might as well give your data away to the attacker right now"?
The funny thing is that the earlier part of the Blumenthal quote is admitting some value in delaying attacks. It isn't claiming that the value is zero; it's claiming that the value is "small". So the full quote isn't even coherent.
The quote has another big problem that I think not as many readers will instantly catch but that's not hard to verify once you're alerted to it. The quote is assuming that, when the attacker has a quantum computer (when "CRQC arrives"), all ECC keys are instantly broken. That's ludicrously far from what all available evidence says.
Here's how I summarized the facts a few days ago in a separate guide: "Obviously what we want to achieve with PQ rollout is having the data protected not just today but far in the future. But, in case we screw that up, ECC adds tremendous value in (1) delaying attacks until attackers have quantum computers, (2) limiting those attacks to the attackers who can afford quantum computers, and (3) limiting the number of broken keys because of the per-key expense of quantum attacks." The Blumenthal quote is overtly denying the value of #1, but it's also ignoring #2 and ignoring #3.
These links are to my June 2026 paper, which in turn reviews available information about these topics. Here are some highlights of the quantification:
I was already on record in 2023, as part of a talk to the Federal Reserve TechLab, estimating a 2029 start date for secret quantum attacks against RSA-2048 (and a 2032 start date for public demos).
IBM in May 2026 announced that it's investing $10 billion in building the first serious quantum computer. Some of that will be non-recurring engineering costs, but probably the quantum computer itself will cost at least $1 billion.
A March 2026 attack paper explains (aside from pointlessly hiding some details that were subsequently reconstructed in public) how a reasonable model of that computer will break about 215 ECC keys per year.
Sure, the cost of quantum attacks will drop. Maybe ten years later $1 billion will pay for breaking 225 ECC keys. But two years ago TLS already used more than 250 ECC keys per year.
I don't mean to endorse ignoring the quantum threat. On the contrary, I coined the phrase "post-quantum cryptography" in 2003 and have been putting a ton of work into the topic since then. I still see some erroneous extrapolations from the fact that decades of development of public quantum computers haven't managed to carry out any useful computations yet; I'm on record critiquing those extrapolations.
But I also don't endorse wild exaggerations of the quantum threat. The attackers who can afford quantum computers in the first place will focus their quantum attacks on what they see as the highest-value targets. That's a disaster for those targets, but this doesn't change the fact that rolling out solo PQ will produce many more broken keys than rolling out ECC+PQ.
Um, how's that supposed to work?
Everyone understands the basic argument that ECC+PQ is safer. For example, if a message has an ECC signature and a PQ signature, with the verifier insisting on both signatures being valid, then the attacker is faced with the problem of forging both. Analogous comments apply to encryption.
This doesn't stop proponents of solo PQ from trying to make ECC+PQ sound scary. But their claims quickly collapse upon examination.
For example, there's a claim that ECC+PQ is so complicated that simply figuring out the details will create security damage through a delay in deployment. You see, there are not just multiple choices of PQ systems, but also multiple choices of ECC systems—and even multiple choices of how to put them together. For example, you could sign a message with ECC and with PQ, or you could first sign with ECC and then sign the message and ECC signature with PQ, among other possibilities. Similarly, there are multiple options for KEM combiners.
So many options! This is like reading an entire menu at a Chinese restaurant! It'll take us years to figure out what to order!
The aforementioned posting from Valsorda claims that using ECC+PQ will "slow us down". John Mattsson claims that this will "significantly delay PQC migration, to the extent that industry would miss European 2030 deadlines". Wow, that does sound scary!
But wait a minute. Cloudflare had already reported in September 2025 that its incoming post-quantum HTTPS connections were "about 95% X25519MLKEM768 and 5% X25519Kyber768Draft00. There is a sliver (~0.01%) that advertises support for pure ML-KEM (which we don't support), mostly together with X25519MLKEM768. That's about the same number as CECPQ2. P256MLKEM768 is even lower". At that point Cloudflare was also reporting that these post-quantum connections had already reached half of Cloudflare's incoming HTTPS connections. As context, Cloudflare says that it runs something like 20% of the Internet's web sites.
If picking an ECC+PQ system is supposed to be so complicated compared to picking a PQ system, how did this broad rollout of ECC+PQ happen?
Answer: People just picked the ECC system that the "vast majority" of TLS sessions were using already, namely X25519. They also picked the first "+" mechanism that comes to mind, namely concatenation of the PQ output with the X25519 output; simple concatenation is just fine for TLS. Done.
Supporting other existing ECC options is similarly easy. The IETF-approved spec for ECC+ML-KEM in TLS includes three options: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024. Each of these is just a few lines of code to write and test on top of the ECC software (which is sitting around in TLS software already) and the ML-KEM software (which would also be part of solo ML-KEM).
As a side note, this hasn't stopped proponents from waving at those few lines of code and claiming that we should worry about the possibility of bugs there. Consider, for example, the aforementioned message from Schultz-Wu: "I’ve seen some people point towards the 'glue code' to create the hybrid as being plausibly its own source of implementation issues."
Sure, there can be bugs in that code. However, as I wrote in my separate guide: "This integration is just a few lines of code. Those lines reduce the damage from bugs and other security problems in many more lines of code for ML-KEM. It makes absolutely no sense to use the possibility of bugs in a few lines of code as an argument to skip mitigations for bugs in many more lines of code."
At the beginning of 2024, I blogged about the risks of solo PQ, including the damage caused by bugs in "new code for whichever KEM—let's call it UltraKEM". I explained why this risk is smaller than the risk of a "hybrid reversal" in which X25519+UltraKEM ends up less secure than solo UltraKEM because of a "program-partitioning disaster in the X25519 software, such as an exploitable buffer overflow" or "some similarly devastating bug in the lines of code for the hybrid hash, such as omitting the UltraKEM session key from the hash input". The important points are as follows: the UltraKEM software is newer than the X25519 software and will have more bugs; X25519 bugs typically won't be program-partitioning disasters; the hybrid hash is very little code.
Similar comments apply to signatures. My June 2026 paper quantifies a risk comparison for Ed25519 and ML-DSA; this includes accounting for the possibilities of Ed25519 buffer overflows and ML-DSA buffer overflows, along with other types of vulnerabilities. Even years after the first quantum attacks, Ed25519+ML-DSA will give away far fewer keys than solo ML-DSA. This conclusion is robust against changes in the underlying numbers, such as the rate of buffer overflows.
A specification of ECC+PQ signatures for TLS was already drafted in 2024. The TLS WG chairs promised in February 2025 that they would call for WG adoption of that document—but then they never followed through. The reason that Google, Microsoft, Mozilla, Akamai, etc. didn't enable ECC+PQ signatures in browsers and typical servers at that point isn't because of them being idiots unable to get ECC+PQ working; it's because they made a business decision to delay deployment of any post-quantum signatures in TLS, independently of the choice between ECC+PQ and solo PQ. Sometimes they were even public about this—look, for example, at Mozilla advocating delay in all "signature modes" and then saying that post-quantum signatures were addressing a "more speculative" threat than "store and decrypt"—but ultimately what matters is that they didn't roll anything out.
For KEMs, the situation is even easier to see, since ECC+PQ has already been deployed. More deployment is needed, but allowing ECC+PQ to be weakened to solo PQ won't do anything to accelerate PQ deployment: any new TLS implementation supporting just solo PQ and not ECC+PQ would fail to establish PQ connections with peers that reject solo PQ. So, no, insisting on ECC+PQ obviously isn't causing a delay. ECC+PQ is rescuing millions of users from PQ security failures—not just the possibility of security failures in PQ specs but the definite reality of vulnerabilities in PQ software.
This one would at least sound like an answer for the victims: "Yes, we knew that rolling out solo PQ would create security failures for millions of users, failures that would have been avoided by ECC+PQ. But we were just barely able to afford solo ECC before that, and we were just barely able to afford solo PQ. We simply couldn't afford to roll out ECC+PQ."
C'mon, do they think we're unable to check the costs? The smallest ML-KEM option, ML-KEM-512, has 800-byte keys and 768-byte ciphertexts. X25519 adds 32 bytes and 32 bytes respectively.
More broadly, the total costs of X25519, including computation and communication, are negligible compared to just the communication cost of ML-KEM-512, never mind the total costs of an application such as TLS. Same story for Ed25519 vs. ML-DSA.
I commented on this in my separate guide in the context of TLS: "Looking at the numbers shows how difficult it is to argue that TLS can afford solo PQ but can't afford ECC+PQ. If anyone had found even a single verifiable example of a TLS application in that situation, we would have been hearing endless references to that example by now, rather than hearing one unfounded insinuation after another."
In February 2026, Paul Wouters claimed that he was "asked by a TLS participant to relay some information publicly regarding their pure PQ mlkem use case", this supposed "use case" being "the market of high-frequency trading", where the "performance drop" of ECC+PQ would supposedly mean that "the traders will insist on waiting until a CRQC is publicly known to exist" while the performance win of solo PQ would supposedly make "a strong case to deploy PQ security".
There were eight followup messages, all sent promptly. Two were pointing out problems with allowing anonymous inputs to the TLS WG. One was Blumenthal issuing his own support statement for solo PQ, without making any comments on high-frequency trading. The other five were pointing out severe flaws in the Wouters story: most obviously, the costs of using ECC+PQ to establish a session before the trading day begins have zero effect on trading latency. Wouters didn't retract the story—nor did he make any attempt to defend it; he simply didn't respond.
ML-KEM software will often have flaws. Some of the flaws will be exploitable. Keeping ECC as part of ECC+ML-KEM, rather than using solo ML-KEM, reduces the damage done by those vulnerabilities. The costs of ECC are easily affordable compared to the costs of ML-KEM, so there's no excuse for throwing ECC away.
Similarly, ML-DSA software will often have flaws. Some of the flaws will be exploitable. Keeping ECC as part of ECC+ML-DSA, rather than using solo ML-DSA, reduces the damage done by those vulnerabilities. The costs of ECC are easily affordable compared to the costs of ML-DSA, so there's no excuse for throwing ECC away.
Finally, please note that you can still speak up for the next few days in IETF's current vote on whether to endorse solo PQ.