This message addresses, in no particular order, various claims that have
shown up on the last-call mailing list regarding this spec. Surely these
disputes should be resolved.

> If quantum attack against first algorithm is much cheaper than
> attacking the second algorithm, then the second algorithm is the
> bottleneck and adding the first to composite does not improve security.

The problem with this argument isn't in the logic but in the hypotheses,
which (1) ignore the literature estimating the cost of quantum attacks
against ECC and (2) ignore the risk of cheaper attacks against ML-DSA.

My new paper https://cr.yp.to/papers.html#mldsa goes through some of the
endless bug possibilities in Dilithium software, including quite a few
bugs already _found_ in released software, including some vulnerability
announcements. For example, the official Dilithium 1.0 implementations
had a severe vulnerability, which I've now shown is also an easy mistake
to make for Dilithium 3.4 (ML-DSA) and is very efficiently exploitable.

There's now a huge pile of new ML-DSA code being rushed out the door in
a panic, certainly with many bugs. My paper uses standard techniques to
estimate the rate of severe vulnerabilities. Many more solo ML-DSA keys
will be breakable than Ed25519+ML-DSA keys---even years after the first
quantum attacks. This is explicitly _ignoring_ the risk of severe breaks
of the ML-DSA spec; it's simply looking at the security damage that will
be caused by the predictable flood of bugs in ML-DSA software.
 
> For TLS, deterministic versus hedged ML-DSA does not matter

Actually, it does. The default randomized ("hedged") ML-DSA option will
often deter libraries from carrying out known-answer tests for signing,
as https://cr.yp.to/papers/mldsa-20260601.pdf#coefftest explains in
detail. This will increase the bug rate. Bugs have an important impact
on the real-world security of TLS, as we've seen many times.

> it should already be clear-cut to absolutely everyone at this very
> late stage that humans in CFRG and/or on the Crypto Review Panel will
> be fundamentally incapable of providing anything novel or useful to
> say on the cryptography (any such information is already completely
> present in public discussion, and the odds of someone in these groups
> having something novel to introduce that they've held back all this
> time is *somewhat noticeably lower* than the odds of a simultaneous
> meteor strike from outer space cutting the physical Internet
> connections between my sending this email and those on this list
> receiving it, such that you do not receive this email).

These histrionics portray the study of Dilithium's security as something
that stabilized years ago.

If lattice attacks are so stable, why did Dilithium 3.0 in 2020 throw
away the Dilithium-1 parameter set? How could new speedups be claimed in
https://eprint.iacr.org/2025/1910 from October 2025 and get past the
Asiacrypt 2025 reviewers? Where can I find someone explaining a supposed
error in https://eprint.iacr.org/2026/279 from February 2026?

FrodoKEM, frequently described as the most conservative lattice system,
says it's an implementation of https://eprint.iacr.org/2010/613. But
that paper claimed 2^150 security for 256-dimensional lattices. The
reason dimension 256 sounds absurd today isn't because of a dramatic
improvement from a single paper; it's from a long series of papers each
making a smaller improvement---a process that's continuing today.

Why exactly should we ignore the possibility of continuing advances in
lattice attacks breaking dimension 512? 1024? Even larger?

Arguments along the lines of "This is okay for signatures because we'll
all move to larger dimensions before the smaller dimensions are broken"
are making two basic security mistakes. First, these arguments focus on
environments that can upgrade quickly, while ignoring the long tail of
slower upgrades. Second, these arguments are conflating attacks _known
to the public_ with attacks _known to attackers_.

The second gap is completely clear in, e.g., an NSA document

    https://www.eff.org/files/2015/01/28/20141228-spiegel-gchq_presentation_on_the_bullrun_programs_decryption_capabilities.pdf

saying "For the past decade, NSA has lead an aggressive, multi-pronged
effort to break widely used Internet encryption technologies" and saying
"Cryptanalytic capabilities are now coming on line" and saying that these
capabilities are "extremely difficult and costly to acquire".

IDA, a private NSA subsidiary, hired famed cryptanalyst Don Coppersmith
around 2003. Is anyone willing to say "Clearly every attack Coppersmith
developed after 2003 is something the public figured out within a few
years"? Also, it's not as if Coppersmith was alone there; NSA is the
largest employer of mathematicians in the United States. Overconfidence
is a poor risk-management strategy.

Maybe at some point the public will be close to the best attack against
general lattice problems. Then public attacks will stabilize. But any
particular lattice system might be much easier to break than the general
lattice problems. We've seen fast breaks of, e.g., HILA5 and Round2. A
few cryptanalysts have looked at specific aspects of the ML-DSA attack
surface beyond general lattice attacks, but these efforts are far too
limited to inspire confidence.

And then there are all the ML-DSA software problems, such as the bugs
for which my new paper demonstrates exploitability. The cryptography
that's actually used, and that's a target of attack, is what software
(and hardware) actually does, whether or not that's what some spec says.

> "The dirty hands of secret services are all over this
> design, so it is probably already backdoored" (https://blog.cr.yp.to/)

Those words (1) are not a quote from me and (2) are spectacularly
missing the point of what I've written about the risks of solo PQ.

Here's a simpler analogy. Back in the 1990s, NSA used export controls to
promote RSA-512. People distributing stronger software were threatened
with criminal prosecution.

Does this mean NSA backdoored RSA-512? No. Normal readers understand
"backdoored" to mean that NSA inserted a _back door_ into the design.
But they didn't. They didn't have to. The whole building was flimsy.
Here's a 2015 paper breaking RSA-512 on EC2 for $75:

    https://eprint.iacr.org/2015/1000

Sure, computer power was more expensive 20 years earlier, but if you
have a big pile of computations to do then buying your own computers
(or, at really large scale, special-purpose chips) is considerably more
cost-effective than renting computers. NSA has a long history of buying
its own equipment:

    https://web.archive.org/web/20230430105513/https://www.nsa.gov/portals/75/documents/news-features/declassified-documents/nsa-early-computer-history/6586785-nsa-key-role-in-major-developments-in-computer-science.pdf

RSA-512 was certainly not stopping serious attackers such as NSA in the
1990s. But, amazingly, IETF standardized RSA-512---merely slapping an
"export" label on it, as if warnings would stop security problems:

    https://datatracker.ietf.org/doc/html/rfc2246

Around the turn of the century, export controls added exemptions for
open-source software, pretty much eliminating the export argument for
RSA-512---but the mere _existence_ of this _option_ in TLS continued
causing tremendous security damage for decades:

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

IETF shares responsibility for this damage.

If someone wants to argue that standardizing RSA-512 was a _good_ idea,
I'd be interested in hearing the argument. But if the argument is that
there was no back door and therefore no damage: sorry, that conclusion
is flatly wrong. Back doors are only one of many attack mechanisms.

> any attempt to delay that deployment

This could make sense in reference to ECC vs. PQ, but makes no sense in
reference to ECC+PQ vs. solo PQ (a comparison raised by many of the
people objecting to solo PQ). Both ECC+PQ and solo PQ are deploying PQ;
the only difference is whether there's also ECC as mitigation against PQ
security failures.

As for "attempt to", it's interesting that the mailing-list censor
didn't speak up to complain about this attribution of motivations.

> Hybridization is not simple addition, it is more like A XOR B...

Huh?

SIKE was applied to tens of millions of real TLS sessions. The only
reason the SIKE break didn't immediately expose the user plaintext to
attackers is that the deployment was ECC+SIKE (CECPQ2b), facing the
attacker with the problem of breaking ECC.

https://cr.yp.to/papers.html#qrcsp surveys many more breaks of PQ specs.
For software breaks see, e.g., https://cr.yp.to/papers.html#kyberslash
and https://cr.yp.to/papers.html#mldsa. There are endless ways that
ECC+PQ can rescue sessions that would otherwise be broken.

Is it possible to screw up ECC+PQ signatures by, e.g., writing "return
ecc_valid or pq_valid" instead of "return ecc_valid and pq_valid"? Yes.
Could this get past tests? Yes. People can botch anything. Failures can
happen in the combiner code. But there's a far larger chance of failures
in many more lines of ML-DSA code, including many lines that are less
likely to be properly tested and reviewed than a combiner.

> inherits the malleability weakness of ECDSA

There's still no response to what I wrote about this "weakness" here:
https://mailarchive.ietf.org/arch/msg/last-call/iAJnFXRSSjBjn1TbEYNNygUsexM/

> one size doesn't fit all cases

1312-byte keys, 2420-byte signatures: ML-DSA-44

1344-byte keys, 2484-byte signatures: Ed25519+ML-DSA-44

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