Filippo Valsorda writes:
> You are characteristically cherry-picking quotes from other venues,
> drawing false comparisons, and then demanding explanations.

Sorry you feel that way. I'm actually trying to understand concretely
what you mean in claiming that there will be "exceedingly few bugs" in
ML-DSA software.

https://cr.yp.to/papers.html#mldsa includes detailed, quantified
estimates of the rate of bugs and the rate of severe vulnerabilities. It
explains where the numbers come from. The resulting graph---

    https://cr.yp.to/papers/mldsa-20260601.pdf#breakable-keys

---says that rolling out solo ML-DSA will result in far more breakable
keys than rolling out Ed25519+ML-DSA, even years after the first quantum
attacks. Solo ML-DSA is thus unacceptable from a security perspective.

This conclusion is robust against uncertainties in the underlying
numbers. _However_, the analysis would break down in the extreme
scenario that the entire ML-DSA software ecosystem has a total of _zero_
severe vulnerabilities.

I don't think this scenario is even remotely plausible given the
evidence collected in my paper. However, _if_ there's a claim that we're
in that scenario, then I'd like to understand the rationale. Maybe
"exceedingly few bugs" is meant to claim zero bugs---or, more to the
point, zero severe vulnerabilities---but this isn't clear, so I'm asking
for clarification.

Imagine a severe vulnerability being found in an ML-DSA implementation
in, say, 2027 (out of a larger number of ML-DSA bugs), breaking many
ML-DSA keys---obviously breaking far fewer Ed25519+ML-DSA keys---and
showing that I'm right. Does this contradict "exceedingly few bugs"?
Would 10 severe vulnerabilities contradict "exceedingly few bugs"?

If the claim isn't that there will be _zero_ severe vulnerabilities,
then I'm baffled at what the rationale is supposed to be for "we should
go straight to pure ML-DSA-44", especially given that "a single broken
key per month can be catastrophic".

You spoke up in favor of this solo ML-DSA spec in the TLS WG, and when I
looked for your rationale I found your posting with all of these quotes,
so I don't understand what your concern is regarding venue.

> there is now a > 1% chance of
> Ed25519/ECDSA/RSA being broken by a QC before 2030

To be clear, I'm not disputing that---except for the word "now" and
concretely the claim that "no one had set such an aggressive timeline
until this month". My 2023 talk to the Federal Reserve TechLab had a
median prediction of 2029 for a secret quantum break of RSA-2048:

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

It also had an easier-to-test median prediction of 2032 for a _public_
quantum break of RSA-2048. I was already saying 2032 for this years
before that talk.

The reason that improved quantum attacks didn't force revisions to my
predictions is that I was carefully modeling the rate of improvements
from the outset. More details on this are explained in my paper:
https://cr.yp.to/papers/mldsa-20260601.pdf#timeline

Note that I'm separately disputing your claim that the value of ECC is
at most "before the CRQCs come". Your claim ignores the cost of quantum
attacks. See generally https://cr.yp.to/papers/mldsa-20260601.pdf#ecc
and specifically https://cr.yp.to/papers/mldsa-20260601.pdf#eccdenial.

> I do stand by my assessment that the risk of ML-DSA forgeries (due to
> bugs or cryptanalysis) is smaller than that of Ed25519/ECDSA/RSA
> forgeries (due to bugs or quantum computers) or composites forgeries
> (due to bugs or due to their rollout being slower than quantum
> computers).

Sorry, can you please quote your assessment of the forgery-via-bug risks
of ML-DSA vs. ECC+ML-DSA? I don't see it.

I saw your claim that ECC+PQ "will only slow us down", and your citation
of a blog post making claims about cryptanalytic risks, but I'm asking
about the "due to bugs" parts.

I did see a claim that "ML-KEM and ML-DSA are a lot easier to implement
securely than their classical alternatives". This claim is unexplained
and seems impossible to reconcile with the extensive evidence presented
in my paper, but _even if this claim is true_ it's a claim about bug
risks of ML-DSA vs. ECC, not of ML-DSA vs. ECC+ML-DSA.

In, say, 2027, maybe an attacker breaks an ECC+ML-DSA key because of an
exploitable bug in the ECC part _and_ an exploitable bug in the ML-DSA
part, but this _combination_ of failures will be much less likely than
an exploitable bug in _just_ the ML-DSA part. My paper estimates rates
of some other failure modes (e.g., maybe an ML-DSA buffer overflow lets
the attacker skip breaking ECC), but in the end ECC+ML-DSA is still
rescuing a ton of keys for which ML-DSA is broken. I don't see where
you've given any assessment of this.

> You are also not engaging with the parts of the conversation that
> don't suit your narrative, so this is not helping anyone, and this
> will be my last reply. I do have one final question: are you going to
> publish a retraction of your statements on the applicability and
> availability of Project Wycheproof test vectors, now that they were
> shown to be factually inaccurate?

I stand by what I wrote.

My paper emphasizes the gap between state-of-the-art tests and typical
tests. My paper gives concrete examples of real-world programming (e.g.,
typos; copy-and-paste with inadequate edits; people not having heard
about powerful, easy-to-use types of tests that have been available for
years), and looks at Wycheproof with this explicit mindset:

> > 3.2 How easily these bugs can pass common types of tests ...
> > 
> > 3.2.5. More examples of inadequate usage of known-answer tests. I
> > have looked at test suites in many more libraries, typically finding
> > tests that are far less stringent ...
> > 
> > Part of the supplement [31] to this paper is a Sage implementation
> > of ML-DSA. Except for adding Sage adaptations of the bugs exploited
> > in this paper's demos, I tried to do what I would expect typical
> > ML-DSA programmers to do if they were asked to use Python or Sage ... 
> > 
> > I then looked at the ML-DSA known-answer tests in Wycheproof [58].
> > Each signing test provides a key pair, a message, this hash mu, and
> > a signature. It seems that the intention is to have a signature
> > function taking the key pair, a message, and mu as input, but this
> > doesn't obviously match any of the interfaces that I noticed in FIPS
> > 204 or that I included in my Sage script. ... I don't think I was
> > being obtuse here; I think many ML-DSA programmers will end up
> > skipping the signing tests from [58] even if they've heard about
> > those tests.

You say that various ML-DSA bugs would be caught by known-answer tests
if the tests were applied properly. My paper already says this (while
also noting various failure modes for it, such as [87] and [85]): see
in particular https://cr.yp.to/papers/mldsa-20260601.pdf#checksums and
https://cr.yp.to/papers/mldsa-20260601.pdf#python-kats.

You portray this as contradicting what I'm saying about Wycheproof. No,
there's no contradiction. My paper is completely explicit in switching
from various tests that I recommend to a separate subsection regarding
"tests that are far less stringent" and "what I would expect typical
ML-DSA programmers to do".

The look at Wycheproof concluded "I think many ML-DSA programmers will
end up skipping the signing tests". See the word "many"? This is not a
statement about what's _possible_ with the tests; it's saying that the
tests often won't even be used.

As for keygen, I'm confident that typical programmers finding the
mldsa_44* files inside Wycheproof---namely "mldsa_44_sign_noseed_test"
and "mldsa_44_sign_seed_test" and "mldsa_44_verify_test"---will conclude
that the tested operations are sign and verify, not keygen.

Why is it important to distinguish between state-of-the-art testing and
typical programmer behavior? Remember the point of this discussion:
there's a proposal on the table for IETF to endorse solo ML-DSA.

I say that there will be severe ML-DSA software vulnerabilities allowing
low-cost forgeries for many solo ML-DSA keys. This is a statement about
the actual Internet-wide software situation, not about some selected
high-assurance fragment. "IETF participants use their best engineering
judgment to find the best solution for the whole Internet, not just the
best solution for any particular network, technology, vendor, or user."

For each severe ML-DSA vulnerability announcement, some libraries will
respond by issuing happy announcements saying "Our library was safe
against this type of bug because of the following assurance practices";
good for those libraries! But many users are still screwed.

Far fewer ECC+ML-DSA keys will be broken. The extra costs of ECC+ML-DSA
are negligible compared to solo ML-DSA. ECC is sitting there anyway. The
added computation _and_ communication costs of ECC are negligible
compared to just the communication costs of ML-DSA, never mind total
application costs.

It's circular for proponents of solo ML-DSA to slow down endorsement of
ECC+ML-DSA and then use this slowdown as an argument in favor of solo
ML-DSA. From a security perspective, solo ML-DSA has to be thrown away
in favor of ECC+ML-DSA.

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