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]
