Re: [openpgp] Proposal to include AEAD OCB mode to 4880bis

Hanno Böck <> Fri, 27 October 2017 10:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C0FF413F411 for <>; Fri, 27 Oct 2017 03:38:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bOIrJOecR3EV for <>; Fri, 27 Oct 2017 03:38:29 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8ABA713B138 for <>; Fri, 27 Oct 2017 03:38:29 -0700 (PDT)
Received: from pc1 ([2001:2012:127:3e00:b3bf:56a1:a140:6086]) (AUTH: LOGIN, TLS: TLSv1/SSLv3, 256bits, ECDHE-RSA-AES256-GCM-SHA384) by with ESMTPSA; Fri, 27 Oct 2017 12:38:27 +0200 id 00000000000000B8.0000000059F30CA3.00004936
Date: Fri, 27 Oct 2017 12:38:26 +0200
From: Hanno =?UTF-8?B?QsO2Y2s=?= <>
Message-ID: <20171027123826.693047e6@pc1>
In-Reply-To: <>
References: <> <> <> <> <> <> <>
X-Mailer: Claws Mail 3.15.1-dirty (GTK+ 2.24.31; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [openpgp] Proposal to include AEAD OCB mode to 4880bis
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 27 Oct 2017 10:38:32 -0000

On Fri, 27 Oct 2017 10:12:51 +0000
Ronald Tse <> wrote:

> Again, OCB is proposed to be a MAY algorithm, not a MUST or even a
> SHOULD — if someone doesn't like it, there is no need to prevent
> others from using it.

I'd like to support what Paul Wouters was saying earlier in this thread.

Don't add multiple algorithms unless there isn't a very good reason for
it. Add one that is good for everything. Having a "may" algorithm only
adds unneeded complexity that is more likely to cause any security
issues than any potential disadvantage any modern AEAD has.

The GPG protocol is far more complex than it has to be.

One more note: Given that I don't see a particular rush in getting a
new RFC out you may simply wait for the CAESAR competition and choose
one of the resulting AEADs.

Hanno Böck

GPG: FE73757FA60E4E21B937579FA5880072BBB51E42