Re: [openpgp] AEAD and Rome (was: First remarks on the last I-D)

[Daniel Huigens <[e-mail]>]

Yeah. In general I agree with this goal. We haven't implemented
Camellia, and to be honest, I'd love to get rid of the NIST and
Brainpool curves, and keep only the CFRG curves.
(As I said before I personally don't care much about FIPS compliance
in general, though I know some people do.)

I also wouldn't be opposed to removing EAX, I agree it's no longer
really necessary.

Relative to those, adding GCM adds less code and maintenance burden
for us, as it's already included in the underlying crypto libraries.
However, I can definitely sympathize if it adds a burden for others.
I certainly wouldn't make GCM mandatory to implement. That way, only
those who want to implement it can, and if it's not included in the
algorithm preferences, nobody will send GCM encrypted messages to that
key; and the implementation can use MTI algorithms instead.

This is in contrast to public-key algorithms, where if anybody publishes
a key using a given algorithm, there's no option to fall back to a MTI
algorithm. Thus I think we should be more restrictive about adding
public-key algorithms (and curves) than symmetric-key algorithms.

However, if the general goal is to have as few algorithms as possible,
I also wouldn't be entirely opposed to having only OCB. But then I would
simplify the entire AEAD system and just hardcode OCB, and if we ever
think that might be(come) no longer sufficiently secure, we can just
define a new packet version. That would be a large overhaul, though, so
I'm not sure if that's worth it at this point. And presumably the
people that care about FIPS compliance would object to that.

Best,
Daniel