This is the worst reaction to a serious and interesting vulnerability I think I've ever seen on HN.
The problem being exploited today is that PGP isn't properly authenticated. PGP has an authenticator, but it's simply the SHA-1 of the plaintext appended to the message. Since even that SHA-1 was a later addition to the protocol, mainstream PGP implementations will process messages that lack the hash and decrypt the message. This is broken: a basic property of modern authenticated cryptography is not to present plaintext to the caller until integrity is checked. There are modern AEAD constructions that go through contortions to obtain that property.
The attack is trivial and obvious in retrospect. Attackers strip off the SHA-1 authenticator of a message and then flip bits in the ciphertext to inject HTML that, when rendered, exfiltrates plaintext.
The GPG project objects to the way this attack is characterized. If you strip the SHA-1 hash off a message, GPG will print a warning. But popular mainstream GPG clients don't honor that warning, which doesn't say "Stop, don't process this plaintext I am showing you", but rather "message was not integrity protected". The fact is, there isn't 1 cryptography engineer in 10 that knew exactly what GPG's behavior with a stripped MDC was or how they should check for it.
This is, to me, an almost perfect analog of the event where it was revealed that the curl API didn't check TLS certificates on CURL_SSL_VERIFYHOST=1, but that was OK because the man page said you should use CURL_SSL_VERIFYHOST=2 if you wanted checking. Sure, programming languages cast "true" to 1, and there was literally no meaningful distrinction between 0 and 1 in curl's design, and, sure, dozens of applications were made insecure by that design decision, but, really, it's in the man page, so they should have known better.
Is "don't render plaintext when an MDC isn't present in the message" in the GPG man page?
Other people object because this exploit depends on HTML email to function. It's a vulnerability with HTML email readers, not PGP! That's an even dumber objection. It is precisely analogous to the argument that BEAST and CRIME and Lucky13 weren't vulnerabilities in TLS, because, after all, they depended on browser HTTP behavior in order to function.
The right thing for GPG to have done was to not render plaintext at all if a valid MDC wasn't included in the message. To provide for compatibility and diagnostics in the vanishingly rare cases where it would be needed, they could have had a flag to restore the current insecure behavior. But, like curl, they did the opposite of the right thing, and now they're blaming downstream while implicitly doubling down on their own broken behavior. Not encouraging.
Finally: several people, including the GPG project apparently, are claiming that the researchers behind this work didn't reach out to them. But Werner Koch himself said that the researchers reached out on November 24th of last year.
This is a shitshow, but it's also probably going to be the best crypto attack of the year. Be careful dismissing it; I think that won't be a good look in the long run.
> But popular mainstream GPG clients don't honor that warning, which doesn't say "Stop, don't process this plaintext I am showing you", but rather "message was not integrity protected".
As more information is coming out, it begins to seem that this is not the case: it looks like most GPG clients do detect the warning/error.
Looking at the table in the paper, most clients weren't vulnerable when using GPG rather than S/MIME.
Thunderbird is listed as vulnerable and would count as a popular mainstream client using GnuPG, but it appears that it (ie, enigmail) is not in fact vulnerable:
Further, according to the paper gnupg "returns an error code" in this case, which I take to mean a nonzero exit status.
It that's true, I don't think the situation is at all as bad as you make out.
AIUI using --status-fd has been the usual thing for clients for a decade or so (it isn't a matter of "oh, didn't you know you should use --status-fd, I'm sure it's in the small print somewhere").
Thunderbird and Apple Mail/GPGTools, two of the most popular PGP mail clients, are vulnerable. The table in the paper makes the situation look better than it is by displaying niche clients with very few users alongside the major clients that everybody uses.
Like I said upthread: the right answer (it's not even debatable; cryptography engineers deliberately design crypt constructions to have this property) is not to provide unauthenticated plaintext to callers at all. This isn't news. Whatever dumb warnings GPG prints are besides the point.
Incidentally: I'm sure there's some version of GPG that doesn't print DECRYPTION_OKAY when the MDC is stripped, but if I encrypt --disable-mdc and then decrypt --status-fd 1, I get DECRYPTION_OKAY and an exit code of 0.
I just tried it on my machine (I'm also using gpg 2.2.7) and I got DECRYPTION_FAILED when I do the following:
% gpg --version
gpg (GnuPG) 2.2.7
libgcrypt 1.8.2
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Home: /home/cyphar/.gnupg
Supported algorithms:
Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2
% gpg --encrypt --disable-mdc input --output output
% gpg --decrypt --status-fd 1 --output should_not_exist output | grep DECRYPTION_FAILED
[GNUPG:] DECRYPTION_FAILED
% echo $?
2
% diff -s input should_not_exist
Files input and should_not_exist are identical
However (as you can see above), it looks like GPG outputs to the file when it shouldn't (and Werner said that it doesn't so there's definitely a bug here).
The reaction is the result of when people's expectations from reading about the attack do not match the actual impact. It has been presented as a fundamental issue with PGP with the recommendation to uninstall and stop using anything associated with it.
I use such programs every day, have developed software which directly use GPG, and administrate servers that depend on GPG every day. Not a single use case is affected by EFail. GPG can still be used by Debian maintainers to sign packages and emails, backups can be encrypted, passwords stored in managers, and so on. Even encrypted email, which is the target of the exploit, have minimal or no impact on me since everyone I know who communicates with encrypted emails have HTML turned off and get big massive warning when the signature is missing (or failed).
EFail can be describe in a single sentence: unsigned PGP data will only give warning when MDC is missing, potentially leaking plaintext in mail clients that render HTML. The scope of this looks to be quite small and a far cry from the suggested idea to uninstall GPG and abandon everything it has touched.
> If you strip the SHA-1 hash off a message, GPG will print a warning.
That's far from the whole story. If you strip off the authentication, GPG will fail with an error. Not a warning message.
(Over a socket, gpg will have started sending real data before failing, due to a bad and ancient design. OpenPGP can improve here, so let's point out the real problems instead of making up simpler ones for the sake of a good story.)
If your mail client supports encrypted email silently ignoring errors there's going to be more attacks possible than this one. And if you're parsing untrusted HTML with Outlook 2007, well, that might be problematic in itself.
I don't think anyone is dismissing the attack itself, but the communication around it could have been a little better. Most use of GPG takes place outside of MUAs.
Nobody is arguing against that, so there's really no one to convince.
What's being argued against are statements like "gpg doesn't fail on unauthenticated messages", and "stop using gpg with email" where the former just isn't true and the latter isn't very helpful seeing how the vast majority of gpg usage is things like git workflows which are completely unaffected by this.
Everybody who argues that clients should be more careful checking warning messages and error codes and therefore this isn't a GPG problem is in fact arguing that.
I don't see why we shouldn't hold clients accountable for not checking error codes from a cryptographic tool. Would you have the same opinion if a client didn't check the error code of 'gpg --verify' -- and thus accepted all signed messages as being valid? I think it's fair to say that there is more than one issue at play here.
FWIW, I completely agree that AEAD should have been added to PGP a long time ago and it's asinine that it hasn't been done yet. Not to mention that it's vulnerable to surreptitious forwarding, and the packet format is insanely complicated and has lots of edge-cases that mean that everyone has to emulate GPG in order to work properly. These things concerned me so much that I decided to use ChaCha20-Poly1305 instead of PGP for a recent project. (I was skeptical of this vulnerability when I first read it, but after sleeping on it and reading comments like yours I decided I was mistaken -- especially since .)
You are being very confrontative for no apparent reason. Arguing that mail clients should not hide decryption errors from users is not "in fact" arguing that gpg should keep leaving plaintext fragments around on errors. Far from it.
But it does not matter how perfect encryption tool you can design if your mail client displays a signature as valid when it is in fact not valid.
If you have constructive opinions on how gpg implements AEAD constructs then why not take them to the mailing list? There are plenty of know-it-all personalities in the open source community, but Werner is not one of them.
The problem being exploited today is that PGP isn't properly authenticated. PGP has an authenticator, but it's simply the SHA-1 of the plaintext appended to the message. Since even that SHA-1 was a later addition to the protocol, mainstream PGP implementations will process messages that lack the hash and decrypt the message. This is broken: a basic property of modern authenticated cryptography is not to present plaintext to the caller until integrity is checked. There are modern AEAD constructions that go through contortions to obtain that property.
The attack is trivial and obvious in retrospect. Attackers strip off the SHA-1 authenticator of a message and then flip bits in the ciphertext to inject HTML that, when rendered, exfiltrates plaintext.
The GPG project objects to the way this attack is characterized. If you strip the SHA-1 hash off a message, GPG will print a warning. But popular mainstream GPG clients don't honor that warning, which doesn't say "Stop, don't process this plaintext I am showing you", but rather "message was not integrity protected". The fact is, there isn't 1 cryptography engineer in 10 that knew exactly what GPG's behavior with a stripped MDC was or how they should check for it.
This is, to me, an almost perfect analog of the event where it was revealed that the curl API didn't check TLS certificates on CURL_SSL_VERIFYHOST=1, but that was OK because the man page said you should use CURL_SSL_VERIFYHOST=2 if you wanted checking. Sure, programming languages cast "true" to 1, and there was literally no meaningful distrinction between 0 and 1 in curl's design, and, sure, dozens of applications were made insecure by that design decision, but, really, it's in the man page, so they should have known better.
Is "don't render plaintext when an MDC isn't present in the message" in the GPG man page?
Other people object because this exploit depends on HTML email to function. It's a vulnerability with HTML email readers, not PGP! That's an even dumber objection. It is precisely analogous to the argument that BEAST and CRIME and Lucky13 weren't vulnerabilities in TLS, because, after all, they depended on browser HTTP behavior in order to function.
The right thing for GPG to have done was to not render plaintext at all if a valid MDC wasn't included in the message. To provide for compatibility and diagnostics in the vanishingly rare cases where it would be needed, they could have had a flag to restore the current insecure behavior. But, like curl, they did the opposite of the right thing, and now they're blaming downstream while implicitly doubling down on their own broken behavior. Not encouraging.
Finally: several people, including the GPG project apparently, are claiming that the researchers behind this work didn't reach out to them. But Werner Koch himself said that the researchers reached out on November 24th of last year.
This is a shitshow, but it's also probably going to be the best crypto attack of the year. Be careful dismissing it; I think that won't be a good look in the long run.