Viktor Dukhovni writes:
> The risk is therefore, that at some point the algorithm can be broken
> by *anyone*, not just NSA.

Anyone who figures out how to break it and has the resources to do so,
yes. That's just like DES, which NSA publicly claimed to be secure but
secretly ensured was "weak enough to still permit an attack" (NSA's
words), simply by limiting the key size to 56 bits. RSA-512 is another
example of a breakable algorithm that NSA promoted to the detriment of
general public security for many years.

The Carter administration found it "intolerable" for communications
security to be provided by "an Agency which had signals intelligence as
its primary mission". These quotes are directly from the NSA director
complaining about this at that time.

You seem to be claiming that NSA's primary mission isn't attack but
rather defense---that if there's a tension between these then NSA will
prioritize defense. Where do you get this idea, and how do you explain
the contradiction with "signals intelligence as its primary mission"?

You conclude that NSA wouldn't push for vulnerabilities that might be
exploited by, say, the Russian government. How, then, do you explain
NSA pushing 56-bit DES, RSA-512, 40-bit RC4, DSA-512, etc.?

If your answer is that NSA magically turned into the good guys after
these examples: What's the mechanism that could plausibly have made this
happen, what's your evidence that it did happen, and how do you explain
https://www.eff.org/files/2014/04/09/20130905-guard-sigint_enabling.pdf
in 2013 documenting a massive NSA sabotage budget?

> including the US government

NSA publicly said it was going to use DES for itself, so your argument
concludes that NSA thought DES was safe. But this is again contradicted
by NSA secretly writing that DES was "weak enough" to break.

See https://blog.cr.yp.to/20251004-weakened.html#dogfood for quotes,
links, and further analysis of this argument.

  [ describing a potential view of ECC "failure": ]
> significant probability, much higher than that of ML-DSA failure.

That's the wrong comparison on two levels.

First, risk comparison has to look at not just probability but impact.
For example: https://arxiv.org/abs/2603.28846 shows that a plausible
model of a not-many-years-from-now quantum computer will be able to
break about 2^15 ECC keys per year. That's very bad for those keys,
times the number of quantum computers that the attacker can afford at
that point, but it's still far smaller than the number of PQ keys that
one would expect to be broken via a single PQ software bug.

Second, the relevant security comparison is not between PQ and ECC, but
between PQ and ECC+PQ, two similar-cost options that both provide the
same basic feature of _trying_ to protect against quantum computers.
The basic advantage of ECC+PQ is that, even when the PQ key is broken,
the ECC key will often save the day. Let's say

    * the PQ key is broken with probability q, and
    * for broken PQ keys the ECC key is broken with conditional
      probability p, saving the day with conditional probability 1-p;

then ECC+PQ keys are broken with overall probability only pq, which is
much smaller than q for most possible (p,q) pairs.

Hypothesizing that p is larger than q, or even much larger than q, is
missing the point. For example, imagining that p = 1/100 and q = 1/10000
means that 1 out of every 10000 PQ keys is broken while only 1 out of
every 1000000 ECC+PQ keys is broken, making ECC+PQ a vastly better
option (100x less damage at similar cost). Saying that ECC is more
likely to fail than PQ in this scenario is irrelevant to the conclusion
that ECC+PQ is by far the best choice.

To imagine that q is only negligibly different from pq, one would have
to make the wild claim that q is negligible or the wild claim that 1-p
is negligible; basically, that every PQ key is safe, or that every ECC
key is broken. Those scenarios aren't inconceivable, but competent risk
management also considers other scenarios.

> If CrQCs take much longer to appear than recent (circa 2029) speculative
> timeframes suggest, and in that extended timeframe ML-DSA falls to novel
> cryptanalysis, you'd be proved right.

Huh? My 2023 quantum-risk-assessment talk for the Federal Reserve
TechLab gave a median estimate of 2029 for secret quantum attacks
breaking RSA-2048 and a median estimate of 2032 for public demos:

    https://cr.yp.to/talks/2023.06.15/slides-djb-20230615-pqrisk-4x3.pdf#page.10

I pointed out two "common mistakes analyzing this risk", one being
"assuming attackers aren't ahead of us", the other being "watching
advances in #qubits and in qubit error rates but not in algorithms".

I was already on record long before 2023 estimating the same 2032 for
public quantum attacks. The mechanisms I use to predict development
speed haven't needed any radical adjustments. The only reason that

    https://cr.yp.to/talks/2017.09.20/slides-djb-20170920-quantum-4x3.pdf

says 2033 rather than 2032 is that Latincrypt is every second year.

Here in 2026, the latest improvements in algorithms seem to have
triggered a stampede of people screaming things like "PANIC! Nobody
expected this" and "Quantum FUD has been around for decades BUT NOW IT'S
REAL AND THE APOCALYPSE IS SCHEDULED FOR 2029" and "Protect yourself
RIGHT NOW by injecting bleach".

I don't find it surprising that a failure to pay attention leads to a
bipolar switch from unjustified exaggerations in one direction ("quantum
computers aren't a real threat") to unjustified exaggerations in the
opposite direction ("ECC is useless"). But I would think that someone
saying "We told you for many years to trust cryptosystem X, but, oops,
it's actually giving away all your data; please panic right now" would
realize how crazy it sounds to follow up by saying "We're telling you to
trust cryptosystem Y". What happens if Y fails too?

We have ECC sitting around already. Double signatures with ECC+PQ are,
internally, continuing to sign with ECC _and_ signing with PQ, so that
many different types of potential PQ failures still face the attacker
with the problem of breaking an ECC key. This has the same easy external
interface as removing the ECC part (contrary to various claims that
suddenly appeared on the TLS mailing list during WGLC and that still
haven't been retracted---Mike Ounsworth commented that there's a "crazy
amount of mis-understanding of composites on display here"), and it has
negligible extra cost. This core argument for ECC+PQ is _not_ dependent
upon any guesses for when the first quantum computers will appear.

---D. J. Bernstein


===== NOTICES =====

IETF BCP 78, "Rights Contributors Provide to the IETF Trust", Section 5
(normative), "Rights in Contributions", provides a modification right
"unless explicitly disallowed in the notices contained in a Contribution
(in the form specified by the Legend Instructions)".

The official language from IETF's "Legend Instructions" for the
situation that "the Contributor does not wish to allow modifications nor
to allow publication as an RFC" is as follows: "This document may not be
modified, and derivative works of it may not be created, and it may not
be published except as an Internet-Draft."
<https://trustee.ietf.org/wp-content/uploads/Corrected-TLP-5.0-legal-provsions.pdf>

The same language is used in, e.g., RFC 5831. The same language hereby
applies to this document. This is not disclaiming or limiting the
applicability of IETF policies; it is strictly following IETF policies.

Rationale: I'm fine with redistribution of copies of this document. The
issue is with modification, such as (1) IESG's May 2025 posting of an
IESG-mangled version of an appeal that I had filed and (2) IETF
management selling IETF mailing-list text to AI companies.