Differences

This shows you the differences between two versions of the page.

--- pgpfan:efail [2022/05/16 21:16] – "Release unauthenticated plaintext". b.walzer
+++ pgpfan:efail [2022/05/16 21:17] (current) – Typo b.walzer
@@ Line 21: / Line 21: @@
 It is sometimes claimed that OpenPGP implementations (GnuPG in particular) are at fault for EFAIL because they "release unauthenticated plaintext". After all, if the OpenPGP implementation had detected that there was a potential modification and had blown up with an error before releasing any of that modified text, then none of this would of happened.
-*Any* data leak could be prevented by detecting the potential problem ahead of time and then refusing to release data. We are adding a known insecure mode (HTML email) to a system and then blaming the cryptography code for not anticipating the potential problem when things inevitably go wrong? This seems a bit random. At any rate, the "just blow up" approach is not practical for the sort of offline applications that OpenPGP is normally used for. An email shows up with a possible modification. Then what? You can't just show the user a blank screen. It would be a perfectly reasonable approach to warn the user and then show the message in a very safe environment. If the user is under attack they need to be allowed to try to figure out how. Chances are it will just be some sort of transmission error. The same sort of thing applies to encrypted files. The user might want to try to recover the corrupted data.
+//Any// data leak could be prevented by detecting the potential problem ahead of time and then refusing to release data. We are adding a known insecure mode (HTML email) to a system and then blaming the cryptography code for not anticipating the potential problem when things inevitably go wrong? This seems a bit random. At any rate, the "just blow up" approach is not practical for the sort of offline applications that OpenPGP is normally used for. An email shows up with a possible modification. Then what? You can't just show the user a blank screen. It would be a perfectly reasonable approach to warn the user and then show the message in a very safe environment. If the user is under attack they need to be allowed to try to figure out how. Chances are it will just be some sort of transmission error. The same sort of thing applies to encrypted files. The user might want to try to recover the corrupted data.
 The spin required to make this a PGP problem was unfortunate in that it distracted from the actual issue of inherently insecure message content in encrypted messaging. The good work done by the security researchers ended up being in a sense wasted. Inherently insecure message content is still a serious issue today (2020).