To the client, when using the APIs as currently common in various cryptographic libraries following the specification of FIPS 203, there would be no action needed whether there is an encryption failure (which won't happen), a corrupted ciphertext, or a malicious modified ciphertext. In all three cases the implementations will return a "shared" secret that is not actually shared with the encapsulating party, and when used with an AEAD as it would be the case in TLS, the AEAD decryption will fail and whatever message was sent on the record layer will be unrecoverable for the other party. This is the same behavior as TLS currently has in case a public key share is modified (intentionally or maliciously), so TLS stacks will already be capable of handling this case. The main difference between ML-KEM and ECDH here is that, while with ECDH a modified key share automatically silently fails to result in an actually shared secret, ML-KEM (and other FO transform based KEMs) learn about such a modification and could return an error code, but the conscious decision was made to not do so.
The only interesting difference (and by interesting I mean theoretically interesting difference) here is that for ML-KEM there can, if you believe in the existence of arbitrarily large numbers <https://en.wikipedia.org/wiki/Ultrafinitism>, be the situation where an unmodified key share also fails to decrypt, resulting in a non-shared secret as if it was modified. An adversary attempting to learn the private key would in this situation, by knowing that the other party failed to decapsulate this specific ciphertext, learn properties of the private key. But again, this decryption failure isn't so incredibly unlikely that this is not a useful attack. The decapsulating party does not actually learn whether the failure to establish a shared secret was due to a malformed ciphertext or due to a decapsulation failure (You could check, but checking would be extremely expensive, computationally speaking, as you need to basically brute force whether there are any closely related possible shared secrets that are not the result of a malformed ciphertext). So from a practical point of view, there is simply no guidance to give implementers. Not only are such errors incredibly unlikely, they also behave exactly the same as corrupted ciphertexts, and your stack will handle those, since there is no difference to the behavior in the case of ECDH. On Thu, Sep 25, 2025 at 1:36 PM Eric Rescorla <e...@rtfm.com> wrote: > > > On Thu, Sep 25, 2025 at 11:41 AM D. J. Bernstein <d...@cr.yp.to> wrote: > >> > “The failure rate for ML-KEM is >> > sufficiently low that it is highly unlikely that any implementation will >> > ever encounter it in practice.” >> >> That's not known. >> >> It's important to distinguish two different situations here. Situation 1 >> is _legitimately generated ciphertexts_. For that situation, Table 1 of >> >> >> https://web.archive.org/web/20250907044602/https://eprint.iacr.org/2025/1562.pdf >> >> reports proofs that the failure rate is <=2^-80, <=2^-95 for dimensions >> 768, 1024. Also, the failure rate is _conjectured_ to be 2^-138.8, >> 2^-164.8, and 2^-174.8 for dimensions 512, 768, 1024 respectively. If >> this conjecture is correct then legitimate users would have to be >> amazingly unlucky to generate a failing ciphertext. >> >> Situation 2 is _ciphertexts generated by attackers_. The reason this is >> different is that attackers can spend tons of computation searching for >> ciphertexts that are enc outputs but more likely to fail than average >> enc outputs are. As an example of how it's not obvious what the best >> tradeoffs are here, page 23 of the original Kyber documentation >> >> >> https://web.archive.org/web/20190214071008/https://pq-crystals.org/kyber/data/kyber-specification.pdf >> >> claimed that a particular approach was "probably" the "best strategy"; >> that turned out to _not_ be the best attack. The paper >> >> >> https://web.archive.org/web/20250708141344/https://eprint.iacr.org/2021/193.pdf >> >> gives you an idea of how complicated it can be to optimize attacks using >> some of the available structure. >> > > Thanks for the expanded discussion. > > It seems to me that the relevant question for the purposes of this > document is whether > the client should do anything in this case other than just report a > connection failure > and handle it like any other connection failure. > > -Ekr > > _______________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org > -- Sophie Schmieg | Information Security Engineer | ISE Crypto | sschm...@google.com
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
