pgpfan:efail
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
pgpfan:efail [2021/07/01 18:50] – I partially reproduced it, understand fundamental issue more b.walzer | pgpfan:efail [2022/05/16 21:17] (current) – Typo b.walzer | ||
---|---|---|---|
Line 5: | Line 5: | ||
* [[https:// | * [[https:// | ||
- | The word " | + | To be completely clear... |
EFAIL was a list of different ways to cause inherently insecure message content (HTML email) to leak decrypted messages. Such data leakage was a known issue and was under routine exploitation at the time. This fact alone should be enough to convince most people EFAIL had nothing to do with either PGP (or S/MIME). When you have a hole big enough to drive a truck through there is no extra value in discussing the size and shape of the truck. Unfortunately in the case of EFAIL we need to spend time discussing truck dimensions. | EFAIL was a list of different ways to cause inherently insecure message content (HTML email) to leak decrypted messages. Such data leakage was a known issue and was under routine exploitation at the time. This fact alone should be enough to convince most people EFAIL had nothing to do with either PGP (or S/MIME). When you have a hole big enough to drive a truck through there is no extra value in discussing the size and shape of the truck. Unfortunately in the case of EFAIL we need to spend time discussing truck dimensions. | ||
Line 18: | Line 18: | ||
This might be a good place to point out how wildly impractical the CFB gadget method is compared to the other methods listed in the EFAIL paper. To make a CFB gadget attack work you need to know the first 11 bytes/ | This might be a good place to point out how wildly impractical the CFB gadget method is compared to the other methods listed in the EFAIL paper. To make a CFB gadget attack work you need to know the first 11 bytes/ | ||
+ | |||
+ | It is sometimes claimed that OpenPGP implementations (GnuPG in particular) are at fault for EFAIL because they " | ||
+ | |||
+ | //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). | 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). | ||
Line 23: | Line 27: | ||
A more fundamental problem with all this is that when used for messaging, PGP uses a combined identity/ | A more fundamental problem with all this is that when used for messaging, PGP uses a combined identity/ | ||
- | The OpenPGP standard and implementations of that standard have suffered from security weaknesses of greater significance than EFAIL with no media coverage at all. That is why the media blowup over EFAIL is so odd. I have a theory... | + | The OpenPGP standard and implementations of that standard have suffered from security weaknesses of greater significance than EFAIL with no media coverage at all. That is why the media blowup over EFAIL is so odd. I have no idea why this ended up so wrong. What ever the reasons, |
- | + | ||
- | Encryption "at rest" is pretty much a solved problem for the sorts of things OpenPGP does. That is why the OpenPGP standard is so stable over the years. As a result there is not very much academic interest in such problems any more. | + | |
- | + | ||
- | The excitement these days is mostly centred on the issues of "in flight" | + | |
- | + | ||
- | So this all might just be another | + | |
[[pgpfan: | [[pgpfan: | ||
pgpfan/efail.1625165442.txt.gz · Last modified: 2021/07/01 18:50 by b.walzer