On Mon, Feb 13, 2017 at 05:09:49PM -0800, Jon Callas wrote:
Your mention of alternatives was incomplete, so I'll bring alternatives up.
We all really want to use OCB. If you look at
<http://web.cs.ucdavis.edu/~rogaway/ocb/ocb-faq.htm> which is Rogaway's page
on it. While it is patented, there are some broad license grants. There's one
for open source software, as well as one for non-military software. He's also
given one OpenSSL. I'll bet that if someone asked him for a grant for the
OpenPGP protocol, he'd probably do it. As it is, the large-swath grants for
it (open source, and non-military) suggest that we could either say that's
good enough for us or ask for another grant. But if we don't want to, we
don't want to. OCB is the mode everyone really wants to use, but I don't want
get wrapped around the axle on the controversy here, either.
Beyond OCB, though, there are a lot of alternatives:
I think OCB is a non-starter because of the patent. It doesn't matter
what the patent situation actually *is*. It matters what Red Hat's
lawyers and the lawyers of thousands of companies worldwide think it
*might be*. Red Hat refused to implement ECC for a long time because
they thought it *might* have potential patent problems, and the
uncertainty was enough to seriously delay modern ECC support on a
significant portion of servers. I don't want to write a spec that is
going to be unusable or less usable because of the patent.
OCB is also not implemented in most crypto libraries (for the above
reason). If we have people writing code in web browsers and scripting
languages, we want something that Web Crypto and OpenSSL are going to
support. Otherwise, we're going to have people writing crypto
implementations in JavaScript and Ruby and whatnot, and those aren't
going to be side-channel safe. People are already doing this, so we
should consider it as a use case.
* 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.
* 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.
--
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