2026-06-02 23:05 GMT+02:00 D. J. Bernstein <[email protected]>:
> 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.
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
