Interoperability with OpenPGP crypto-refresh

Werner Koch wk at gnupg.org
Thu Feb 2 10:26:48 CET 2023


On Thu,  2 Feb 2023 06:12, Christoph Anton Mitterer said:

> The WG seems to have done quite a good job, and crypto-refresh provides
> many things that are wanted.

Up until summer 2021.

> Is there any *real* problem about it containing GCM?! Its chapter 9.6.

Yes, I explained it.  This adds a lot of extra complexity to the
protocol to mitigate for the fragile GCM.  That does not affect just
GCM but also OCB.

> draft-koch-openpgp-2015-rfc4880bis-00, OTOH, lacks at least Ed448.

Will be added.  Actually GnUPG supports x448 for quite some time.

> It also still comes only with S2K as KDF, despite there being
> considerably better alternatives (I mean Argon2 would be the natural

OpenPGP is a protocol used mainly for public key encryption.  The S2K is
mainly used for impedance matching.  Using it to make brute forcing of
passphrases harder is not its primary goal.  And in fact it can't be
used in real world applications: For symmetric encryption the a full
entropy passphrase should be used.  Any delays or extensive requirement
of resources (memory, CPU) is counterproductive in the real world.

You use symmetric-only encryption either for automating tasks which
requires speed and thus implementations may not be resource hog.  Or for
mass sending of encrypting data to a large group of recipients.  In that
case the recipients have all kind of different machine types and you
can't assume that they all have some big-memory system to quickly do the
S2K.  They want to work fast and there are use cases where dozens of
messages are received per second - not a suitable target for Argon2 or
any other long running KDF.

For protecting the private key - well, this should be done but it is not
in the scope of OpenPGP, which describes an on-the-wire protocol and not
a particular implementations.  Sending a private key in the OpenPGP
format is anyway not a good idea to still existing weaknesses in the
protocol - the common wisdom is to use symmetric-only encryption (with a
full-entropy password) to convey a private key.  Or use another public
key.

> May not be a big issue for Thunderbird, but for anyone who wants to do
> symmetric session keys, that's really some bad news - and IMO in no way

No.  The real world works in a different way. See above.

> Passively following the WG, many people there seem to believe that the
> crypto-refresh process was quite open for anyone and seem to consider
> the competing/conflicting draft at best unfortunate or rather made in

It is not a competing one but it is the state of things from summer 2021
which all paricipants of the DT had agreed upon back then.  Actually
with some minor modification it is the very same as what we had in 2021
and which had been implemented and interop tested already in 2018.



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: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20230202/adf0673b/attachment.sig>


More information about the Gnupg-devel mailing list