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 [2022/05/16 19:46] – No one cares about my opinions of media. b.walzerpgpfan:efail [2022/05/16 21:17] (current) – Typo b.walzer
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/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. 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.
 +
 +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.
  
 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).
pgpfan/efail.1652730410.txt.gz · Last modified: 2022/05/16 19:46 by b.walzer