The Call of the Open Sidewalk

From a place slightly to the side of the more popular path

User Tools

Site Tools


pgpfan:efail

Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
pgpfan:efail [2021/05/21 16:19] – I have a theory... b.walzerpgpfan:efail [2022/05/16 21:17] (current) – Typo b.walzer
Line 5: Line 5:
   * [[https://www.wired.co.uk/article/efail-pgp-vulnerability-outlook-thunderbird-smime|We're calling it: PGP is dead]]   * [[https://www.wired.co.uk/article/efail-pgp-vulnerability-outlook-thunderbird-smime|We're calling it: PGP is dead]]
  
-The word "Hoax" in the title of this article refers to the attempts to make it seem that EFAIL represented some deficiency in PGP. That was simply not true.+To be completely clear... The word "Hoax" in the title of this article refers exclusively to the media attempts to make it seem that EFAIL represented some deficiency in PGP. It also can be considered a satire of needlessly provocative headlines. EFAIL represents real issues. They were just misrepresented.
  
 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 17: Line 17:
 The OpenPGP specification already has a simple integrity check called the [[pgpfan:mdc|MDC]] that is entirely adequate to detect this particular attack. The addition of authenticated encryption to PGP would make no difference at all for any of the demonstrated EFAIL leaks. It is not possible to suggest authenticated encryption here without also acknowledging that the OpenPGP specification is not susceptible to EFAIL. The CVE was most likely disputed on this basis. The OpenPGP specification already has a simple integrity check called the [[pgpfan:mdc|MDC]] that is entirely adequate to detect this particular attack. The addition of authenticated encryption to PGP would make no difference at all for any of the demonstrated EFAIL leaks. It is not possible to suggest authenticated encryption here without also acknowledging that the OpenPGP specification is not susceptible to EFAIL. The CVE was most likely disputed on this basis.
  
-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/characters of the unencrypted message. The EFAIL paper suggested that the use of the ''multipart/mixed'' MIME attribute could allow as many as 500 guesses at those 11 bytes/characters in the same message. Unfortunately the paper did not give any examples of clients where this might work. The three clients I tested((Thunderbird, Roundcube, Mutt)) would not even recognize a second HTML section in a message, much less decrypt and interpret it. This is important because EFAIL is the sort of attack you only get to do once. The attack email is seen by the user and would normally inform them of the fact they were under some sort of attack.+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/characters of the unencrypted message. The EFAIL paper suggested that the use of the ''multipart/mixed'' MIME attribute could allow as many as 500 guesses at those 11 bytes/characters in the same message. Unfortunately the paper did not give any examples of clients where this might work. Even if there were email clients out there that will allow hundreds of attempts at decoding anonymous encrypted messages in the same message while ignoring hundreds of modification errors the attack was still quite impractical. The attack email is seen by the user and would normally inform them of the fact they were under some sort of attack. Then they would likely have reported it and the email client(s) would have fixed their bug(s). This sort of thing is typical for encrypted email where the recipient always gets to see the attack message.
  
-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 messagingThe 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).+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.
  
-A more fundamental problem with all this is that when used for messaging, PGP uses combined identity/integrity check called [[pgpfan:signatures|signature]]In PGP messaging both the MDC and hypothetical authenticated encryption are irrelevant. So this ends up being a kind of straw manThis would of been much better if it was discussed in terms of how PGP actually works and how these vulnerabilities affect the clients in that context.+//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 possible modification. Then what? You can't just show the user blank screenIt would be a perfectly reasonable approach to warn the user and then show the message in very safe environmentIf 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 OpenPGP standard and implementations of that standard have suffered from security weaknesses of greater significance than EFAIL with no media coverage at allThat is why the media blowup over EFAIL is so odd. I have theory... +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 messagingThe good work done by the security researchers ended up being in sense wastedInherently insecure message content is still serious issue today (2020).
- +
-Encryption "at rest" is pretty much 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" encryptionProtecting information on the network while it is being transferred. In flight encryption is anything but solved problemIf experts were consulted it is very possible that those experts did not care very much about the properties of at rest encryption and would of talked about the much more interesting implications of something like the EFAIL CFB gadget attack for in flight encryption. Those implications would be fairly dire.+A more fundamental problem with all this is that when used for messaging, PGP uses a combined identity/integrity check in the form of a cryptgraphic signatureIn PGP messaging both the MDC and hypothetical authenticated encryption are less important compared to the question of allowing the handling of anonymous (invalid or missing signature) messages in very insecure waySo this ends up being a kind of a straw man. This would of been much better if it was discussed in terms of how PGP actually works and how these vulnerabilities affect the clients in that context.
  
-So this all might just be another example of the problems caused by insufficient research on the part of the technical press...+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, this serves as yet another indication of the poor quality of the technical press.
  
 [[pgpfan:index|PGP FAN index]] [[pgpfan:index|PGP FAN index]]
  
pgpfan/efail.1621613975.txt.gz · Last modified: 2021/05/21 16:19 by b.walzer