[openpgp] Re: multi-key collisions in OpenPGP
Daniel Huigens <[email protected]> Wed, 19 Nov 2025 10:37:13 +0000
| Newsgroups | gmane.ietf.openpgp |
|---|---|
| Message-ID | <dGL_Bv8L4nytTq4_XEtW1fUbhMfWmoG_v-WJfHOWKR6JeGisMl9AI9xWxXux2jHtyFcYU35EZBYZ872muhRY0LZGnuEwjj7c0zXqcHRC3Z4=@protonmail.com> |
Hi Falko, On Monday, November 17th, 2025 at 10:54, Falko Strenzke wrote: > Releasing plaintext before the final chunk is only a problem if the message isn't cancelled after seeing the final authentication tag or the lack of it. If incompletely verified plaintext in this sense is rendered to the user or otherwise processed, this is a problem first of all due allowing truncation attacks. The possibility of MKC would only be further problem. But for MKC to be a real problem, we need a special setting (see my example below). Thanks for the clarification and concrete example. I agree that, if the final authentication tag fails to validate, the implementation should return an error message as RFC9580 requires. However, when streaming, data may already be output to stdout or processed in some other way (e.g. if you have a streaming MIME parser) before that. As long as a clear error message is displayed to the user, I think that should be OK (or at least it's not any worse than displaying or processing an unencrypted and unsigned message, for example). I do agree that it's novel that such an error may indicate not just a truncation but also an attempted MKC attack, indeed, and communicating this clearly may require some care. In either case, though, the integrity of the displayed message is not verified (as a whole), somewhat similarly to if an expected signature had failed to verify at the end, so perhaps an error message could focus on that. Let me know whether that sounds reasonable or if you disagree. Best, Daniel _______________________________________________ openpgp mailing list -- [email protected] To unsubscribe send an email to [email protected]