Bernstein Puts Numbers on ML-DSA's Fragility. The Hybrid Debate Is Over.
What the new attack paper means for your signature deployment
Daniel J. Bernstein has published a 59-page paper titled “Exploiting ML-DSA bugs” that should end the debate over whether hybrid ECC+PQ signatures are necessary. The paper provides open-source attack demonstrations against two classes of ML-DSA (FIPS 204) software vulnerabilities. Both attacks recover an equivalent secret key in under one second on a single laptop core, then forge arbitrary signatures that pass standard verification.
That alone would be significant. What makes the paper consequential for PQC migration programs is its quantitative analysis: Bernstein estimates that 25% of ML-DSA libraries will ship with severe vulnerabilities at initial release, and projects that solo ML-DSA deployment would produce roughly an order of magnitude more breakable signature keys than hybrid Ed25519+ML-DSA over the next five years.
The timing is pointed. In April 2026, cryptography engineer Filippo Valsorda argued that hybrid ECC+ML-DSA signatures are unnecessary and would slow urgent PQC deployment. Sophie Schmieg, Google’s senior cryptography engineer, argued on the IETF TLS list that hybrid signatures are less necessary than hybrid key exchange because signature forgery damage is bounded by key revocation. Bernstein’s paper dismantles both positions with working code and historical data.
The Attacks
The first attack targets what Bernstein calls the “AABBCC” bug, where coefficients in the secret polynomial end up repeating in pairs. This is an ML-DSA-specific version of a vulnerability announced in 2018 by Dilithium co-designer Vadim Lyubashevsky, who said the bug “can easily be exploited to recover the secret key.” Lyubashevsky never published a working demo. Bernstein does.
The second attack targets nonce repetition, the ML-DSA analog of the Sony PlayStation 3 ECDSA disaster from 2010. If ML-DSA signature software accidentally reuses the secret nonce, the attacker recovers the secret key by simple polynomial division. Both attacks produce universal forgeries.
But these bugs pass all standard functionality tests. A signature generated with the AABBCC bug is a valid ML-DSA signature. It interoperates with correct verifiers. It passes known-answer tests if those tests were generated by code with the same bug (which is exactly what happened with both official Dilithium 1.0 implementations in 2017).
Three Independent Papers, One Conclusion
Bernstein’s paper arrives alongside two corroborating findings. Nadim Kobeissi’s “Verification Theatre” paper reported 13 vulnerabilities in Cryspen’s libcrux, a library used by Firefox and OpenSSH that advertised formal verification. Four bugs were inside the formal verification boundary, including a wrong multiplication constant in ML-DSA. If the leading formally verified PQC library ships with bugs its verification framework cannot catch, the unverified majority will fare worse.
Separately, Lee, Lim, and Yoon found that production ML-DSA implementations have shipped with arithmetic overflow bugs from aggressive removal of Montgomery reductions. Whether the resulting non-conformant signatures leak information about the secret key remains an open question that Bernstein frames as likely.
These are not coincidences. They are the statistical baseline for cryptographic software. Blessing, Specter, and Weitzner’s study of eight major cryptographic libraries found 0.45 to 1.19 CVEs per 1,000 lines of code added, with an average exploitable lifetime of 5.13 years. ML-DSA’s signing procedure is unusually complex compared to classical alternatives, and the ecosystem is adding an estimated 100,000 to 200,000 lines of new, algorithm-specific code across roughly 50 libraries. The CVE data predicts what happens next.
Why the “Skip Hybrid” Argument Fails
Valsorda’s case rested on two claims: that ML-DSA is easier to implement securely than classical alternatives, and that the Wycheproof test suite represents improved testing infrastructure. Bernstein addresses both. Wycheproof does not include ML-DSA key-generation tests. Its signature-generation tests use a nonstandard interface that many implementations will skip. Standard interoperability tests, which are what most deployments actually run, cannot catch the classes of bugs Bernstein demonstrates.
The comparison with Ed25519 makes the gap concrete. Bernstein’s CVE review found 1 to 2 severe vulnerabilities across roughly 100 Ed25519 libraries over more than a decade, yielding a severe-vulnerability rate of about 2%. ML-DSA libraries in 2027, by his model, face an 18% rate. That gap narrows over time as ML-DSA implementations mature, but it persists for years.
Schmieg’s argument that signature forgery damage is bounded by revocation does not survive contact with how forgeries actually propagate. DigiNotar compromised hundreds of thousands of users before revocation. Forged code-signing keys enable persistent access that survives key rotation entirely. Revocation bounds the visibility of forgery, not the consequence.
Context the Reader Needs
Bernstein has advocated for hybrid ECC+PQ deployment for a decade and has been among the most vocal critics of NIST’s PQC process. The paper is technically sound, but it is an advocacy document for a position he has held since 2016. That does not weaken the core argument. It does mean the quantitative estimates in Figure 9.1.1 should be treated as order-of-magnitude reasoning rather than precise predictions. The directional conclusion (more breakable ML-DSA keys than Ed25519+ML-DSA keys) holds across wide variations in the underlying assumptions. The specific numbers do not.
The paper also deliberately excludes the risk of a mathematical break of the ML-DSA specification itself. If Dilithium’s underlying lattice assumptions turned out to be weaker than expected, the breakable-key estimates would be vastly higher. This conservative scope means the paper may actually understate the case for hybrid.
Migration Impact
For anyone managing a PQC migration program, three actions follow directly:
Do not deploy solo ML-DSA for new signature applications if hybrid Ed25519+ML-DSA is available. The IETF composite ML-DSA specification for TLS is at revision 10. The LAMPS composite signatures draft for X.509 is at revision 19. The code required for Ed25519+ML-DSA is almost entirely the same code required for solo ML-DSA. The signature size increase from adding Ed25519 (64 bytes) to an ML-DSA-44 signature (2,420 bytes) is 2.6%. For applications already absorbing the order-of-magnitude jump from ECDSA to ML-DSA, the marginal cost is in the noise.
Invest in ML-DSA testing infrastructure that goes beyond standard functionality tests. Cross-library checksum comparisons using derandomized RNGs catch the classes of bugs Bernstein demonstrates. Standard interoperability tests do not. If your organization is evaluating or deploying ML-DSA libraries, require your vendors to demonstrate this level of testing. Organizations in Phase 5 of the PQC Migration Framework should add cross-implementation checksum testing to their pilot acceptance criteria.
Budget for software maturation as a scheduled phase, not a surprise. An ML-DSA library that ships today and receives its first serious security audit in two years is carrying two years of undetected vulnerabilities. The CVE data predicts this with statistical regularity. A credible PQC migration plan treats bug discovery and patching as a scheduled activity, not a crisis.
The irony should not be lost: we are migrating to new signature algorithms because the old ones may eventually be broken by quantum computers, and in the process, we risk deploying the new algorithms in ways that make them immediately breakable by classical computers. Hybrid cryptography eliminates that tradeoff. It should be the default.
Bottom line: Organizations currently planning or executing PQC signature deployment should adopt hybrid Ed25519+ML-DSA as the default configuration. The cost difference is negligible; the security difference, by Bernstein’s quantified analysis, is an order of magnitude in breakable keys for the next five years. Any steering committee still debating whether hybrid signatures are “worth the complexity” can now be shown the numbers.
For the full technical analysis, see my detailed coverage of the Bernstein paper on PostQuantum.com and the broader implications for migration strategy in The PQC Migration’s Biggest Risk Isn’t Quantum Computers.
The Applied Quantum PQC Migration Framework provides structured guidance for hybrid deployment across TLS, IPsec, SSH, and code-signing in Phase 5 (Pilots & Migration Patterns).