On Feb 13, 2017, at 5:28 PM, brian m. carlson
<sandals(_at_)crustytoothpaste(_dot_)net> 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
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp