> non-zero probability of failure, meaning > two honest parties may derive different shared secrets. [ ... ] > Clients MAY retry if a failure is encountered. [ ... ] > it is RECOMMENDED for implementers to not specifically handle > post-quantum key exchange shared secrets failures
Some implementors have been trained to add checks for "bad" behavior to every function. _Recommending_ otherwise isn't going to override that. The mentions of KEM failures will instead trigger these implementors to randomly screw around with the KEM internals. Sometimes this will end up with code that looks like "if c does not match c' in ML_KEM.Decaps_Internal then ..." where "..." turns out to have a buffer overflow. Such ciphertext mismatches aren't covered by typical test vectors but are _very easy_ for the attacker to generate. Why should a KEM-in-TLS spec allow anything other than computing the specified KEM session key in all cases? Obeying the KEM spec is what's assumed by typical papers on KEM cryptanalysis, so deviating from it rapidly gets into "this cryptosystem is unreviewed" territory. The review that _has_ happened shows that even tiny deviations can be a security disaster: see, e.g., https://cr.yp.to/papers.html#ntrw. > the lack of a known feasable method What does "a known feasable method" mean here? The lack of a method for an attacker to generate failures? This makes no sense in the context of the attacker-free definition of "failure" earlier in the paragraph ("two honest parties may derive different shared secrets"). If the infeasibility claim is instead about whether an implementation's failure checks can be triggered in a realistic attack scenario: Such a claim is unevaluatable without a specification of those checks, and is in any case inappropriate without quantification and references. The claim is wrong for, e.g., the c-c'-mismatch check mentioned above. More broadly, there seem to be two different approaches to handling the IND-CCA2 risks of Kyber/ML-KEM: (1) requiring Kyber/ML-KEM keys to be used just once; (2) denying that the risks exist. #2 is unjustified, and I worry that #2 will deter #1. ---D. J. Bernstein _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
