Efail or OpenPGP is safer than S/MIME

[Werner Koch]

Hi!

Some may have noticed that the EFF has warnings about the use of PGP out
which I consider pretty overblown. The GnuPG team was not contacted by
the researchers but I got access to version of the paper related to
KMail. It seems to be the complete paper with just the names of the
other MUAs redacted.

Given that the EFF suggests to deinstall GpgOL, we know tha it is not
vulnerable; see see https://dev.gnupg.org/T3714.).

Here is a response I wrote on the weekend to a reporter who inquired on
this problem.

=============
The topic of that paper is that HTML is used as a back channel to create
an oracle for modified encrypted mails. It is long known that HTML
mails and in particular external links like <img href="tla.org/TAG"/>
are evil if the MUA actually honors them (which many meanwhile seem to
do again; see all these newsletters). Due to broken MIME parsers a
bunch of MUAs seem to concatenate decrypted HTML mime parts which makes
it easy to plant such HTML snippets.

There are two ways to mitigate this attack

- Don't use HTML mails. Or if you really need to read them use a
proper MIME parser and disallow any access to external links.

- Use authenticated encryption.

The latter is actually easy for OpenPGP because we started to use
authenticated encryption (AE) since 2000 or 2001. Our AE is called MDC
(Modification detection code) and was back then introduced for a very
similar attack. Unfortunately some OpenPGP implementations were late to
introduce MDC and thus GPG could not fail hard on receiving a mail
without an MDC. However, an error is returned during decrypting and no
MDC is used:

gpg: encrypted with 256-bit ECDH key, ID 7F3B7ED4319BCCA8, created 2017-01-01
"Werner Koch <***@gnupg.org>"
[GNUPG:] BEGIN_DECRYPTION
[GNUPG:] DECRYPTION_INFO 0 7
[GNUPG:] PLAINTEXT 62 1526109594
[GNUPG:] PLAINTEXT_LENGTH 69
There is more to life than increasing its speed.
-- Mahatma Gandhi
gpg: WARNING: message was not integrity protected
[GNUPG:] DECRYPTION_FAILED
[GNUPG:] END_DECRYPTION

When giving a filename on the command line an output file is even not
created. This can't be done in pipe mode because gpg allows to process
huge amounts of data. MUAs are advised to consider the DECRYPTION_FAILED
status code and not to show the data or at least use a proper way to
display the possible corrupted mail without creating an oracle and to
inform the user that the mail is fishy.

For S/MIME authenticated encryption is not used or implemented in
practice and thus there is no short term way to fix this in S/MIME
except for not using HTML mails.

The upshot of this is that OpenPGP messages are way better protected
against such kind of attacks than S/MIME messages. Unless, well, the
MUAs are correctly implemented and check error codes!


Shalom-Salam,

Werner


p.s.
Some cryptographers turn up their nose at the OpenPGP MDC which is an
ad-hoc AE mode from a time before AE received much research. However,
it does it job and protects reliable against this and other attacks.
The next OpenPGP revision will bring a real AE mode (EAX or OCB
depending on key preferences) which has other benefits (early detection
of corrupted messages, speed) but it will takes years before it will be
widely deployed and can can actually be used to create messages.

[Andrew Gallagher]

Post by Werner Koch
The topic of that paper is that HTML is used as a back channel to
create an oracle for modified encrypted mails.

This confirms that my forensic analysis of the wording of the
announcement was sound. ;-)

The good thing is that oracle attacks are *noisy*, so you'll notice when
it happens.

Post by Werner Koch
There are two ways to mitigate this attack
- Don't use HTML mails. Or if you really need to read them use a
proper MIME parser and disallow any access to external links.

Unfortunately HTML mail is commonplace, so never reading an HTML mail
again may be too much to ask.

Post by Werner Koch
- Use authenticated encryption.

So how do we enforce MDC checking at the receiving end? I assume this is
something that has to be handled by the calling program at the moment. I
see that MDC is the default for all modern ciphers, but does that imply
that MDC *checking* is the default? If so, then all we would need to do
is disable non-modern ciphers.

Looks like S/MIME is pretty much buggered though...

[Robert J. Hansen]

Post by Andrew Gallagher
So how do we enforce MDC checking at the receiving end? I assume this is
something that has to be handled by the calling program at the moment.

By default, GnuPG will scream bloody murder if a message lacks an MDC or
if the MDC is invalid. At that point it's up to your email client to
pay attention to the warning and do the right thing. Enigmail 2.0 and
later are fine, but I can't speak for other systems.

Of course, if you're crazy enough to disable the MDC check
("--no-mdc-warning") then all bets are off, but really, you'll get what
you deserve.

Post by Andrew Gallagher
I see that MDC is the default for all modern ciphers, but does that imply
that MDC *checking* is the default?

MDC is an attribute of the packet, not the cipher. By default, all
ciphers in the GnuPG suite use MDC.

Hope this puts your mind at ease. :)

[Andrew Gallagher]

Post by Robert J. Hansen

Post by Andrew Gallagher
I see that MDC is the default for all modern ciphers, but does that imply
that MDC *checking* is the default?

MDC is an attribute of the packet, not the cipher. By default, all
ciphers in the GnuPG suite use MDC.
We hesitate to require the MDC also for old algorithms (3DES, CAST5>
because a lot of data has been encrypted using them in the first
years of OpenPGP.

So if someone sends me a 3DES-encrypted mail it won't check the MDC?
Doesn't gpg still support reading 3DES?

[Robert J. Hansen]

Post by Andrew Gallagher

Post by Robert J. Hansen
We hesitate to require the MDC also for old algorithms (3DES, CAST5>
because a lot of data has been encrypted using them in the first
years of OpenPGP.

So if someone sends me a 3DES-encrypted mail it won't check the MDC?
Doesn't gpg still support reading 3DES?

Let's try it and find out. :)

PS C:\Users\rjh> gpg --recipient 0xB44427C7 --cipher-algo 3DES
--disable-mdc --encrypt --sign foo.cc
gpg: 0xB44427C7: skipped: public key already present
gpg: WARNING: encrypting without integrity protection is dangerous

PS C:\Users\rjh> gpg foo.cc.gpg
gpg: WARNING: no command supplied. Trying to guess what you mean ...
gpg: encrypted with 256-bit ECDH key, ID AA24CC81B8AED08B, created
2017-04-05
"Robert J. Hansen <***@sixdemonbag.org>"
File 'foo.cc' exists. Overwrite? (y/N) y
gpg: Signature made 05/14/18 05:40:46 Eastern Daylight Time
gpg: using EDDSA key 4BF2042AE28F62B81736E8CBA83CAE94D3DC3873
gpg: Good signature from "Robert J. Hansen <***@sixdemonbag.org>" [ultimate]
gpg: aka "Robert J. Hansen <***@enigmail.net>" [ultimate]
gpg: aka "Robert J. Hansen <***@hansen.engineering>"
[ultimate]
gpg: WARNING: message was not integrity protected



... Yep, GnuPG will warn you the message was not integrity protected.
Your email client should see this warning and refuse to render the message.

[Andrew Gallagher]

Post by Robert J. Hansen
... Yep, GnuPG will warn you the message was not integrity protected.
Your email client should see this warning and refuse to render the message.

I tried again using CAST5 instead of MD5 to bypass the smartcard bug.
The news is not good.

```
***@fred:~$ gpg --recipient 0xFB73E21AF1163937 --cipher-algo CAST5
--disable-mdc --encrypt --sign --armor reply.txt
gpg: using "00CC54C6A0C601691AF4931FFB73E21AF1163937" as default secret
key for signing
File 'reply.txt.asc' exists. Overwrite? (y/N) y
***@fred:~$ gpg reply.txt.asc
gpg: WARNING: no command supplied. Trying to guess what you mean ...
gpg: encrypted with 4096-bit RSA key, ID 0x6B09069314549D4B, created
2013-07-02
"Andrew Gallagher <***@andrewg.com>"
File 'reply.txt' exists. Overwrite? (y/N)
Enter new filename: foo
gpg: Signature made Mon 14 May 2018 11:57:17 IST
gpg: using RSA key 291E79A1DC55AE27A52EEF835C1EC404D5906629
gpg: Good signature from "Andrew Gallagher <***@andrewg.com>" [ultimate]
gpg: aka "Andrew Gallagher <***@llagher.net>" [ultimate]
gpg: aka "Andrew Gallagher <***@gmail.com>"
[ultimate]
gpg: aka "Andrew Gallagher
<***@siren.solutions>" [ultimate]
gpg: aka "[jpeg image of size 18803]" [ultimate]
gpg: aka "Andrew Gallagher <***@siren.io>"
[ultimate]
Primary key fingerprint: 00CC 54C6 A0C6 0169 1AF4 931F FB73 E21A F116 3937
Subkey fingerprint: 291E 79A1 DC55 AE27 A52E EF83 5C1E C404 D590 6629
gpg: WARNING: message was not integrity protected
```

So far so good - gnupg correctly throws a warning. But:

```
***@fred:~$ cat reply.txt.asc | mailx ***@andrewg.com -s "test
message"
```

Now in Enigmail, I get a decrypted message with a green bar and no
warnings whatsoever:

```
Enigmail Security Info

Decrypted message
Good signature from Andrew Gallagher <***@andrewg.com>
Key ID: 0xF1163937 / Signed on: 14/05/18, 11:57
Key fingerprint: 00CC 54C6 A0C6 0169 1AF4 931F FB73 E21A F116 3937

Used Algorithms: RSA and SHA512

Note: The message is encrypted for the following User ID's / Keys:
0x6B09069314549D4B (Andrew Gallagher <***@andrewg.com>)
```

So it would appear that Enigmail IS VULNERABLE.

I have reproduced this on debian's 2:1.9.9-1~deb9u1 (v1.9.9) and 2.0.3
on Mac. By comparison, the default cipher (AES) correctly throws a
decryption error in enigmail using the same test systems.

[Robert J. Hansen]

Fascinating. I've thrown it over to Patrick: we'll look into it and get
back in touch soon.

[Andrew Gallagher]

Post by Andrew Gallagher
I tried again using CAST5 instead of MD5 to bypass the smartcard bug.

Argh, I meant to say 3DES of course, not MD5. Sorry.

[Robert J. Hansen]

Post by Andrew Gallagher
Argh, I meant to say 3DES of course, not MD5. Sorry.

It's worth noting, incidentally, the #Efail attack flat-out requires
MIME. So inline PGP messages are not vulnerable, as there's no MIME
parsing pass which can be exploited. So you're *still* safe, although
this is still a bug that should be fixed. ;)

I can recreate the bug; I'll be bringing it up to Patrick soon.

[Robert J. Hansen]

... and Patrick, moving faster than the speed of light, already has the
bug triaged and bounced back. This is actually a GnuPG bug, not an
Enigmail bug. From Patrick:

=====

The problem is that gpg doesn't say anything. I would expect a
DECRYPTION_FAILED message here:

[GNUPG:] ENC_TO 5F5FDF400616A9CF 1 0
[GNUPG:] KEY_CONSIDERED 4F9F89F5505AC1D1A260631CDB1187B9DD5F693B 0
[GNUPG:] KEY_CONSIDERED 4F9F89F5505AC1D1A260631CDB1187B9DD5F693B 0
gpg: WARNING: cipher algorithm CAST5 not found in recipient preferences
[GNUPG:] DECRYPTION_KEY 530187ED159A04E6F53ED1385F5FDF400616A9CF
4F9F89F5505AC1D1A260631CDB1187B9DD5F693B u
[GNUPG:] KEY_CONSIDERED 4F9F89F5505AC1D1A260631CDB1187B9DD5F693B 0
gpg: encrypted with 4096-bit RSA key, ID 5F5FDF400616A9CF, created
2018-01-17
"Patrick Brunschwig <***@enigmail.net>"
[GNUPG:] BEGIN_DECRYPTION
[GNUPG:] DECRYPTION_INFO 0 3
[GNUPG:] PLAINTEXT 62 1526296937
[GNUPG:] PLAINTEXT_LENGTH 4
abc
[GNUPG:] NEWSIG
gpg: Signature made Mon May 14 13:22:17 2018 CEST
gpg: using RSA key 4F9F89F5505AC1D1A260631CDB1187B9DD5F693B
[GNUPG:] KEY_CONSIDERED 4F9F89F5505AC1D1A260631CDB1187B9DD5F693B 0
[GNUPG:] SIG_ID Rh02jRM7bb5K0OOXQaEgmdJF+Bo 2018-05-14 1526296937
[GNUPG:] KEY_CONSIDERED 4F9F89F5505AC1D1A260631CDB1187B9DD5F693B 0
[GNUPG:] GOODSIG DB1187B9DD5F693B Patrick Brunschwig <***@enigmail.net>
gpg: Good signature from "Patrick Brunschwig <***@enigmail.net>"
[ultimate]
gpg: aka "Patrick Brunschwig <***@brunschwig.net>"
[ultimate]
gpg: aka "[jpeg image of size 13251]" [ultimate]
[GNUPG:] VALIDSIG 4F9F89F5505AC1D1A260631CDB1187B9DD5F693B 2018-05-14
1526296937 0 4 0 1 10 00 4F9F89F5505AC1D1A260631CDB1187B9DD5F693B
[GNUPG:] TRUST_ULTIMATE 0 direct
[GNUPG:] VERIFICATION_COMPLIANCE_MODE 23
[GNUPG:] DECRYPTION_OKAY
gpg: WARNING: message was not integrity protected
[GNUPG:] END_DECRYPTION

[Andrew Gallagher]

Post by Robert J. Hansen
The problem is that gpg doesn't say anything. I would expect a

So perhaps the solution is to throw a big warning and prompt when an
integrity check failure is thrown by gnupg? That would mitigate the
current issue, but allow for reading pre-MDC emails as per Werner's
earlier link.

The problem here is that an integrity failure is a serious error when it
occurs in a context where oracle behaviour is possible (such as email),
but it's much less serious when used outside that context. Just because
gnupg says it's only a warning-level offence doesn't mean enigmail
should agree...

[Fiedler Roman]

Post by Andrew Gallagher

Post by Robert J. Hansen
The problem is that gpg doesn't say anything. I would expect a

So perhaps the solution is to throw a big warning and prompt when an
integrity check failure is thrown by gnupg? That would mitigate the
current issue, but allow for reading pre-MDC emails as per Werner's
earlier link.
The problem here is that an integrity failure is a serious error when it
occurs in a context where oracle behaviour is possible (such as email),
but it's much less serious when used outside that context. Just because
gnupg says it's only a warning-level offence doesn't mean enigmail
should agree...

In my opinion, the problem is related to the general gnupg interface design. An optional error or warning is always somehow problematic in interfaces:

1) you have to read and understand the complete documentation to know of any message that may occur

2) if it is not here, you simply do not know, if everything is right, if you just missed the message or an attacker managed to "suppress" it somehow. Makes it easier on the attacker - like here

In my opinion, gnupg would do itself a favour by avoiding optional messages - without any other reference to it. With such a protocol I would expect gnupg to end somehow like ...

[END_STATUS]: Messages: 3, Valid MDCs 2, Signed Messages 2, ...., Warnings: 1, Errors: 0 ... (put here everything you deem important and document it)

This would also prevent many other programming errors: e.g. if gpg claims to have processed 2 signed messages, a client has to verify, that it also received two "GOOD_SIG" messages. If just any of the numbers do not match, any good mail client should bail out immediately, e.g. if warn=1 but the client did not understand the warning.

LG R

PS: A end message as single line sorted JSON dictionary might make parsing less error prone and increase the number of developers really parsing and using them.

[MFPA]

Hi


On Monday 14 May 2018 at 1:33:03 PM, in
<mid:***@S0MSMAIL112.arc.local>,
Fiedler Roman wrote:-

Post by Fiedler Roman
This would also prevent many other programming
errors: e.g. if gpg
claims to have processed 2 signed messages, a client
has to verify,
that it also received two "GOOD_SIG" messages.

What if a message has more than one signature?

[Fiedler Roman]

Post by MFPA
Hi
On Monday 14 May 2018 at 1:33:03 PM, in
local>,
Fiedler Roman wrote:-

Post by Fiedler Roman
This would also prevent many other programming
errors: e.g. if gpg
claims to have processed 2 signed messages, a client
has to verify,
that it also received two "GOOD_SIG" messages.

What if a message has more than one signature?

The status line format should be designed to support those variants to allow a "logical consistency check" of the communication with GnuPG like a message digest allows consistency checking for a cryptographic message. I guess it would be ease for the GnuPG-hardcore developers to define, which fields are required to perform a thorough consistency check.

[Fiedler Roman]

Post by Fiedler Roman
The status line format should be designed to support those variants to
allow a "logical consistency check" of the communication with GnuPG

There is a
DECRYPTION_FAILED
and that is all what it takes.

But this is only a single status code for a very complex decryption/validation process (considering cipher methods, signature methods, local time, trust DBs, signatures, number of messages, ...). When relying on that single code, gpg would need configuration parameters to configure each step of the whole decryption/validation process in a very fine-grained way, so that gpg will know in the end, if it should issue the FAILED or not. I am not sure, if gpg could support implementation/testing/life-cycle-efforts to establish all those parameters and different process models for most of the decryption processes gpg users envision to use gpg for.

If the integrity check fails there
The recipient MUST verify the integrity of the received content
before releasing any information, especially the plaintext of the
content. If the integrity verification fails, the receiver MUST
destroy all of the plaintext of the content.
Unfortunately this can't be done by tools prepared to process huge
amounts of data. And in contrast to the Efail claims this is an
important feature. How would you else do your ZFS backups without
having a way to stream the data to the backup system.

This is just the example of two different, complex decryption/validation processes, that should be supported both. As the definition of the "process" also has implications, what a valid "integrity check" is (see also the discussion about historic messages), I believe, that this is hard to be done by breaking it down to a single 0/1 decision for gpg (which might not know the constraints of the current process in detail). Otherwise a "--allow-non-rfc-5083-streaming-mode" flag should already exist to tell gpg more about the decryption process constraints (to distinguish between the two different process models, that should be implemented already, just for your RFC-citation from above).

...

LG Roman

[Andrew Gallagher]

Post by Fiedler Roman
I am not sure, if gpg could support implementation/testing/life-cycle-efforts to establish all those parameters and different process models for most of the decryption processes gpg users envision to use gpg for.

Why do we need a plethora of configuration parameters to selectively turn off various parts of a security protocol? Why should we even encourage such a thing? With security, either everything seems to be ok, or it’s broken in such a way that it’s potentially an utter disaster. And quite probably both simultaneously.

The only reasonable use case for selective disabling of security protocol features is for backwards compatibility. That doesn’t require fine grained control, just a version number. And even then, it opens up the possibility for user error.

I’m going to preemptively quote RJH here before he gets around to it. Use the defaults! ;-)

A

[Robert J. Hansen]

Post by Andrew Gallagher
I’m going to preemptively quote RJH here before he gets around to it. Use the defaults! ;-)

:)

[Fiedler Roman]

Post by Fiedler Roman

Post by Fiedler Roman
I am not sure, if gpg could support implementation/testing/life-cycle-efforts

to establish all those parameters and different process models for most of the
decryption processes gpg users envision to use gpg for.
Why do we need a plethora of configuration parameters to selectively turn
off various parts of a security protocol? Why should we even encourage such
a thing? With security, either everything seems to be ok, or it’s broken in such
a way that it’s potentially an utter disaster. And quite probably both
simultaneously.

In my opinion it is hard to find such a "one size fits all" solution. Like Werner's example: disabling decryption streaming operation might increase security for some use-cases (validation before decryption&output) but might make others impossible, like streaming of backups (decryption&output before final validation). So you need something on the interface to support that non-standard behavior, deviate from the default.

Post by Fiedler Roman
The only reasonable use case for selective disabling of security protocol
features is for backwards compatibility. That doesn’t require fine grained
control, just a version number. And even then, it opens up the possibility for
user error.

Yes, another example for different use-cases and hence different process model requirements in software.

Post by Fiedler Roman
I’m going to preemptively quote RJH here before he gets around to it. Use the
defaults! ;-)

Then why are there already so many command line options for decryption/validation gpg not just one: "--insecure"? From my point of view, monopolists might be able to push one set of defaults but the open source software ecosystem might work differently: those projects survive, that enable that many use-cases per development effort, so that they find sufficient developers/funds to support development. If they drift off, the project will fork/another project might take over.

So gpg has to watch out for the optimum point between following extremes:

1) Only supporting one standard use-case with default settings (thus increasing security but loosing users)

2) Supporting many use-cases via different gpg-internal decryption/validation-process models (requiring loads of parameters, complex models, lot of implementation, risk to invoke gpg with wrong parameters)

3) Supporting one generic use-case/process model and leaving it to the caller (other side of interface) to decide what to make from it (risk, that other party just does not do it right - e.g. ignores a warning like with Efail)


Assuming, that the ideal point would be somewhere in between, supporting only a single FAIL status like old-style shell commands might not be sufficient to attract sufficient users from world 1, 2, 3 above.

LG Roman

[Werner Koch]

Post by Fiedler Roman
In my opinion it is hard to find such a "one size fits all"
solution. Like Werner's example: disabling decryption streaming

The goal of the MDC is to assure that the message has been received
exactly as the sender set it. Thus there is just a binary decision:
Okay or Fail. Everything is like you have been dropped at boot time
into manual fsck mode - you can do something about it or you just
irginore things and restore the partition.

Post by Fiedler Roman
streaming of backups (decryption&output before final validation). So
you need something on the interface to support that non-standard
behavior, deviate from the default.

It is already there. If you use "--output FILE" the file is either
created or not. Your choice.


Shalom-Salam,

Werner

[Andrew Gallagher]

Post by Robert J. Hansen
It's worth noting, incidentally, the #Efail attack flat-out requires
MIME. So inline PGP messages are not vulnerable, as there's no MIME
parsing pass which can be exploited. So you're *still* safe

I wouldn't be that confident. I haven't tested PGP/MIME yet simply
because it's harder to construct the test message. The important point
is that we can't rely on gnupg's message integrity check to prevent
automatic decryption - so there's no good reason to believe that PGP
mail is any less vulnerable than S/MIME.

Note to anyone coming fresh to the conversation: disabling the display
of HTML email is *probably* a sufficient mitigation in either case.

[Andrew Gallagher]

Post by Robert J. Hansen
... Yep, GnuPG will warn you the message was not integrity protected.
Your email client should see this warning and refuse to render the message.

Yes, but that's not as serious as the error thrown for an unprotected
AES message. Do mail clients treat such warnings as fatal? Should mail
clients *ever* treat mere warnings as fatal?

I can't test here because I'm suffering from https://dev.gnupg.org/T3576
- guess that means I'm immune! ;-)

[Robert J. Hansen]

The following is what I wrote to a journalist covering the story:

=====

We've known about problems in OpenPGP's feedback mode for at least
thirteen years. (See https://eprint.iacr.org/2005/033.pdf for an
example.) The OpenPGP working group resolved these problems by adopting
modification detection codes (MDCs). GnuPG properly implements MDCs and
gives clear and unambiguous warnings if a message lacks an MDC. The
paper authors acknowledge that if an email client handles these warnings
sensibly, their attack fails.

In other words, their attack is completely dependent on email clients
handling our warnings in a broken way. Great: that they've found bugs
in major email clients is a good thing, but where's the flaw in the
OpenPGP protocol or GnuPG's implementation of it? And does this really
deserve the hype-tastic title "Breaking S/MIME and OpenPGP Email
Encryption" when it really doesn't do that?

In grad school my adviser told me to follow Napoleon's Rule in paper
titles. "If you tell the world you're going to conquer Russia, you'd
better conquer Russia." This paper doesn't deliver on what its title
promises.

[Werner Koch]

Hi!

I digged in my mail archives and found a discussion with Sebastian
Schinzel about a work in progress thing which turned out to not being a
GnuPG problem. Here is a timeline with my messages.

On 2017-11-24 we were asked for the encryption keys of the security at
gnupg.org address. On the same day we received an advisory titled

Efail: Full Plaintext Recovery in PGP via Chosen-Ciphertext Attack

with the notice

We ask you kindly to keep this advisory and the information therein
confidential until we find a nearby date for coordinated public
disclosure!

A few hours later my reply went out:

--8<---------------cut here---------------start------------->8---
Thanks for sharing the paper with us. I may have missed something but I
can't see that you considered the use of MDC as specified in RFC-4880,
5.13 (Sym. Encrypted Integrity Protected Data Packet (Tag 18)). Here is
the timeline of the introduction of the MDC.

AES conference March 2000

* Meeting between PRZ, Jon Callas, and me to discuss how to make our
encryption mode more robust without requiring signed content.

GnuPG 1.0.3 (2000-09-18)

* Twofish and MDC enhanced encryption is now used. PGP 7 supports
this. Older versions of GnuPG don't support it, so they should be
upgraded to at least 1.0.2

GnuPG 1.0.7 (2002-04-29)

* The MDC feature flag is supported and can be set by using
the "updpref" edit command.

GnuPG 1.1.92 (2002-09-11)

* The use of MDCs have increased. A MDC will be used if the
recipients directly request it, if the recipients have AES,
AES192, AES256, or TWOFISH in their cipher preferences, or if
the chosen cipher has a blocksize not equal to 64 bits
(currently this is also AES, AES192, AES256, and TWOFISH).

* GnuPG will no longer automatically disable compression when
processing an already-compressed file unless a MDC is being
used. This is to give the message a certain amount of
resistance to the chosen-ciphertext attack while communicating
with other programs (most commonly PGP earlier than version 7.x)
that do not support MDCs.

GnuPG 2.1.9 (2015-10-09)

* gpg: Fail with an error instead of a warning if a modern cipher
algorithm is used without a MDC.

Your attack should not work if the MDC is in use. And it is always in
use for AES. In any case active content in mails should be discouraged
in all mails (see my mail headers ;-).

We are slowly working in the WG on RFC4880bis to introduce a new
encryption mode. Unfortunately there are heavy opinions on the use of
OCB mode and thus we may need to come up with the choice of two new
modes. Based on the experience with MDC I expect that the deployment of
a new mode will take at least 3 years. Until then I hope that the MDC
hack will serve us fine.
--8<---------------cut here---------------end--------------->8---

In response to that they said that they did a simple rollback to the
non-MDC encryption. This is a pretty old thing which we are aware of
and the reasons why a warning has always been printed in that case.

In a further response the same day they noted that gpg indeed returns an
error code but that Enigmail still displays the message. My reply on
that went out on 2017-11-26:

--8<---------------cut here---------------start------------->8---
Enigmail does something wrong the. Here is the respective code in GnuPG:

else if (!result
&& !opt.ignore_mdc_error
&& !pkt->pkt.encrypted->mdc_method
&& openpgp_cipher_get_algo_blklen (c->dek->algo) != 8
&& c->dek->algo != CIPHER_ALGO_TWOFISH)
{
/* The message has been decrypted but has no MDC despite that a
modern cipher (blocklength != 64 bit, except for Twofish) is
used and the option to ignore MDC errors is not used: To
avoid attacks changing an MDC message to a non-MDC message,
we fail here. */
log_error (_("WARNING: message was not integrity protected\n"));
if (opt.verbose > 1)
log_info ("decryption forced to fail\n");
write_status (STATUS_DECRYPTION_FAILED);

which was introduced with

commit 625e292108cc0fd9077769587a8c22abe7805e33
AuthorDate: Tue Oct 6 09:40:57 2015 +0200

gpg: Fail decryption for AES etc message w/o MDC.

* g10/mainproc.c (proc_encrypted): Fail for modern messages w/o MDC.
--

This change turns the missing MDC warning into an error if the message
has been encrypted using a cipher with a non-64 bit block length cipher
and it is not Twofish.

We can assume that such messages are created by code which should have
been able to create MDC packets. AES was introduced with 1.0.3 on
2000-09-18 shortly after MDC (1.0.2 on 2000-07-12). We need to
exclude Twofish because that might have been used before MDC.


GPGME based applications should get it correct because GPGME detects the
STATUS_DECRYPTION_FAILED and flags the result as failed.
--8<---------------cut here---------------end--------------->8---

On 2017-11-29 we got a short mail asking for a phone call. It might be
that I did not reply to that but in any case my office phone number is
easy to lookup. I did not get a phone call.

Since then we have not seen any more communication - not even about the
proposed coordinated public disclosure. Thus I closed this issue in
December and forgot about it.

On 2018-04-27 I received another paper via a Kmail developer which had a
different title than the one from November

*** DO NOT PUBLISH OR SHARE ON PUBLIC MAILING LISTS ***
Efail: Breaking S/MIME and OpenPGP Email Encryption using
Exfiltration Channels

and no author names etc. The GnuPG team discussed this but did not see
that any action was required. In particular because due to the
redaction we were not able to contact and help the developers of other
MUAs which might be affected.


Shalom-Salam,

Werner

[Robert J. Hansen]

If I read it correctly, it also has another attack, no longer based on
user agents concatenating HTML mime parts, but also based on CFB
gadgets. Which, here, looks like a flaw in the OpenPGP specification
indeed (and thus GnuPG's implementation of it), and not in MUAs?

MDCs stop it dead. If a message has no MDC or an invalid MDC, GnuPG
_will_ warn you about it. Now, whether your email client does the right
thing upon being warned, that's between you and your email client...

[Andrew Gallagher]

Post by Robert J. Hansen

If I read it correctly, it also has another attack, no longer based on
user agents concatenating HTML mime parts, but also based on CFB
gadgets. Which, here, looks like a flaw in the OpenPGP specification
indeed (and thus GnuPG's implementation of it), and not in MUAs?

MDCs stop it dead. If a message has no MDC or an invalid MDC, GnuPG
_will_ warn you about it. Now, whether your email client does the right
thing upon being warned, that's between you and your email client...

This all exposes one of the difficulties with trying to manage security
software in a decentralised ecosystem. We end up in arguments over whose
responsibility it is when the joints come apart.

I would humbly suggest that we stop worrying about which side of the
GPG/MUA fence the ball is on, and fix it on *both* sides. That means:

1. change the default behaviour of GPG so that any integrity failure is
fatal by default, even for old ciphersuites (we could have a flag to
override for those that really need it). For belt and braces, disable
the obsolete ciphersuites by default (again, we can provide an
override). We have assumed that so long as you don't *generate* poor
crypto you're safe. That's just not true.

2. AND the MUAs need to make sure they fail hard on integrity warnings,
because old versions of GPG may hang around for a while. Also ensure
that links aren't followed by default, that the capabilities of
encrypted HTML mail are constrained, etc.

The PGP ecosystem will survive this, because the tech is in place. The
enforcement has just erred a little too far on the side of
compatibility. It's all fixable.

[Werner Koch]

Post by Andrew Gallagher
This all exposes one of the difficulties with trying to manage security
software in a decentralised ecosystem. We end up in arguments over whose

That is actually easy compared to a system which is also designed to
protect data at rest. Some users may want to restore their 2 year old
backup to fix a problem with garbled tapes; some may want to read the
real documents about WMD from 2003; some may even want to be able to
decrypt their old love letters at the time of their silver wedding.

Post by Andrew Gallagher
1. change the default behaviour of GPG so that any integrity failure is
fatal by default, even for old ciphersuites (we could have a flag to

I am all in favor of this and even considered to that some time ago.
However, not too long ago we removed support for PGP-2 keys which
unfortunately resulted in lots of angry mails from people who now think
they need to use gnupg 1.4 every day because they seem to read mails
From the last century on a regular base. Well, they think and they were
quite vocal. Now telling them they need to enable an option to read
certain not that old mail (e.g. creating by other OpenPGP
implementations) will a) lead to even more angry mails and b) they will
keep on using that option for all mails. Thus my tentative plan was to
make the next major version hard fail on messages without MDC and slowly
start using our forthcoming AEAD encryption mode.

Well okay, with the new support of the Ehtmlfail paper we could now
point to that paper and always hard error out if no MDC is used even for
old algorithms. Shall we consider this?

Post by Andrew Gallagher
the obsolete ciphersuites by default (again, we can provide an

They are not used by default. 3DES is a MUST algorithm and will only be
deprecated with RFC_4990bis and thus GnuPG 2.3.

Post by Andrew Gallagher
2. AND the MUAs need to make sure they fail hard on integrity warnings,
because old versions of GPG may hang around for a while. Also ensure

Fortunately the majority of them do.

Post by Andrew Gallagher
that links aren't followed by default, that the capabilities of
encrypted HTML mail are constrained, etc.

Yes please, I consider this the minimum requirement for HTML based
mails. Why sending email when you need to go online for reading them.
And also disallow Javascript. How you only need to convince the mail
content designers that they can't simply use the web page and send it as
mail. That will be the hard part.

Post by Andrew Gallagher
The PGP ecosystem will survive this, because the tech is in place. The

I am not so sure for S/MIME - but that is whishful thinking ;-)


Shalom-Salam,

Werner

[Lars Noodén]

On 05/14/2018 08:32 PM, Werner Koch wrote:
[snip]

Post by Werner Koch
I am all in favor of this and even considered to that some time ago.
However, not too long ago we removed support for PGP-2 keys which
unfortunately resulted in lots of angry mails from people who now think
they need to use gnupg 1.4 every day because they seem to read mails
From the last century on a regular base.

[snip]

How feasible would it be to strip or disable encryption in a fork of an
old version and just leave it capable of decryption? And would that
address their use-cases for the old mails while dealing with the
security concerns arising from the outdated ciphers? So it could be a
gnupg-encore fork for archival purposes.

/Lars

[Andrew Gallagher]

Post by Lars Noodén
How feasible would it be to strip or disable encryption in a fork of an
old version and just leave it capable of decryption?

I’m sure it’s feasible, but it doesn’t address this issue or any other kind of oracle, replay or chosen-text attack. If today has taught us anything, surely it is that flaws in decryption are just as dangerous as flaws in encryption.

A

[Andrew Gallagher]

Post by Werner Koch

Post by Andrew Gallagher
This all exposes one of the difficulties with trying to manage security
software in a decentralised ecosystem. We end up in arguments over whose

That is actually easy compared to a system which is also designed to
protect data at rest. Some users may want to restore their 2 year old
backup to fix a problem with garbled tapes; some may want to read the
real documents about WMD from 2003; some may even want to be able to
decrypt their old love letters at the time of their silver wedding.

Indeed. This is why data must be treated as a living object. If tape drive technology moves on, the data must be moved on. Same with file formats, encryption systems and dying raid arrays. Librarians and archaeologists understand the process of care and feeding for physical artefacts. Digital artefacts are no exception.

Post by Werner Koch

Post by Andrew Gallagher
1. change the default behaviour of GPG so that any integrity failure is
fatal by default, even for old ciphersuites (we could have a flag to

I am all in favor of this and even considered to that some time ago.
However, not too long ago we removed support for PGP-2 keys which
unfortunately resulted in lots of angry mails from people who now think
they need to use gnupg 1.4 every day because they seem to read mails
From the last century on a regular base. Well, they think and they were
quite vocal. Now telling them they need to enable an option to read
certain not that old mail (e.g. creating by other OpenPGP
implementations) will a) lead to even more angry mails and b) they will
keep on using that option for all mails. Thus my tentative plan was to
make the next major version hard fail on messages without MDC and slowly
start using our forthcoming AEAD encryption mode.
Well okay, with the new support of the Ehtmlfail paper we could now
point to that paper and always hard error out if no MDC is used even for
old algorithms. Shall we consider this?

Yes, absolutely. I think this is the easiest and most effective technical mitigation available. If people have a problem with data archival, they should be pointed to a guide on how to re-encrypt their sensitive data in a modern format. Their data is probably horrendously insecure anyway, so we’re doing them a favour. :-)

If we believe that there will be more encrypted messages in the future than there have been in the past, then protecting those future messages takes priority, especially if an upgrade pathway exists.

Post by Werner Koch

Post by Andrew Gallagher
the obsolete ciphersuites by default (again, we can provide an

They are not used by default. 3DES is a MUST algorithm and will only be
deprecated with RFC_4990bis and thus GnuPG 2.3.

OK.

As an aside, I think we have to be careful about the meaning of “use”. They are not used by default in encryption, but they are in decryption. I’ve had multiple conversations today over this ambiguity.

Post by Werner Koch

Post by Andrew Gallagher
2. AND the MUAs need to make sure they fail hard on integrity warnings,
because old versions of GPG may hang around for a while. Also ensure

Fortunately the majority of them do.

Yes, nevertheless I don’t think it is good practice to rely on one single layer for security protection, because then we have a single point of failure. With two interacting systems, neither should assume that the other is behaving correctly. Trust but verify, belt and braces, measure twice cut once.

That means security policy should be enforced by both applications, so that a single failure doesn’t blow open the entire system. This is especially important when there are potentially unlimited kinds of systems, of varying compliance, that could be involved in any interaction.

I think also that we should be mindful that “be strict about what you send but liberal about what you receive” is great advice for interoperability, but absolutely disastrous advice for security.

Post by Werner Koch

Post by Andrew Gallagher
that links aren't followed by default, that the capabilities of
encrypted HTML mail are constrained, etc.

Yes please, I consider this the minimum requirement for HTML based
mails. Why sending email when you need to go online for reading them.
And also disallow Javascript. How you only need to convince the mail
content designers that they can't simply use the web page and send it as
mail. That will be the hard part.

Another thing we need to learn from this is that HTML elements may be a privacy concern in plaintext mail, but they are a *security* concern in encrypted mail. The context changes the risk profile. So mail clients (tbird) that disable risky HTML (such as loading images) by default but provide user overrides are doing so justifiably from a privacy standpoint, where a warning about the privacy implications may be sufficient.

But encryption has to change this risk analysis - in an encrypted mail there can’t be an easy override because the stakes are much higher and people are easily tempted. When we have a system like tbird+enigmail+gpg where there are *three* interacting components, this coordination becomes really difficult. At the very least, enigmail must be able to enforce a stricter content hygiene policy on encrypted HTML mail than tbird applies to plaintext HTML.

How *feasible* this might be is a question aimed at the enigmail devs in the list. :-)

Post by Werner Koch

Post by Andrew Gallagher
The PGP ecosystem will survive this, because the tech is in place. The

I am not so sure for S/MIME - but that is whishful thinking ;-)

:-P

A

[Bernhard Reiter]

Post by Andrew Gallagher

Post by Werner Koch
Well okay, with the new support of the Ehtmlfail paper we could now
point to that paper and always hard error out if no MDC is used even for
old algorithms. Shall we consider this?

Yes, absolutely. I think this is the easiest and most effective technical
mitigation available.

I completely agree, the paper shows problems with the current specifications,
backend and frontend implementations. We should (help to) fix it in all three
places.

Best for GnuPG would be to not display contents which did not have integrity
protection by either:
a) MDC
b) AEAD
c) a signature over the whole contents from someone where it has been
encrypted to (if this is feasable to detect).

Post by Andrew Gallagher
With two interacting systems, neither should assume that the other
is behaving correctly.

Note that it is not just email clients that are in danger.
If you get a file with active contents (e.g. an HTML file, or a video
reference) and you decrypt it as data on the command line it is fine up to
there. But once you try to read or open it, you'll have a backchannel.

Post by Andrew Gallagher

Post by Werner Koch
Yes please, I consider this the minimum requirement for HTML based
mails. Why sending email when you need to go online for reading them.
And also disallow Javascript. How you only need to convince the mail
content designers that they can't simply use the web page and send it as
mail. That will be the hard part.

Another thing we need to learn from this is that HTML elements may be a
privacy concern in plaintext mail, but they are a *security* concern in
encrypted mail.

People clearly seem to want a way to send files with potentially active
elements. So in my opinion the crypto standards and backends should be
designed to allow this in the safest way possible.

Best Regards,
Bernhard

[Bernhard Reiter]

.. to only display contents if there was integrity protection by either

Post by Bernhard Reiter
a) MDC
b) AEAD
c) a signature over the whole contents from someone where it has been
encrypted to (if this is feasable to detect).

if users or frontends still want to show contents, to me it seems good if

* there is a very explicit disable-safety-button
* ideally working only for one encryption, so it has been issued explicitely
each time
* a warning against active content which may become active much later
* an attempt to prevent active backchannels as much as possible
(e.g. by only showing plain text and saving as plain-text suffix)

would need to be put in the documentation so GnuPG frontends know.

Regards,
Bernhard

[Bernhard Reiter]

Post by Bernhard Reiter
.. to only display contents if there was integrity protection by either

[..]

I'll continue the discussion about what should technically be done

Post by Bernhard Reiter
if users or frontends still want to show contents, to me it seems good if

[..]

to frontends included with Gpg4win on
https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/gpg4win-devel

Regards,
Bernhard

[Andrew Gallagher]

Post by Bernhard Reiter

Post by Andrew Gallagher
Another thing we need to learn from this is that HTML elements may be a
privacy concern in plaintext mail, but they are a *security* concern in
encrypted mail.

People clearly seem to want a way to send files with potentially active
elements. So in my opinion the crypto standards and backends should be
designed to allow this in the safest way possible

I’m not saying that active elements should be banned outright, just that they should be handled more carefully in the encrypted case than they are in plaintext.

So for example, I could change my thunderbird settings to display active content by default, or tbird could let me click on a handy button to load foreign images. This is reasonable UC behaviour if we are only concerned about the privacy implications.

But I would argue that it may not be reasonable if we have serious security concerns, so we may want to suppress the handy “load images” button or have a separate config setting for “display remote content in encrypted messages by default”. The point being that the context determines the measures that we may want to take.

A

[Bernhard Reiter]

I’m not saying that active elements should be banned outright, just that
they should be handled more carefully in the encrypted case than they are
in plaintext.
so we may want to suppress the handy “load images” button or have
a separate config setting for “display remote content in encrypted messages
by default”. The point being that the context determines the measures that
we may want to take.

I agree.
My point is that it is legitimate to send files with potentially active
contents. And they are a problem even outside of an email application.
So making integrity checks a hard requirement and do not display anything
in the failed case seems a good idea to me.

Bernhard

[Werner Koch]

Post by Andrew Gallagher
If we believe that there will be more encrypted messages in the future than there have been in the past, then protecting those future messages takes priority, especially if an upgrade pathway exists.

Unless you change the default options of gpg or you encrypt to at least
one old key there is no problem at all. I assume that 99.9% of all GPG
created messages are safe because they use MDC in away which allows the
receiving GPG to hard fail if the MDC was stripped.

Post by Andrew Gallagher
As an aside, I think we have to be careful about the meaning of “use”. They are not used by default in encryption, but they are in decryption. I’ve had multiple conversations today over this ambiguity.

Right. However, if someone sends you a message using an old algorithm
you can't do anything about it. We can assume that those who do not
have sane software or configuration also miss other important security
precautions so that there are many other and easier ways to get to the
plaintext than an active MitM or a replay of modified messages.

Post by Andrew Gallagher
I think also that we should be mindful that “be strict about what you send but liberal about what you receive” is great advice for interoperability, but absolutely disastrous advice for security.

I fully agree.

Post by Andrew Gallagher
But encryption has to change this risk analysis - in an encrypted mail
there can’t be an easy override because the stakes are much higher and
people are easily tempted. When we have a system like

Right. When you use encryption you can make a concious decision to keep
the data confidential or public.

Post by Andrew Gallagher
tbird+enigmail+gpg where there are *three* interacting components,

Plugins are a real problem but I think we are doing anywat great given
that the native encryption stuff is not much better (Efail tested in
Outlook the internal S/MIME which is vulnerable and the GpgOL plugin
for OpenPGP which is not vulnerable).

I would really be good if the Mozilla folks would work closer together
with Enigmail and not reject the idea of including OpenPGP which they
more or less did since about 2000.


Shalom-Salam,

Werner

[Andrew Gallagher]

Post by Werner Koch
Unless you change the default options of gpg or you encrypt to at least
one old key there is no problem at all. I assume that 99.9% of all GPG
created messages are safe because they use MDC in away which allows the
receiving GPG to hard fail if the MDC was stripped.

This is a very good point that I think has been overlooked in the chaos.
There are many different things going on here that overlap and interact.

The only emails that are in danger of being leaked *via the MDC issue*
are those that were originally encrypted using one of the obsolete
cipher suites. Anything encrypted with AES should be immune. This is
because:

a) gnupg only falls back to compatibility mode for messages that use
obsolete ciphers, and

b) If you inject an AES cipherstream into a 3DES or CAST5 message (which
is how the CFB gadget trick works), you get garbage.

BUT

We should also be very careful to note that none of this discussion
thread applies to the MIME concatenation vulnerability, which is a
problem in Thunderbird and other mail clients, and which cannot be
solved by gnupg.

[Werner Koch]

Post by Andrew Gallagher
We should also be very careful to note that none of this discussion
thread applies to the MIME concatenation vulnerability, which is a
problem in Thunderbird and other mail clients, and which cannot be

While we are at that point. Can we get a definive answer whether TB
loads external content by default, that is honors the href, erc, etc.
attributes? Form the screenshot I have seen, it says it won't do that.
But I am not sure what is the default.

I hesitate to achieve HTML-mail expert status (see my X-message-flag
header).


Salam-Shalom,

Werner

[Fiedler Roman]

Post by Andrew Gallagher

Post by Werner Koch

Post by Andrew Gallagher
This all exposes one of the difficulties with trying to manage security
software in a decentralised ecosystem. We end up in arguments over

whose

Post by Werner Koch
That is actually easy compared to a system which is also designed to
protect data at rest. Some users may want to restore their 2 year old
backup to fix a problem with garbled tapes; some may want to read the
real documents about WMD from 2003; some may even want to be able to
decrypt their old love letters at the time of their silver wedding.

Indeed. This is why data must be treated as a living object. If tape drive
technology moves on, the data must be moved on. Same with file formats,
encryption systems and dying raid arrays. Librarians and archaeologists
understand the process of care and feeding for physical artefacts. Digital
artefacts are no exception.

So true. By applying such procedures, the long-term costs for providing data access would not only be on the gnupg developers' side (for providing loads of backward compatibility switches in highly security critical context) but also on those users wanting to keep the data for a long time. To improve awareness on user side and also reduce their archival costs, might a "gnupg --archive" function help? It decrypts a message the same way a normal "--decrypt" would do but then reencrypts the old encrypted message plus the decrypted content and a full decryption process audit log using an "archive key".

With such a function, gnupg might have it easier to argue running a more rigid scheme for retiring old features, e.g. that first normal decryption will fail (warning about deprecation, recommending sender upgrade or --archive use) and then after some years grace period removing the code completely?

[Patrick Brunschwig]

On 14.05.18 19:32, Werner Koch wrote:
[...]

Post by Werner Koch

Post by Andrew Gallagher
1. change the default behaviour of GPG so that any integrity failure is
fatal by default, even for old ciphersuites (we could have a flag to

I am all in favor of this and even considered to that some time ago.
However, not too long ago we removed support for PGP-2 keys which
unfortunately resulted in lots of angry mails from people who now think
they need to use gnupg 1.4 every day because they seem to read mails
From the last century on a regular base. Well, they think and they were
quite vocal. Now telling them they need to enable an option to read
certain not that old mail (e.g. creating by other OpenPGP
implementations) will a) lead to even more angry mails and b) they will
keep on using that option for all mails. Thus my tentative plan was to
make the next major version hard fail on messages without MDC and slowly
start using our forthcoming AEAD encryption mode.
Well okay, with the new support of the Ehtmlfail paper we could now
point to that paper and always hard error out if no MDC is used even for
old algorithms. Shall we consider this?

Yes, I think that's a good idea.

-Patrick

[Andrew Gallagher]

Post by Andrew Gallagher
I would humbly suggest that we stop worrying about which side of the
GPG/MUA fence the ball is on, and fix it on *both* sides.

I have just opened tickets in both GnuPG and Enigmail for the respective
integrity check mitigations.

https://dev.gnupg.org/T3981
https://sourceforge.net/p/enigmail/bugs/838/

Please let's avoid a finger-pointing contest. Belt and braces. :-)

[v***@nym.hush.com]

Werner Koch, wk, at gnupg.org wrote on
Mon May 14 19:32:18 CEST 2018:
...

I am all in favor of this and even considered to that some time ago.
However, not too long ago we removed support for PGP-2 keys which
unfortunately resulted in lots of angry mails from people who now think
they need to use gnupg 1.4 every day because they seem to read mails
From the last century on a regular base. Well, they think and they were
quite vocal. Now telling them they need to enable an option to read
certain not that old mail (e.g. creating by other OpenPGP
implementations) will a) lead to even more angry mails and b) they will
keep on using that option for all mails. Thus my tentative plan was to
make the next major version hard fail on messages without MDC and slowly
start using our forthcoming AEAD encryption mode.

Well okay, with the new support of the Ehtmlfail paper we could now
point to that paper and always hard error out if no MDC is used even for
old algorithms. Shall we consider this?
...

=====

Yes.

As an Old PGP 2.x user, I can say that the majority of PGP 2.x users communicating among them selves, DON'T use GnuPG at all.

Those who do use GnuPG, have a new V4 key and use exclusively that, and can easily handle the hardwired MDC fail, and will even be thankful for the GnuPG 'protection'.


vedaal

[Sebastian Reuße]

Post by Robert J. Hansen

Post by Andrew Gallagher

Post by Robert J. Hansen
We hesitate to require the MDC also for old algorithms (3DES, CAST5>
because a lot of data has been encrypted using them in the first
years of OpenPGP.

So if someone sends me a 3DES-encrypted mail it won't check the MDC?
Doesn't gpg still support reading 3DES?

Let's try it and find out. :)
... Yep, GnuPG will warn you the message was not integrity protected.
Your email client should see this warning and refuse to render the message.

I notice that the command currently succeeds, albeit with a warning.
Would it make sense to have GnuPG return a non-zero exit code in case
some MUA does not parse these warnings, or in case it does parse them
but proceeds to use the result?

Alternatively, perhaps invoking gpg for decryption could honor some
command-line switch or gpg.conf option to turn some or all warnings into
hard errors.

Kind regards,
SR