As you might have heard there is a flaw in many popular email clients that allows an attacker to decrypt PGP or S/MIME encrypted email content.
Turn off OpenPGP and S/MIME encryption in your mail client and use an external tool (eg. Keybase) for encryption/decryption by copy-pasting content.
(For Thunderbird) Disallow remote content in messages.
The last 2 just protect you from stumbling into the attack. You can still be exploited if you accept remote content for that particular mail and/or if you manually decrypt the message.
Not much to do with PGP. The flaw is with loading external content in HTML emails. This has always been a way to spy on readers. This is just one of the reasons I prefer text/plain for email.
Mutt doesn't have any of these issues. It handles multipart mime as intended. Not sure if it is affected by the fact that GPG only issues a warning instead of failing in case of a missing MDC. But despite that, it doesn't allow any spying.
Yeah I really don't like all the hyped up coverage about "OMG PGP encryption is broken!!1!" because it's misleading and people are probably still on the safer side using encryption.
On Twitter, some of the infosec people were mentioning that updating your Thunnderbird to 52.7 or Enigmail to the latest version solves the issue for you only i.e any other client/device which runs the old software is still vulnerable to the issue.
Yeah I think that is something that has to be stressed here. All parties in the communication have to be safe.
It's a very simple proposal. The plaintext of every encrypted block is prefaced by an obfuscation string part which prevents the message string part vcoming after it from being part of the EFAIL attribute. The EFAIL can attack each block seperately, but it can't divide and conquer a block itself.
where you can play around with the choices the EFAIL attacker has and the opportunities to defend against it.
It depicts a typical 16 bytes string to be encoded in a single block, but it is safely prefaced by an obfuscation string.
Did I mention it has to be uncompressed? Because compression ruins the boundary alignment. And of course for any reader who doesn't have software to remove the obfuscation parts, the mail is ugly, although still readable.
More technical details are in the document.
I have tried to offer a whole system cost/benefit analysis at the end.
If it were to be implemented it would have to be implemented close to the encryption/decryption, e.g. inside the GnuPG module. That is because aligning the obfuscation string with the encryption block boundary requires close coordination. Too easy to make a mistake otherwise.