Skip to content
Tech News
← Back to articles

Bugs happen: The easy way to compare solo PQ to ECC+PQ

read original more articles
Why This Matters

This article highlights the critical importance of maintaining ECC alongside post-quantum cryptography (PQC) to prevent catastrophic security failures caused by bugs in PQ software. Relying solely on PQ without ECC introduces unnecessary vulnerabilities, especially given the current state of PQ software development, which is prone to flaws. Preserving ECC as a layered defense offers a more resilient and cost-effective approach to future-proofing cryptographic systems for consumers and the tech industry alike.

Key Takeaways

The cr.yp.to blog

2026.07.04: Bugs happen: The easy way to compare solo PQ to ECC+PQ. #pqcrypto #bugs #vulnerabilities #hybrids

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:

PQ software will often have flaws.

Some of the flaws will be exploitable.

Keeping ECC as part of ECC+PQ, rather than using solo PQ, reduces the damage done by those vulnerabilities.

The costs of ECC are easily affordable compared to the costs of PQ, so there's no excuse for throwing ECC away.

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:

... continue reading