At a glance, I found a bug. This isn't the worst bug, but as of https://github.com/djmdjm/openssh-wip/pull/64/commits/3f46d7e044f736dd04f7b03a795c2709f5f2c1ae, at least, crypto_sign_mldsa44_ed255199_keygen_seeded() silently discards keygen failures.
https://github.com/djmdjm/openssh-wip/blob/3f46d7e044f736dd04f7b03a795c2709f5f2c1ae/ssh-mldsa-eddsa.c#L58-L83 The "goto out" for lines 66-70 doesn't change the return value from 0. This is the sort of thing I'd expect the OpenSSH team to find in a code review, but since you asked. On Tue, Jun 2, 2026 at 3:24 PM Loganaden Velvindron <[email protected]> wrote: > > > On Tue, 02 Jun 2026, 23:08 John Mattsson, <john.mattsson= > [email protected]> wrote: > >> Agree with Filippo and Sophie. I do not think the IESG should take any >> action based on this paper. It does not present anything that has not >> already been discussed publicly. ML-DSA is clearly a much better algorithm >> than ECDSA and EdDSA. If the IETF were to recommend anything, it could be >> the use of a higher security level, but ML-DSA-44 already provides a >> substantial security margin when used in end-entity certificates. For >> long-term roots of trust, I would use standalone SLH-DSA. >> >> Well-designed and properly implemented hybrid schemes can provide clear >> benefits. However, while X25519MLKEM768 is both cryptographically sound and >> widely implemented, there is currently nothing even close to mature for >> hybrid signatures in TLS. Several TLS libraries have stated on the TLS >> mailing list that they will not implement >> draft-ietf-lamps-pq-composite-sigs. Ericsson can be added to that list: we >> will not support draft-ietf-lamps-pq-composite-sigs in any of our >> libraries, products, or services. In our view, >> draft-ietf-lamps-pq-composite-sigs is neither technically nor legally >> deployable. This should not be interpreted as opposition to hybrid >> approaches in general. We strongly support X25519MLKEM768 and have >> implemented our own non-composite hybrid signature solutions for other use >> cases. >> >> I wish that those in academia advocating hybrid signatures had spent some >> effort producing technically sound and deployable hybrid specifications, >> rather than devoting enormous amounts of time slowing the urgently needed >> PQC migration in industry. >> >> While Bernstein focuses on implementation errors in untested reference >> code from 2017, and one can speculate about future attacks on ML-DSA, we at >> Ericsson have already encountered multiple real-world vulnerabilities in >> hybrid signature systems that vendors have attempted to sell to us. Hybrid >> signatures are not automatically better. In fact, it is trivial to see that >> draft-ietf-lamps-pq-composite-sigs sacrifices several important security >> properties of ML-DSA (non-malleability and BUF), properties whose absence >> from traditional signatures has contributed to significant practical >> vulnerabilities in the past. >> >> Moreover, the objective of draft-ietf-lamps-pq-composite-sigs is _not_ to >> increase security, it is to allow vendors to market FIPS-validated RSA and >> ECDSA as "quantum-resistant" even when only the quantum-vulnerable >> component has been validated. This is, at best, a highly questionable >> business practice and should not be endorsed by the IETF in any way. >> > > I think that security reviews in hybrid ed25519+mldsa 44 for openssh are > welcome. > > What are the security issues you see in this pr ? > > https://github.com/djmdjm/openssh-wip/pull/64 > > > > >> Cheers, >> John Preuß Mattsson >> >> *From: *Sophie Schmieg <[email protected]> >> *Date: *Tuesday, 2 June 2026 at 19:59 >> *To: *Filippo Valsorda <[email protected]> >> *Cc: *IETF TLS <[email protected]>; [email protected] <[email protected]> >> *Subject: *[TLS] Re: [Last-Call] Last Call: >> <draft-ietf-tls-mldsa-03.txt> (Use of ML-DSA in TLS 1.3) to Informational >> RFC >> >> 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 <[email protected]> >> wrote: >> >> 2026-06-02 16:23 GMT+02:00 Russ Housley <[email protected]>: >> >> 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 <[email protected]> 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 -- [email protected] >> > To unsubscribe send an email to [email protected] >> >> _______________________________________________ >> TLS mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> >> >> _______________________________________________ >> TLS mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> >> >> >> -- >> >> Sophie Schmieg | Information Security Engineer | ISE Crypto | >> [email protected] >> >> -- >> last-call mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> > _______________________________________________ > TLS mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
