Daniel J. Bernstein, a cryptographer at the University of Illinois at Chicago and Academia Sinica in Taiwan, published a paper on June 1, 2026, demonstrating that an attacker can recover an equivalent signing key and forge signatures on any message if ML-DSA signing software contains either of two small coding errors. ML-DSA is the standardized form of the CRYSTALS-Dilithium post-quantum signature scheme, published by NIST as FIPS 204 in August 2024.
Bernstein ran both attacks on his own implementation of ML-DSA, written in the Sage mathematics system, after adding each bug to it. Each such change “interoperates with authentic ML-DSA, passes typical tests, and is exploitable in 1 second on 1 laptop core,” he wrote in the self-published, 59-page paper.
Bernstein attacked buggy software, not the ML-DSA standard, and he based his case against deploying ML-DSA without a classical signature beside it on a forecast of how many severe bugs new libraries will ship. He wrote that his estimates “assume that there will not be a severe break of the ML-DSA standard per se,” a risk he treated separately.
The two demonstrations
In the first bug, the coefficients of a secret value generated for each signature repeat in pairs, a pattern Bernstein calls AABBCC. He modeled it on a flaw in both official implementations of Dilithium 1.0, the version of ML-DSA’s predecessor submitted to NIST in 2017.
Vadim Lyubashevsky, writing for the CRYSTALS team on NIST’s pqc-forum mailing list on January 2, 2018, thanked Peter Pessl for reporting that error. “This reuse of randomness can easily be exploited to recover the secret key,” Lyubashevsky wrote. Bernstein wrote that “there do not appear to have been any demos” showing that this or other announced flaws in Dilithium and ML-DSA software could be exploited.
In his first demonstration, an attacker who sees a public key and two signatures solves for an equivalent secret key and then signs messages of the attacker’s choosing. Bernstein reported breaking a newly generated key in each of 50 runs.
In the second bug, the secret per-signature value repeats across signatures, a slip Bernstein compared with the Sony PlayStation 3 ECDSA vulnerability. An ML-DSA signer sometimes discards a candidate signature and starts again. Bernstein recovered the key from two signatures when both had needed the same number of restarts.
He put the success rate at “roughly 80% of the time” and wrote that an attacker can check the result and try another signature. He released both attacks as open-source scripts.
Code from two libraries
Bernstein reproduced ML-DSA subroutines from two open-source libraries, mldsa-native and OpenSSL, and described small slips in each that would produce exploitable patterns. In the mldsa-native routine, a programmer who changed “1 to 0 and 3 to 2” after a paste, in what Bernstein called “a moment of forgetfulness,” would produce the AABBCC pattern.
In the OpenSSL routine, a programmer who accidentally changed one minus sign to an ampersand would clear every second coefficient and produce an A0B0C0 pattern, “again exploitable as easily as AABBCC,” Bernstein wrote, though he did not demonstrate that attack.
Errors in either subroutine “will not be caught by ML-DSA-44 functionality tests,” Bernstein wrote.
Bernstein’s estimates
Bernstein estimated that about 50 ML-DSA libraries will see noticeable deployment over the next five years, adding 100,000 to 200,000 lines of new code. He applied rates of 0.450 and 1.187 cataloged vulnerabilities per 1,000 lines of net code change, figures that Jenny Blessing, Michael Specter, and Daniel Weitzner measured in 2021 for the NSS and OpenSSL libraries.
He arrived at about 100 vulnerabilities, or two per library on average. Treating one vulnerability in eight as severe, he estimated that each new ML-DSA library has about a one-in-four chance of a severe vulnerability.
Ed25519 is an elliptic-curve signature scheme that Bernstein designed with four colleagues. For 2027, he estimated that 18% of ML-DSA keys would be breakable. He put the share for that year at about 4.1% for keys used to sign each message with both ML-DSA and Ed25519, and at 1.6% for Ed25519 keys used alone.
For a large-scale attacker, Bernstein assumed “a secret billion-dollar quantum computer by 2029” when he modeled quantum attacks on Ed25519. He concluded that even years after the first quantum attack, the number of breakable Ed25519+ML-DSA keys would still be much smaller than the number of breakable ML-DSA keys. Referring to his Figure 9.1.1 projections, he wrote that “using ML-DSA rather than Ed25519+ML-DSA within the next 5 years would damage security.”
Responses on the IETF list
Bernstein raised the paper on June 1 in a discussion of draft-ietf-tls-mldsa during the IETF’s last call, the final round of public comment before the approval decision. In that draft, IETF authors specify how to use ML-DSA in TLS 1.3, the protocol used to encrypt web connections.
Bernstein suggested that the Internet Engineering Steering Group, or IESG, extend the last call, due to close that day. The IESG is the body that approves IETF specifications.
In the paper, Bernstein disputed an April 6 blog post in which Filippo Valsorda, a cryptography engineer, argued against hybrid signatures, the practice of pairing a post-quantum signature with a classical one.
Bernstein “looks for severe bugs in ML-DSA implementations, and only finds one in a 2017 implementation,” Valsorda replied on June 2, adding that the bugs “would be caught by the vectors in the body of draft-celi-acvp-ml-dsa.” That document is a NIST specification of validation tests for ML-DSA implementations.
John Mattsson of Ericsson wrote the same day that he did not think the IESG should take any action based on the paper. With the last call closed on June 1, the IESG was next to decide on the draft.
Update, November 13, 2026: The IESG approved draft-ietf-tls-mldsa on July 8. On September 10, it denied an appeal by Bernstein that it called “a second appeal.” The draft entered the RFC Editor queue on September 11 and had no RFC number as of October 12.
