Re: [openpgp] Choices for AEAD modes [was: AEAD and Rome]

[Werner Koch <[e-mail]>]

On Tue, 14 Jun 2022 19:40, Daniel Kahn Gillmor said:

>  d) we can revert to rfc4880bis-10's AEAD packet framing and key
>     schedule, with its table of AEAD modes, without guarantees of key
>     separation, and without GCM, but switched to OCB as the MTI mode.

Yes, this is what has been deployed worldwide for years in millions of
installations (decryption wise) and is meanwhile in active use .  After
consensus in the WG!

From an implementors POV it okay to flag the EAX code point as reserved,
make OCB manatory, and forbid any other code points.

> option (d) is problematic because a "specification required" registry
> would presumably soon have GCM added by folks who want it, but the lack

So let them add their GCM using another packet and I bet that - for
OpenPGP - it will not fly.

> of key separation between modes means that addition of a new mode like
> GCM risks introducing problems with cross-mode key abuse.  This key
> separation is one of the reasons that the design team moved to the

That is more of an academic reason than of any practical real world
need.  We don't want to have allow for too much new options.

>    greenfield application.  I don't know whether the WG could get
>    consensus around what those algorithm choices would be, but I could

The algorithms we need are AES128, AES256, OCB, SHA256, SHA512, X25519,
and maybe X448.  But that would not be a real world usable applications
but can only be used in new closed projects.


Shalom-Salam,

   Werner


-- 
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein