Hi Tim, > Op 23 sep 2025, om 03:49 heeft Tim Bray <[email protected]> het volgende > geschreven: > > Just out of curiosity, is the chance of failure easy to compute? E.g. chance > of a random-UUID collision is something like 2.7 * 10**-18 >
It’s part of the properties of ML-KEM (because it’s a security-related parameter). It’s specified in Table 1 of the FIPS: for ML-KEM 512, the failure rate is 2^-138, the others similarly cryptographically negligible. Realistically, ML-KEM decapsulation failures will never happen before the heat death of the universe or something similarly silly. Cheers, Thom > -T > > On Mon, Sep 22, 2025, 6:13 p.m. Filippo Valsorda <[email protected] > <mailto:[email protected]>> wrote: >> Strong agree. Failure probabilities lower than the chance of hardware >> failure can only be ignored. Anything else is needless complexity. >> >> (I believe we’d also avoid handling the DSA signature failure case, if we >> were to write it up today.) >> >> 2025-09-22 21:03 GMT+02:00 Eric Rescorla <[email protected] >> <mailto:[email protected]>>: >>> 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] <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] To unsubscribe send an email to [email protected]
