3 ms·

> 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

> 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: https://twitter.com/robertjhansen/status/995977877375070209 https://twitter.com/robertjhansen/status/995977877375070209 According to https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060334.html https://lists.gnupg.org/pipermail/gnupg-users/2018-May/06033..., if a gnupg client uses --status-fd and there's no MDC, it will get [GNUPG:] DECRYPTION_FAILED and it won't get the usual [GNUPG:] DECRYPTION_OKAY 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").

tptacek 8y ago
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.
tptacek 8y ago
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.
- cyphar 8y ago
  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).

tptacek 8y ago

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.

tptacek 8y ago

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.

cyphar 8y ago
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).