Brace yourself: User-friendly but broken OpenPGP is here

[Vincent Breitmoser]

> A closer inspection of the key ID showed that it was encrypted with my master
> key. A key that is not marked to be used for encryption. So how the heck did
> that happened?

I believe what you're experiencing here is actually a direct consequence of
a GnuPG policy decision: Subkeys that don't have an encryption flag *are*
typically allowed for decryption by GnuPG. I suspect it only doesn't work
because you are using a smartcard key (or perhaps the policy has changed?).

Some more background: I filed an issue with GnuPG for this in 2018, when
I received related bug reports for OpenKeychain. Users complained that they
received encrypted data they couldn't decrypt with OpenKeychain, but could with
GnuPG. I'm aware of at least one bank that does this, as well as a Perl OpenPGP
implementation, and now apparently canarymail.

GnuPG allows this behavior, so other implementations will in practice rely on
it. Hyrum's law:

> With a sufficient number of users of an API,
> it does not matter what you promise in the contract:
> all observable behaviors of your system
> will be depended on by somebody.

Relevant issue on the GnuPG issue tracker: https://dev.gnupg.org/T4235

For convenience, here's the relevant response from Werner:

> I don't see a problem. If you have the private key you can and will use it.
> I guess your concern is an oracle?

And the response from Andre (GnuPG dev):

> Bug compatibility is nothing esoteric or bad especially for a general purpose
> backend tool like gnupg. Being open to accepting broken input is a good thing
> because it will mean that we can get people out of a "broken tool vendor lock
> in".

Hope that sheds some light on this.

Cheers

 - V