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

Jon Callas <> Tue, 14 February 2017 01:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 63ABD129401 for <>; Mon, 13 Feb 2017 17:09:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.588
X-Spam-Status: No, score=-4.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-1.887, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id s_fyk4LtBwnz for <>; Mon, 13 Feb 2017 17:09:52 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AA1B4120726 for <>; Mon, 13 Feb 2017 17:09:52 -0800 (PST)
Received: from by (Oracle Communications Messaging Server 64bit (built Feb 26 2016)) id <> for; Tue, 14 Feb 2017 01:09:52 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=4d515a; t=1487034591; bh=zM4sIkNBqQTlPlshO6qftau2Aqji8emmgEI4vjZbYKg=; h=Content-type:MIME-version:Subject:From:Date:Message-id:To; b=n8ZyCBNtImqbpqAEObaFnH2eXVtzkfUCt3xD1HjUPJ6xpR/5Yvbkg+2CToXhZTgcR MDuykOpLum/dp2qxEn1tMoMBurXIv7FE1/84CSYVbthRLJ+TLtotsZO9NDoMs6bzaP irQVWuB1O2ORFFTTZyAhGlon/LPzY0JRCXrLH1dljSMfabHLq3h9cqI2RaseGemmGE yQHg8l9N62jIFmORAxh6jIF0MT/9j6W1l/5SQgu5ruttiXlgf6NIRRMo32BIQDRJm7 nV+djX9MSYQOHAkYoDVB7/6T1/tFah121nQGhdnDFdgnlnh38yT9CbkcK0C6fgNMIt HRicWKq8ifQkQ==
Received: from ([]) by (Oracle Communications Messaging Server 64bit (built Feb 26 2016)) with ESMTPSA id <>; Tue, 14 Feb 2017 01:09:51 +0000 (GMT)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-02-13_13:,, signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1034 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1603290000 definitions=main-1702140010
Content-type: text/plain; charset=us-ascii
MIME-version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: Jon Callas <>
In-reply-to: <>
Date: Mon, 13 Feb 2017 17:09:49 -0800
Content-transfer-encoding: quoted-printable
Message-id: <>
References: <>
To: "brian m. carlson" <>
X-Mailer: Apple Mail (2.3259)
Archived-At: <>
Cc:, Jon Callas <>
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:09:54 -0000

> On Feb 12, 2017, at 5:06 PM, brian m. carlson <> wrote:
> I've opened a pull request that defines an AEAD encrypted data packet
> using GCM.  This work is necessarily incomplete, because it doesn't
> define a new version of the symmetrically-encrypted data packet, which
> we'd want, and it doesn't define a new encoding for the secret key
> packet.
> GCM seems to be the uncontroversial choice here.  It's used in TLS and
> other protocols, and it provides adequate security.  It isn't encumbered
> by patents.  It performs reasonably well.
> Other alternatives include OCB and CTR with HMAC.  I personally object
> to OCB because it's patented, and while I like CTR with HMAC, it was my
> impression that the rest of the working group would not share my
> opinion.
> While I understand that we are not interested in adding general
> extensibility to the protocol, I opted to include an octet for the AEAD
> algorithm in case someone wants to define OCB or something like
> ChaCha20-Poly1305.  ChaCha20 cannot use GCM, but it is a popular
> algorithm that performs well on many architectures and is well-suited to
> embedded systems.
> I've proposed this as a starting point and welcome further comments.

I'll request that another mode than GCM be used. In particular, I disagree with it being "uncontroversial." It's the most controversial mode you could pick.

GCM is very brittle. It breaks in very bad ways if you aren't careful with nonces/tags. There are many cases of people misusing it and getting worse than no security. I state that because if you *think* you're getting authenticated data, but it's actually been altered in transit, and that will likely cause issues in the receiving state machine.

This paper <> is all about real-world cases of unintentional misuse of GCM.

Furthermore, the multiply in GHASH is slow in software. Yes, there are hardware instructions in high-end Intel and ARM processors, but if you do it on lower-end processors or in something like javascript, it's a pain. If you have to conditionally do hardware or software, it makes implementation more difficult.

I think GCM is fine to use in some circumstances, like high-speed VPN boxes, but it's the AEAD mode that comes from ACME. If you are Wile E. Coyote it is going to blow up in your face.

Perhaps most rigorously, the real problem with GCM is GHASH. Anything with GHASH is worrisome.

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:

* CCM. CCM has been my go-to for AEAD in many cases. It is easy to understand and works well. It is easy to get right. I think that this is an important property, being easy to get right. Its major disadvantage, being a two-pass algorithm, is not that bad for OpenPGP because we have streaming packets in the core protocol. Nonetheless, Rogaway's own paper about it (see the OCB link above for it) is not a bad paper, but remember that Rogaway is arguing against CCM in favor of either OCB or his own EAX.

* 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.

* SIV. SIV is another Rogaway mode, it's unencumbered, has resistance to misuse, and I can't think of anything bad to say about it other than a plea not to use the GCM version because GHASH. Many cool kids are using it.

* EAX. I tend to discount EAX because it's not OCB, not CCM (which was created to be Not OCB), and not SIV. I wouldn't scream, though. I just think that in this day, it doesn't have an advantage over any non-GCM AEAD thing.

* 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.

So to sum up, I think that GCM is actually controversial and dangerous for generic use.