Re: [openpgp] OpenPGP encryption block modes

[Bruce Walzer <[e-mail]>]

On Fri, Aug 05, 2022 at 08:00:07AM +0000, Aron Wussler wrote:
> Hi all,
> 
> I think in this thread is missing an important piece of information.
> 
> > Speaking of messaging, wouldn't you strongly prefer the most compatible mode?
> 
> These preferences are signalled by the keyholder. When I generate a key I can specify if I'd like GCM messages in the Preferred AEAD Ciphersuites.

There seem to be two significantly different cases here...

1. The mode is required.

In this case a user can signal that they want that mode in their key
(in practice the implementation will make this decision). This
preference becomes part of their long term PGP identity. Should they
receive material in that mode they can keep it indefinitely with the
assurance that they will retain access to it. Ideally an
implementation would support any mode actually used by the user for
their lifetime plus a bit.

This is more or less the current situation for OpenPGP
preferences. This doesn't always work in practice because a user can
use the same key with multiple implementations. Those implementations
might not all be as up to date. I have already ran across an instance
where a proposed AEAD mode leaked out of an implementation and caused
a unsolvable interoperability issue for a user not completely
knowledgeable about these sorts of issues. They generated the key on
the newest implementation.

2. The mode is optional (the GCM case).

Is having a mode that is optional but resides in the preferences
something that has ever been seen in normal OpenPGP usage?

In this case a user can signal that they want that mode in their key
...  but they really shouldn't. That is because a conforming
implementation can drop their mode at any time. Then all their
messaging archives and encrypted files are suddenly inaccessible for
no reason a typical user would understand. They are unlikely to be able
to come up with a script to reencrypt everything to a different
mode. They can't just upgrade to a newer version.

Contrast this to, say, a medium like TLS where, in principle, you
could renegotiate a different mode for every connection. The OpenPGP
preference system is not a negotiation system. In practice it mostly
prevents downgrade attacks. Things work as well as they do because
most implementations support the same modes.

> 
> A recipient not trusting GCM can simply omit it from their key. I see no problem with any implementation omitting GCM by default (not to alienate non-crypto-geeks) and including only if it makes sense for the implementation itself (e.g. OpenPGP.js), or if there are some legal requirement to do so. I can't imagine a (compliant) implementation sending GCM messages to a certificate that does not specify support for them.
> 
> Furthermore, a GCM-skeptical sender could also ignore this preference and just send messages using OCB, that must be supported (even though admittedly this requires more technical knowledge).
> 
> Finally, since we're not in the asymmetric part of the certificate - that if you fail to parse game's over - I don't understand the point of discussion. As said at IETF114, if this does not end into the draft, anyone can come up with a spec adding an additional block mode, therefore not adding it now will not prevent people from using it eventually.

Anyone can do whatever they want, but that would be the case for any
standards effort. The reason we have standards is so they won't.

Bruce