Hi Eric and all, ML-KEM/Kyber was designed with implicit rejection.
K', the output of Decap, Algorithm 18 of FIPS 203, is always a pseudorandom byte string. Seeing K' one can't tell whether Decryption failure happens. 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. (*) When c is not generated by Encap, practically c is not a valid ciphertext, then practically c' at step 8 is different from c. Therefore, implicit rejection happens. This practically provides CCA security because the output K' has nothing to do with the Decap key. Querying invalid ciphertexts gives the attacker no information about the Decap key. When a handshake fails, practically it is not caused by a decryption failure because the probability of (*) is practically zero. So, just tell implementors to treat the ML-KEM as having zero decryption failure. Regards, Quynh. From: Eric Rescorla <[email protected]> Sent: Monday, September 22, 2025 3:03 PM To: <[email protected]> <[email protected]> Subject: [EXTERNAL] [TLS] ML-KEM failures 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]
