[TLS] Re: [Last-Call] Last Call: <draft-ietf-tls-mldsa-03.txt> (Use of ML-DSA in TLS 1.3) to Informational RFC

[Filippo Valsorda <[e-mail]>]

2026-06-02 23:05 GMT+02:00 D. J. Bernstein <[e-mail]>:
> Filippo Valsorda writes:
> > These bugs are so easy to find
> 
> The CVE-2026-24850 bug [...]
> 
> The CVE-2026-22705 timing leak [...]
> 
> The CVE-2026-41990 bug [...]
> 
> The "previous" vs. "current" bug [...]

>From your paper:

> I’m counting vulnerabilities as severe only if the attacker can quickly forge signatures on new attacker-chosen messages.

>From my reply:

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

Those are not severe bugs. So yes, only one real and three imagined severe bugs, all easy to find by doing any testing at all.

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

Easy: because in 2017 Dilithium 1.0 was research software that ~no one in industry cared about, other implementations didn't exist, nor did KATs.

> Et cetera. My paper is looking at the real world, not at some fantasy
> world [...]

All the severe bugs in the paper that affect ML-DSA software (as opposed to the Dilithium 1.0 submission in 2017) are fantasy bugs.

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

I guess we disagree on what testing is typical. Adding ≥ 1 readily available known-answer test for a high-level deterministic function is in my opinion typical in cryptography engineering, but I acknowledge that you seemed confused by how to apply the (seed, public key, message, µ, signature) Wycheproof test vectors to your implementation.

Here is a Sage script that applies the very first test vector of mldsa_KL_sign_seed_test.json to find both bugs in your implementation. It uses the randombytes() hook you are fond of and the external standard randomized interface, instead of the deterministic interface I tend to prefer. It also tests key generation, despite "the nonexistent ML-DSA keygen tests in [Project Wycheproof]."

https://gist.github.com/FiloSottile/5fa77f87543830a068d400a83d9bcb57

I don't expect this will convince you, but hopefully it will reassure others who might be genuinely concerned about the testability of ML-DSA.