Note that a decryption failure will cause a leakage of the private key under certain circumstances (I think not in the case of a single-use ephemeral key like in TLS, nor do we care in that case). However, even if there was an error flag returned by the implementation (realistically, a decapsulating party cannot determine whether a decryption failure was due to rounding errors or due to malicious or accidental ciphertext manipulation, so such an error flag would not be possible in the first place, but I digress), this circumstance is mathematically so unlikely that it is far more likely that a cosmic ray flipped a bit, a CPU manufacturing bug resulted in a CPU that can't compute very well, enough electrons randomly deciding to actually just be in a different wire, etc. Trying to handle ML-KEM decapsulation failures is similar to writing the same if statement twice, in case the CPU changed its mind in-between. We shouldn't mention it, and just ignore its existence for practical realizations of ML-KEM, the decapsulation failure is something that needs to be analyzed for theory, but it has no practical implications.
On Tue, Sep 23, 2025 at 8:30 AM Dang, Quynh H. (Fed) <quynh.dang= [email protected]> wrote: > Hi Thomas, > > I wrote " So, just tell implementors to treat the ML-KEM as having zero > decryption failure" which implies that there is no need for such check > program. > > Theoretically, if a different "ML-KEM" has a high decryption failure rate > and a user's TLS's handshake fails more often than the level that they are > happy with, then they can write such a program to detect what is the > percentage of the failed handshakes caused by the decryption failure. The > system (the client) would save the received ciphertexts of the failed > handshakes. This program would run separately from the ML-KEM's Decap of > course. > > But no one should use such a KEM where its decryption failure rate > noticeably affects the handshake performance and such KEM likely has a > security issue. > > One can write a check program for ML-KEM in constant time by doing steps: > 1, 2, 3, 4, 5, 8, then check if c=c'. > > Regards, > Quynh. > > > -----Original Message----- > > From: Bellebaum, Thomas > > <[email protected]> > > Sent: Tuesday, September 23, 2025 7:59 AM > > To: Dang, Quynh H. (Fed) <[email protected]>; [email protected]; > > [email protected] > > Subject: [EXTERNAL] Re: [TLS] Re: [EXTERNAL] ML-KEM failures > > > > Hi Quynh, > > > > > The Decaps key holder can write another program to output c' and check > if c > > = c' or not to know if Decryption failure happens when c is a ciphertext > > generated correctly by Encap. (*) > > > > Just for the record: Doing so could be dangerous for the same reason that > > constant time implementations of the FO transform hide whether c != c'. > It can > > potentially leak exactly the information the implicit rejection is > designed to > > hide (and security arguments of many schemes rely on this). > > > > -- TBB > _______________________________________________ > TLS mailing list -- [email protected] > To unsubscribe send an email to [email protected] > -- Sophie Schmieg | Information Security Engineer | ISE Crypto | [email protected]
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
