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

"brian m. carlson" <> Tue, 14 February 2017 02:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9AC4912945E for <>; Mon, 13 Feb 2017 18:26:55 -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 xBXVtFflFzuh for <>; Mon, 13 Feb 2017 18:26:54 -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 030D412945C for <>; Mon, 13 Feb 2017 18:26:54 -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 D4395280AD; Tue, 14 Feb 2017 02:26:51 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=default; t=1487039211; bh=W+uKOon6yQ/MTukEv4RifzP2wssY0C0Spu6Un6IZN68=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=F1MvH5v+s1gzFRZa9pG7/etoXD7lPXWk/2WqbTCs7kBNGDIoAXV7MWBeWgsZRYLqF R845d8whOxXq/Ty8znIHEoOcTsJ6PZGVjjb3q737rDHiJQyahO0LGdeIhjRVExpg5E iESpjgaukZH1Zcbkq17kAMRT6TMJk3b/FN6meuF2tYsa5Bf77AHN4Hm9BRyc+beeFu GOCdt9EXp0mVQQehjMrOd0HC6IlsH8OMFQ4D954fu7K8y9jvn8yLILw/4dhYM56Tv4 IuBv2cYUBTn/TR0rW9LVeQhLhmFddRvdzACT+lWzAzqky9BD/PAVG11QKHsT3pJ0cd sS5yX/3YjpXS1WmJbAsOEObkLgatYoQSi2CIpcXILPoRP8hVa2z3v5X2bSTUfLVKrm s935lcZn6aA8zvbboukkUNwynanefCYXNWwUTzLuB/i8TAz6YF705HD74GvclCng/I WxaA2RRhEWd94q9Vze7Q8XbUjKrR7317VMYiuGvul86m3lmzEaz
Date: Tue, 14 Feb 2017 02:26:45 +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="agazaxkeichqll3z"
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 02:26:55 -0000

On Mon, Feb 13, 2017 at 06:05:34PM -0800, Jon Callas wrote:
> > On Feb 13, 2017, at 5:28 PM, brian m. carlson <> 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
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | | My opinion only