Sophie Schmieg writes:
> 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.
Maybe there are practical implications. Specifically:
* Maybe there's a feasible algorithm for attackers to find failing
ML-KEM ciphertexts (ciphertexts that are enc outputs but make dec
fail). This is a complicated attack question that hasn't seen
nearly enough cryptanalysis to justify claims about the optimal
attack cost.
* Once an attacker triggers a failure, that's actually leaking quite
a bit of information about the secret key, and presumably finding
the whole secret key isn't much harder. That's also what one sees
in quite a few of the successful chosen-ciphertext attacks known
against other systems in the literature.
* Finding the secret key certainly has practical implications.
It's unhelpful to mention these failures inside specifying how to
_implement_ ML-KEM: there's no known way for an implementation to make
the situation better by checking for these failures, while it's easy to
see how such checks can make the situation much worse. But _security_
analyses should account for these failures. As an example of the
practical impact, a reasonable risk-management strategy would
* presume that ML-KEM _fails_ to protect against chosen-ciphertext
attacks (note that dec failures aren't the only issue here),
* limit ML-KEM usage to one-time keys (keys used for just one
ciphertext), and
* switch to safer KEMs for static-key applications (such as server
identity keys in KEMTLS).
Of course this should be combined with other risk-management steps such
as hybrids.
---D. J. Bernstein
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
