2025-09-23 14:53 GMT+02:00 Scott Fluhrer (sfluhrer) <[email protected]>: > I disagree - DSA is not an example of this. > > DSA doesn't have a "failure probability", instead, it uses "rejection > sampling" to generate the signature (just like ML-DSA does) - it's just that, > in the DSA case and unlike the ML-DSA case, the probability of a sample being > rejected is extremely tiny. The DSA signature being generated will always be > valid.
I think we are talking about different things. k is generated either by rejection sampling or by reducing a wider value. If using rejection sampling over P-256 (unlike over the other NIST P curves), the chance of rejection is not cryptographically negligible (2^-32). I don't think anyone is arguing rejections there could be ignored. There is *also* in the ECDSA algorithm a case for r = 0 or s = 0 (FIPS 186-5, Section 6.4.1, Step 11), in which one generates a new k value and tries again, as Eric said. That one is ludicrously cryptographically negligible, so it could just be ignored, but the FIPS algorithm forces us to add complexity to "handle" it. The one that is similar to the ML-KEM decapsulation "failures" is the latter. > > *From:* Russ Housley <[email protected]> > *Sent:* Monday, September 22, 2025 4:44 PM > *To:* Eric Rescorla <[email protected]> > *Cc:* IETF TLS <[email protected]> > *Subject:* [TLS] Re: ML-KEM failures > > Eric: > > I agree. DSA also had a super small possibility of a signature failing. If > it ever happened, one would generate a new k value and try again. I > understand it never happened, and peple stopped talking about the failure > case... > > Russ > > > On Mon, Sep 22, 2025 at 9:04 PM Eric Rescorla <[email protected]> wrote: >> Hi folks, >> >> I see that the hybrid doc continues to have this text: >> >> *Failures.* Some post-quantum key exchange algorithms, including ML-KEM >> [NIST-FIPS-203 >> <https://www.ietf.org/archive/id/draft-ietf-tls-hybrid-design-16.html#NIST-FIPS-203>], >> have non-zero probability of failure, meaning two honest parties may derive >> different shared secrets. This would cause a handshake failure. ML-KEM has a >> cryptographically small failure rate; if other algorithms are used, >> implementers should be aware of the potential of handshake failure. Clients >> MAY retry if a failure is encountered. >> >> There was extensive discussion about this for the pure ML-KEM draft, and my >> sense was the sentiment was that this should not be discussed, at least for >> ML-KEM. I think we should remove >> this whole section. >> >> -Ekr >> >> _______________________________________________ >> 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] > _______________________________________________ > 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]
