Filippo Valsorda writes:
> These bugs are so easy to find

The CVE-2026-24850 bug ("the ML-DSA signature verification
implementation in the RustCrypto 'ml-dsa' crate incorrectly accepts
signatures with repeated (duplicate) hint indices") was so easy to find:
just try a fuzzer. So why wasn't it found before release?

The CVE-2026-22705 timing leak ("a timing side-channel was discovered in
the Decompose algorithm which is used during ML-DSA signing") was so
easy to find: just run standard constant-time checkers. So why wasn't it
found before release? (Btw, maybe this one is exploitable, but my paper
explicitly presumes unexploitable since there's no analysis.)

The CVE-2026-41990 bug ("Libgcrypt before 1.12.2 mishandles Dilithium
signing. Writes to a static array lack a bounds check but do not use
attacker-controlled data") was so easy to find: just try a fuzzer. So
why wasn't it found before release?

The "previous" vs. "current" bug in Cryspen's "verified" ML-DSA software
was so easy to find: just try a fuzzer. So why wasn't it found before
release? (Btw, anyone claiming that signature malleability is severe has
to count this bug as severe.)

Both of the official Dilithium 1.0 implementations submitted to NIST
were vulnerable (and, as my paper shows for an analogous bug in
Dilithium 3.4 = ML-DSA, exploitable in under 1 second on 1 core). This
bug was so easy to find: just check KATs against a Python translation of
the spec. So why wasn't it found before release?

Et cetera. My paper is looking at the real world, not at some fantasy
world where every bug that could easily have been caught _is_ caught.
Cryptographic deployments use a wide range of libraries with a wide
range of testing practices; saying that better tests exist is really
missing the point.

Most Dilithium software is new, so the CVEs are just getting started,
and trying to extrapolate from those would obviously be error-prone. But
this extrapolation is what you're doing in emphasizing the small number
of severe vulnerabilities found so far.

My paper instead uses the normal technique of measuring ML-DSA software
complexity to predict ML-DSA bug rates. My paper also looks much more
closely at some structural aspects of ML-DSA software that make a wide
range of ML-DSA bugs likely to evade typical tests. The word "typical"
is important; again, saying that better tests exist misses the point.

You claimed that there are going to be "exceedingly few bugs" in ML-DSA
software. How many is "exceedingly few"? Where do you get this number
from? If there's no specific number that would disprove the claim, then
the claim is content-free, so why are you advocating decisions on the
basis of the claim?

As for severity, a 2021 study of cryptographic libraries found that
about 1/8 of cryptographic CVEs are severe. Are you claiming that ML-DSA
CVEs will end up with a lower severity rate than that? Why? How low?

In the same posting, you wrote that "a single broken key per month can
be catastrophic" and that a disaster chance above 1% is unacceptable
since "you are betting with your users' lives". Are you claiming that
the chance of a severe ML-DSA software vulnerability is below 1%?

---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.

IESG claims that the "explicitly disallowed" provision in BCP 78 is
limited to the examples in Section 3 in BCP 78. That is incorrect. BCP
78 states that Section 5, "Rights in Contributions", is normative, while
Section 3, "Exposition of Why These Procedures Are the Way They Are", is
informative. The opt-out provision in the normative text is clear, and
cannot be limited by an informative section. BCP 78 does not give IESG
any authority to issue changes or purported clarifications of the rules.

Rationale for exercising the BCP 78 opt-out provision: I'm fine with
redistribution of copies of this document. The issue is instead 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. This goes far beyond what
copyright law allows as fair use (such as giving quotes for purposes of
commentary). When I complained about the mangled document, the IETF
Executive Director responded not by apologizing but instead by asserting
that IETF management "has a license" to do anything it wants.