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

"brian m. carlson" <> Tue, 14 February 2017 01:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4E4841299FA for <>; Mon, 13 Feb 2017 17:28:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (3072-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id B4kxEhG0oeFX for <>; Mon, 13 Feb 2017 17:28:21 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 83520129998 for <>; Mon, 13 Feb 2017 17:28:21 -0800 (PST)
Received: from (unknown [IPv6:2001:470:b978:101:254c:7dd1:74c7:cde0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id A3A9B280AD; Tue, 14 Feb 2017 01:28:20 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=default; t=1487035700; bh=8J2uFyXnxYM4dfgunZqm/N6DYBPTJkedGGt9tg5ULiw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=BvQvQGXwOvee463ZJRK58kkT0JrjYqha4PS1+3R/nR4eBxxU2x/150EkIvGghtQFm 86Iw1uve6ph/fQWq+8fHXBjGWMyf4mtP9+sfHb6k7JH6RfkhN8MAUS5EFd2tQBUGhX mlrDipfGIsPDi5FNwmbncI5CVzBIuZE+ljml7xTsP0mlEnTnHwo5uQT79JlK5M4k+I 0GGLRc4DAAXbROwT2si8yqWcMF14CKLts11FXclD6NUevzOYxnTuUzWowndQCG3hLf yCgl2bFVL8lDa2FtPbKZDn143ZNCDzgBY8lEZ9sK7S37jdmvbRJFa1tHzLdDQpGI2q uzupNpE4lCqcBHwvcNXC34+BlG7L4eP82aM64T3yLfl3+O9SNWZS758nUULKeVmtY8 jsKy8C35Cqb0Y+M3oHy+kA5t0GQ0reAcTxWiJZ74X2CWGuSf3mikrP1tLEr4HlFI4a RcefjlhzrjkDEga2+FnVO9aqJEBC2F8lDtnTeajyrgr1iJhL9fu
Date: Tue, 14 Feb 2017 01:28:17 +0000
From: "brian m. carlson" <>
To: Jon Callas <>
Message-ID: <>
References: <> <>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="fys2cy2bdpxwm72x"
Content-Disposition: inline
In-Reply-To: <>
X-Machine: Running on genre using GNU/Linux on x86_64 (Linux kernel 4.9.0-1-amd64)
User-Agent: NeoMutt/20170113 (1.7.2)
Archived-At: <>
Subject: Re: [openpgp] Pull request for AEAD encrypted data packet with GCM
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 14 Feb 2017 01:28:23 -0000

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 <> 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
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | | My opinion only