Note that the described vulnerabilities are due to the usage of the
Fiat-Shamir transform and are shared by all constructions that use the
Fiat-Shamir transform as well as ECDSA, which is similar, but legally
distinct from Fiat-Shamir. ML-DSA is actually the most hardened version of
this transform, using both entropy stored in the private key with the
message as well as externally supplied entropy for computing its witness.
This is why djb has to reach deep into the implementation and invent a
fault at rhoprimeprime, while much easier to trigger faults exist in EdDSA
(simply supplying an inconsistent public and private key to an
implementation is enough to trigger the fault there). Unless we have
similar warnings for ECDSA and EdDSA, I would not bother with adding them.
This behavior is well known and covered by test vectors, for all
Fiat-Shamir variants I'm aware of.

On Tue, Jun 2, 2026 at 10:38 AM Filippo Valsorda <filippo@ml.filippo.io>
wrote:

> 2026-06-02 16:23 GMT+02:00 Russ Housley <housley@vigilsec.com>:
>
> With the notice that you attached to this note, it cannot be used to
> improve the Security Considerations of draft-ietf-tls-mldsa-03.  As such,
> this is very unhelpful.
>
>
> There is no need anyway.
>
> Bernstein looks for severe bugs in ML-DSA implementations, and only finds
> one in a *2017* implementation of Dilithium 1.0, and then *invents* three
> bugs that resemble it. All four would be found by running *any* KATs for *any
> signing interface*, including the high-level non-internal deterministic
> signing one.
>
> This paper could have been a few uninteresting entries in a muzoo
> <https://github.com/FiloSottile/mostly-harmless/tree/main/muzoo> mutations
> folder.
>
> Some of the surrounding 50 pages of stuff make claims that are at best
> confused and at worst intentionally obtuse. For example on page 15 he
> claims he can't see how to use a test vector that provides (seed, public
> key, message, µ, signature)
> <https://github.com/C2SP/wycheproof/blob/878e5366008753df2064d40c49f8e2f50f9c6af7/testvectors_v1/mldsa_44_sign_seed_test.json>
> to test a signing interface that does (seed, message) => (signature) or a
> key generation interface that does (seed) => (public key). These
> misunderstanding seem to mislead other parts of the paper such as claiming
> a trivially-caught bug "can’t be caught by the nonexistent ML-DSA keygen
> tests in [Project Wycheproof]" or that "[Project Wycheproof] seems to
> require a nonstandard interface to test ML-DSA signature generation, and it
> doesn’t test ML-DSA key generation at all."
>
> These bugs are so easy to find that they would be caught by the vectors in
> the body of draft-celi-acvp-ml-dsa
> <https://pages.nist.gov/ACVP/draft-celi-acvp-ml-dsa.html>, without even
> accessing actual ACVP vectors provided by NIST at
> https://github.com/usnistgov/ACVP-Server/tree/master/gen-val/json-files,
> which Bernstein somehow wrote a 59-page paper about testing ML-DSA without
> referencing.
>
> Russ
>
> > On Jun 1, 2026, at 4:42 PM, D. J. Bernstein <djb@cr.yp.to> wrote:
> >
> > I've just finished a paper titled "Exploiting ML-DSA bugs":
> >
> >    https://cr.yp.to/papers.html#mldsa
> >
> > Let me gently suggest that IESG extend the current "last call" and ask
> > the TLS WG chairs to stop censoring my messages to the TLS mailing list.
> >
> > The abstract of the paper is as follows:
> >
> >    At least four Dilithium software vulnerabilities have been announced
> >    so far, including an identical vulnerability in each of the two
> >    official Dilithium 1.0 implementations and two different
> >    vulnerabilities in a "verified" implementation of Dilithium 3.4,
> >    also known as ML-DSA. However, there do not appear to have been any
> >    demos showing exploitability of any of these vulnerabilities.
> >
> >    This paper shows that a small change in ML-DSA software creates an
> >    ML-DSA version of the Dilithium 1.0 software vulnerability, can
> >    occur by accident as in the original vulnerability, interoperates
> >    with authentic ML-DSA, passes typical tests, and is exploitable in 1
> >    second on 1 laptop core. This paper provides an open-source attack
> >    demo that inspects a public key and two signatures, obtains an
> >    equivalent secret key, and uses this key to rapidly forge signatures
> >    on attacker-chosen messages.
> >
> >    This paper also shows that another small change in ML-DSA software
> >    creates a different software vulnerability, can occur by accident as
> >    in the Sony PlayStation 3 ECDSA vulnerability, interoperates with
> >    authentic ML-DSA, passes typical tests, and is exploitable in 1
> >    second on 1 laptop core. This paper again provides an open-source
> >    attack demo that rapidly forges signatures on attacker-chosen
> >    messages, after inspecting a public key and a few signatures.
> >
> >    This paper then uses standard techniques to estimate exploitability
> >    rates for ML-DSA software, and to estimate the number of ML-DSA keys
> >    that the attacker will be able to break in year Y, as a function of Y.
> >
> >    This paper also reviews evidence in the literature regarding quantum
> >    timelines, costs of quantum attacks, and non-quantum security
> >    failures in ECC, so as to estimate the number of Ed25519+ML-DSA
> >    double-signing keys that the attacker will be able to break in year
> >    Y. The main conclusion is that, even years after the first quantum
> >    attack, this number will still be much smaller than the number of
> >    breakable ML-DSA keys.
> >
> >    Qualitative security benefits of ECC+PQ compared to solo PQ have
> >    been pointed out before, but not with quantified estimates of the
> >    number of breakable keys. Some recent postings gave arguments
> >    disputing these benefits; this paper closes by pointing out flaws in
> >    those arguments.
> >
> > ---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 is clear, and cannot
> > be limited by an informative section. BCP 78 also 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. There's no legitimate excuse for
> > that, and it goes far beyond what copyright law allows as fair use, such
> > as giving quotes for purposes of commentary.
> >
> > --
> > last-call mailing list -- last-call@ietf.org
> > To unsubscribe send an email to last-call-leave@ietf.org
>
> _______________________________________________
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-leave@ietf.org
>
>
> _______________________________________________
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-leave@ietf.org
>


-- 

Sophie Schmieg | Information Security Engineer | ISE Crypto |
sschmieg@google.com