We are getting increasingly off-topic (so I probably shouldn't respond - mea
culpa).
I don't see the ML-KEM case and the DSA (or ECDSA) case to be at all similar.
In ML-KEM, decapsulation failure occurs when both sides do precisely the right
thing, and public key and ciphertext are transmitted faithful, and still the
protocol "fails" (in this case, the two sides generate different shared
secrets).
In the DSA/ECDSA case, the signer internally selects a value ("a sample")
processes it, and then decides that sample doesn't "work", and so it selects a
different sample. This is all internal to the signer - when it does generate a
signature, it is a valid signature to the message, and one for which the
verifier will be able to verify. Hence, the protocol doesn't fail - it's just
that the signer may need to do additional work.
I see these as completely different.
________________________________
From: Filippo Valsorda <[email protected]>
Sent: Tuesday, September 23, 2025 9:15 AM
To: Scott Fluhrer (sfluhrer) <[email protected]>; Russ Housley
<[email protected]>; Eric Rescorla <[email protected]>
Cc: IETF TLS <[email protected]>
Subject: Re: [TLS] Re: ML-KEM failures
2025-09-23 14:53 GMT+02:00 Scott Fluhrer (sfluhrer)
<[email protected]<mailto:[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]<mailto:[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]<mailto:[email protected]>
To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
TLS mailing list -- [email protected]<mailto:[email protected]>
To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
