Should one really disable AEAD for recent GnuPG created PGP keys?

[Werner Koch]

On Tue,  5 Mar 2024 11:15, Bruce Walzer said:

> So just to be clear, I am not complaining that GnuPG implemented the
> LibrePGP version of OCB. I am complaining that GnuPGP did #2 and #3
> before implementation was close to universal and did not clearly spell

Sorry, this is not true. OCB mode is only used if all recipient's key
have the flag that they support this mode.  This is not different from
the preferences for a certain cipher algorithm.  For example AES in the
old days.  The migration from CAST5 to AES worked without any noticeable
problems because after we implemented AES, we announced that in the keys
and the peers started to use AES iff all recipients claimed that they
support this flags.  Same thing for for compression algorithms.  At some
point we were talked round to implement bzip2.  The WG agreed on a code
point for this and GnuPG implemented it.  It is really rare that you
get messages which you can't decrypt due to the non-supported
compression algo.  The preference system does it works.

Now, when you move to another software with less capabilities, you need
to announce that to your peers by sending an updated key with the new
set of preferences.  Sure there is a problem with low end mobile device
software which you use with the same key - in this case you need to drop
the preferences which are not supported by your mobile device software.

> block cipher mode and do whatever else will speed things up. The user,
> of course, would be made aware the the resulting files might not be
> decryptable everywhere.

If your key claims that it supports this feature it is decryptable - or
you forgot to distribute the fact that you moved to a less capable
software.

Right, for symmetric only encryption the preferences don't work.  But in
this case you need to negotiate parameters and passwords anyway.

> Arch Linux is just dropping #3 with their patch. Their version of
> GnuPGP still supports the OCB mode and can generate it. So they are

Sure they can do that.  However, I don't think that this is a good
decision.  With the same argument we would still be using CAST5 or
Twofish or even Blowfish.

> distributions were not tempted to issue such patches. There really
> should be a better way of doing this. Otherwise the users will
> encounter different behaviour on different Linux distributions.

Agreed.  Let the preferences work for you.  And also nag Vincent et al
to stop crippling their software (rejecting OCB).  After all
BouncyCastle supports ed25519 which is also not specified by an RFC or
anything else except the way gpg implemented the details of that curve.
Such public key algorithms can't even be managed by the preference
system.


Salam-Shalom,

   Werner

-- 
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 247 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240306/4a92a9a1/attachment.sig>