Re: [openpgp] Pull request for AEAD encrypted data packet with GCM

[Jon Callas <[e-mail]>]

> On Feb 13, 2017, at 5:28 PM, brian m. carlson <[e-mail]> wrote:
> 

[OCB discussion removed because we're all in violent agreement.]

>> * ChaCha20+Poly1305. Many of the cool kids are using it. It's fast, reasonably okay to implement, it's in TLS 1.3, and wouldn't be a bad choice. The major criticism I can see is that ChaCha20 is a stream cipher not a streaming mode on a block cipher (like AES or Twofish or whatever). I think most of the legitimate criticisms of it are blunted by its being used a lot in the TLS world.
> 
> That's why my proposal (which I will send a patch to the list for
> shortly) proposed an octet for AEAD algorithm.  We can implement
> ChaCha20 as a cipher and Poly1305 as an AEAD algorithm.  I support doing
> this, but doing just ChaCha20-Poly1305 excludes a secure implementation
> of all the block ciphers that we currently have.  We need something that
> works with AES.

Forgive my being out of the loop on this and behind in document reading.

4880 uses CFB implicitly with two flavors (regular and with MDC). Historically, OpenPGP leaves lots of parameterization around which is great for experimentation, but hell on test matrixes. One could parameterize a new packet in which there was a cipher parameter and an integrity parameter. Thus, one could have a the matrix [AES(key size), Twofish(key size), ...., whatever; CCM, SIV, HMAC, ...]. (The clever reader might note that HMAC leads to its own parameter.) Or one could have a parameter for a full thing like AES128-SIV, or AES256-HMAC-SHA512. I recommend the latter, myself. 

In that case, just pick decent parameters on ChaCha20+Poly1305 and be done. This is slightly important because this would be the first time OpenPGP used a stream cipher per se.

Historic note: OpenPGP dates from a time when there were a lot of good arguments for a lot of options. Okay, there were better arguments than there are now. :) You know, should we use IDEA, CAST5, or Blowfish? Should we allow DSA to be used RIPEMD-160 because SHA-1 was created by the NSA and some people think it's backdoored. We also in those days wanted maximum consensus on getting 2440 done as fast as possible. That led to a lot of parameters and then contraction of those parameters later when people never implemented the algorithm they really wanted. I think this is an opportunity to collapse option explosion by just having AE suite parameters. This would allow some generosity in parameters without total option explosion.

> 
>> * CTR+HMAC. Like you, I mention it for completeness. But while I think that any of the above would be better, I think it is again better than GCM. It's not sexy but it works, and it's harder to screw up than many things.
> 
> That's why I like it.  Assuming you have a constant time AES
> implementation, you can implement CTR and HMAC in constant time in
> almost any language.  Those algorithms are also implemented in most
> libraries.

This is also an argument in favor of CCM, SIV, and perhaps others.

One final thing that just occurred to me. If we really, really want this to preserve some OpenPGP goodness, there would also be a preference packet to allow someone to state what they do and don't speak. 

	Jon