Nadim Kobeissi writes:
> But you're shifting the goalposts.

No, I'm not. See, e.g.,

    https://web.archive.org/web/20260603074058/https://mailarchive.ietf.org/arch/msg/spasm/pcISUlnedpExwwLuISP18oR1zxc/

for a 2024 posting where I emphasized how the risks of "bugs in
post-quantum software" warrant "a blanket rule of always upgrading from
ECC to PQ+ECC, _not_ discarding the ECC layer, even when the PQ layer is
SPHINCS+" (which is the most conservative signature system).

In the same posting, I explained the difference between state-of-the-art
bug elimination and what happens in the real world. What my new paper is
doing is adding quantification of bug rates and exploitation costs in
the case of ML-DSA, culminating in a concise graph

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

with estimates for the number of breakable keys; but conceptually this
is the same point I've been making for years.

> First, it was: "we don't know if
> ML-DSA is a mature or sufficiently studied cryptographic design."

This quote (which is not from me) downplays (1) the instability of
lattice security levels and (2) the further risks that come from the
ML-DSA attack surface _beyond_ general lattice attacks. My new paper
cites some examples of broken lattice systems and recent attack
advances: see https://cr.yp.to/papers/mldsa-20260601.pdf#mathdenial.

The explicit reason that my new paper focuses primarily on bugs,
omitting the risk of spec breaks from the estimates of the number of
breakable keys, is that we _know_ bugs will happen. Even if the ML-DSA
spec's security level someday stabilizes without much more security loss
compared to today, we will see severe vulnerabilities in ML-DSA
software---which will produce many more breakable ML-DSA keys than
breakable ECC+ML-DSA keys.

Here are the main steps in how my paper quantifies this:

    * The 2021 Blessing--Specter--Weitzner study found that NSS added a
      CVE for each ~2200 lines of added code; that OpenSSL added a CVE
      for each ~840 lines of added code; that about 1/3 of CVEs across
      OpenSSL, GnuTLS, NSS, Botan, Libgcrypt, wolfSSL, LibreSSL, and
      BoringSSL were severe; and that about 1/8 of "cryptographic" CVEs
      were severe.

    * In, e.g., OpenSSL the software for the ML-DSA primitive per se
      has 2331 lines of portable code plus 1360 lines of Perl generating
      AVX2-optimized NTT code. There are many more ML-DSA libraries, and
      one expects roughly 1/4 of them to have severe vulnerabilities,
      given the data regarding previous cryptographic CVEs.

    * My paper systematically analyzes various reasons that one might
      optimistically hope for ML-DSA code to avoid bugs, or to avoid
      vulnerabilities, or to avoid severe vulnerabilities. The paper
      goes through examples of the endless bug opportunities for ML-DSA,
      presents fast exploit demos for two examples, and looks at the
      bugs that we've already seen in real software---including one of
      the targets of the exploit demos.

    * My paper also quantifies how many ECC keys will be breakable by
      quantum computers and through ECC software vulnerabilities.

Quoting Section 1: "The main conclusion is that far fewer Ed25519+ML-DSA
keys will be breakable than ML-DSA keys, not just before the first
quantum attack but also continuing for years after the first quantum
attack. This conclusion is robust against uncertainties in the
underlying numbers, such as bug rates."

> I'm pretty sure that there's some nineteen year old kid somewhere
> writing his first ML-DSA implementation in JavaScript

That's not a reasonable characterization of the libraries with CVEs or
other bugs announced in 2026 so far for Dilithium/ML-DSA code:

    * libgcrypt (CVE-2026-41990),
    * wolfSSL (CVE-2026-3503 plus eprint 2026/1032),
    * RustCrypto (CVE-2026-22705 plus CVE-2026-24850), and
    * libcrux (the two bugs pointed out in your paper).

Appendix B of my paper explicitly discounts CVEs that mention ML-DSA but
are actually in other code, such as CVE-2025-15469 (announced in 2026),
in which "The 'openssl dgst' command-line tool silently truncates input
data to 16MB when using one-shot signing algorithms and reports success
instead of an error". But this CVE, like many others, illustrates that
cryptographic libraries have a long way to go in quality assurance.

> It's never been my opinion that ECC+ML-DSA is bad or undesirable. My
> opinion is that it's *just not worth it*. You'd need to add
> hybridization scaffolding for signatures, something which currently
> doesn't exist and isn't even specified, across every single TLS
> implementation.

Huh? I'm saying solo ML-DSA causes definite security damage compared to
ECC+ML-DSA. See https://cr.yp.to/papers/mldsa-20260601.pdf#breakable-keys
for quantification of the number of breakable keys. If you're not
disputing this damage, how do you claim that ECC+PQ is "not worth it"?

As a factual matter, there's already a spec. The added combiner code
(sign twice, make sure both verify) needed per implementation is much
smaller than the added ML-DSA code needed per implementation.

> the implementations that matter (i.e. whatever all major web browsers
> and web servers use)

Are you sure you aren't underestimating the software diversity of web
servers? See, e.g., the range of software listed in some TLS CVEs:

    https://cr.yp.to/papers/pqconnect-20241206.pdf#page.1

The damage done if IETF endorses solo ML-DSA in TLS includes a long tail
of security problems that will take many years to clean up, very much
like the damage done by IETF endorsement of RSA-512 and DSA-512 a long
time ago:

    https://publish.illinois.edu/science-of-security-lablet/files/2016/08/10062016-Heninger-Slides.pdf

I'm horrified at the notion that the only damage we're concerned with is
damage to Google etc. This violates an IETF principle that was quoted as
"fundamental" in

    https://www.ietf.org/blog/ietf-llc-statement-competition-law-issues/

namely: "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."

> I don't think that ECC implementations are somehow less likely to have
> bugs or are less in need of best practices and tons of testing!

See https://web.archive.org/web/20260603090502/https://mailarchive.ietf.org/arch/msg/last-call/0TJ297MxKhTJ4gonXr2H86xLi-8/
for three quotes from my paper explaining flaws in this argument.

In short: (1) My paper shows that the usual ECC bugs have ML-DSA
analogues, while the opposite isn't true. (2) ECC code is typically much
older than ML-DSA code, so each ECC bug is more likely to have been
eliminated. (3) Claiming that ML-DSA would have as few keys broken as
ECC doesn't change the fact that ECC+ML-DSA will have fewer keys broken.

> The right thing to do right now is to improve our best practices and
> make sure they reach as many implementations as possible

Sorry, did I miss someone arguing _against_ better testing? My paper
gives concrete examples of how unsatisfactory current testing is, and
recommends various improvements.

> Dan, why don't you for example try to contribute tests and other such
> artifacts to projects like Wycheproof,

Wycheproof has been around for a decade. It added ML-DSA tests a year
ago. Nevertheless various CVEs appeared in 2026 for released ML-DSA
software. How do you explain that?

Here's my explanation: The bug coverage in Wycheproof is very far from
comprehensive, as illustrated by bugs often leading to patches not just
in buggy libraries but also _patches in Wycheproof_. Furthermore, people
writing ML-DSA software often don't end up using Wycheproof, either
because they didn't hear about it or because they have trouble using it.
Furthermore, we're starting to see timing attacks in ML-DSA CVEs, and
addressing those definitely needs more than just test vectors.

I prefer to put most of my testing efforts into more advanced test
mechanisms that systematically cover larger classes of software flaws
and are easier to scale to large volumes of code.

I don't mean to criticize people who are writing tests for specific
bugs---I sometimes write those types of tests too. But there's a
tradeoff between spending time on addressing specific bugs and spending
time on addressing the underlying systemic issues.

> or if you're like me and prefer
> to work alone, publish your own guidelines for ML-DSA best practices,
> or even write your own ML-DSA implementation that you consider to be a
> gold standard in terms of implementation quality and correctness for
> others to emulate?

The core reason is that I see one application after another where KEMs
are a better choice than signatures for authentication. We're using KEMs
anyway for encryption, so eliminating signatures gets rid of a bunch of
unnecessary risks in these applications. So I'm looking mainly at KEMs
and symmetric cryptography. Here's an example of production code that I
released a few months ago for an important subroutine, so you can get an
idea of what I think is a reasonable level of quality assurance:

    https://sorting.cr.yp.to

Obviously signatures are important for _some_ applications, such as
offline code signing. But offline code signing can trivially afford
SPHINCS+. Security is a higher priority than efficiency.

What about applications that need offline signatures _and_ really can't
afford SPHINCS+? There's XMSS and smaller variants of SPHINCS+. State
management and limits on the number of signatures are risky, but not as
risky as ML-DSA.

Maybe the ML-DSA picture settles down to something comfortable at some
point. But then why would people not end up using one of ML-DSA's
smaller successors, such as HAETAE? Is the cliff supposed to stop
crumbling with ML-DSA exactly at the edge, the smallest unbroken
lattice-based signature system? Seems implausible.

Anyway, obviously publishing ML-DSA best practices and high-quality
ML-DSA code isn't going to instantly eliminate ML-DSA bugs from the
software ecosystem. In software more broadly, there's a long history of
best-practices documents and high-assurance software, and yet _typical_
software is full of bugs.

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