On Mon, Feb 13, 2017 at 06:05:34PM -0800, Jon Callas wrote:
On Feb 13, 2017, at 5:28 PM, brian m. carlson
<sandals(_at_)crustytoothpaste(_dot_)net> wrote:
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.
My patch implements exactly that: a cipher byte, and an AEAD algorithm
byte (it uses GCM, but it sounds like we want to change that). I feel
like this provides us the flexibility we need without providing too many
options, especially since I get the impression we may want both block
and stream ciphers).
If we did CTR+HMAC, I'd propose CTR+HMAC-SHA512 and CTR+HMAC-SHA-3-512
as the AEAD algorithms (just hardcoding those as AEAD algorithm bytes).
If we did EAX or SIV, that would logically be the AEAD algorithm. If we
additionally did ChaCha20, I'd define Poly1305 as the AEAD algorithm in
the TLS way.
I was not considering allowing further parameterization beyond that
point, as that's a great way to let people pick bad options.
We do need to preserve the existing cipher byte values for AES Key Wrap
in coordination with ECDH, though.
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.
I think we're in agreement.
* 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.
I think the two-pass nature of CCM is undesirable, but I'd be fine with
EAX or SIV. I feel confident I could implement those in a constant time
manner in a variety of languages given a constant-time AES-ECB and
AES-CTR.
--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: https://keybase.io/bk2204
signature.asc
Description: PGP signature
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp