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

Gregory Maxwell <> Tue, 31 October 2017 02:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A42041389E6 for <>; Mon, 30 Oct 2017 19:29:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 cm2yq3ObtjKX for <>; Mon, 30 Oct 2017 19:29:55 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c08::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C2E3F13374A for <>; Mon, 30 Oct 2017 19:29:54 -0700 (PDT)
Received: by with SMTP id v27so10977253uav.7 for <>; Mon, 30 Oct 2017 19:29:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xgc5tayMIjfTiGEmPi1cMPGqH4pzbNkNyUKj+O7QWDA=; b=hVBLVP71Nm/W4TYSl9QE++fNymo/2gMtGa04vqmwzofoIFaCUliQBWlUdjIrmLrWRm 8AhkNuTLPsDB80LXg6X9cVk/bWPgFYGXsHUjBnzjtGmKbSGXoxfZUbJHfEc4HvkbjY9V jSiD1OPN2W8/H1Vp05NX18b3x6gF2tPV6VyeuO9hVBrkruWyM9okXdrOXv0pEIAKDUpz e+EwvHAikJ/hYWWgwJx+lTeg0lsGRHI/ZzbVT4WQIzyJ2JBgZwOJEXujNM9nA+ku3yRF DnHjzg3NHXRPGzBpWhebrNGO6mmITxNKoVttsd6F8LoQgaRaEwdgosdYlQ2FPWnnBmYt zhaw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xgc5tayMIjfTiGEmPi1cMPGqH4pzbNkNyUKj+O7QWDA=; b=WSunMDNln57UqMdKAy2SIMTNxgFvZrlpAx49MGeXqbKEwmMZAsgjGRrsMfx+lCkXRq 4wmNEOj+NwPEhN7XM6KS0ZL1Kxak9ogdrREt5P62210C3uK07s5PzBjB2mV/g+QuPVMr dSQneI0Gr+s9rrhfm/AqzKwAgo3dkYFtdaziqjWR6mN1fnTzuPCdsa1tlcKwHgno8H2W L3c4WkdQedcoxRqv7tRMy2GuK+LHIOaOvdoaDtsnDCQBT0ZkvCBj8DahSa2nb0FMTheH cTOLLv8ekilyohDI+oMRIkzIJR9Opub/duZq7Nlq3jci9D5qd736dWIjV8dd7FvN5Elb zVOw==
X-Gm-Message-State: AMCzsaVQIyfgULnAVTHnY2ayrN5tptgm7yFP4MpnLNe0XdUGQ+SwFmMM 8daOFUkkvtYwbzxM5mZLnG0EcCmf92mhX0j980I=
X-Google-Smtp-Source: ABhQp+QYUOBob7sXIkR3Rh+pZQEWx2f20jjUOBl1cwz7lSFOBWve0rOPSdO66iVeZ3yKmvFKHiS2UGT4J4zHuPMdIFM=
X-Received: by with SMTP id d15mr318929uae.127.1509416993893; Mon, 30 Oct 2017 19:29:53 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 30 Oct 2017 19:29:52 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <>
From: Gregory Maxwell <>
Date: Tue, 31 Oct 2017 02:29:52 +0000
Message-ID: <>
To: Paul Wouters <>
Cc: Ronald Tse <>, "" <>
Content-Type: text/plain; charset="UTF-8"
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: Tue, 31 Oct 2017 02:29:57 -0000

On Sat, Oct 28, 2017 at 8:23 AM, Paul Wouters <> wrote:
> For protocols like IKE/IPsec or TLS, where you negotiate a cipher suite,
> MAY algorithms are fine.
> For a protocol where both parties are not online at the same time, and
> where one party might not know the other party's capabilities at all,
> a MAY algorithm can lead to non-interoperability (with human latency
> involved)

This is a great argument but it does not apply here: A PGP public key
lists the suites that it supports. The only way you get an
incompatibility is if the far end is OCB-only and you can't support it
and that failure is "realtime" not delayed.

> It would have been nice to have had OCB support when it was invented.
> By now, the gains are pretty minimal. While there is an argument for

IIRC most or all of the popular OCB alternatives are CTR based and
highly brittle to nonce reuse.

SIV mode is the only currently standardized-in-any-way AEAD mode that
I'm aware of that has some robustness to nonce reuse.

Not that IV reuse should be a major risk factor for OpenPGP-- but I
think we've all learned that brittle constructions tend to result in
unwelcome surprises, that line if thinking is why AEAD modes exists in
the first place.

>The fact that there is a discussion and unclarity
> about this at all shows that there is an issue here.

Never underestimate people's ability to have a debate.

> The lesson here is, don't put arbitrary restrictions on your algorithm if
> you want to see widespread adoption.

This seems rather moralistic rather than a practical consideration.

IETF protocols routinely register encodings and codepoints for highly
restricted techniques:  OCB in OpenPGP would only get used when there
is mutual support on both ends.

I don't think the laudable effort of avoiding restricted techniques as
mandatory in standardized protocols is aided by a total war on them
that covers optional use of less restrictively licensed things.

The standards process question should primarily be will it get use if
it exists? If not, don't bother. The licensing of OCB appears to be
very permissive for more than a few very broad classes (including Free
Software implementations).  Input from implementers on if they'd
implement it if specified should be the primary metric.

Also, if it gets used will it enhance or harm security (seems more
like the former in this case)?

I don't believe there is any 1:1 replacement for it currently, if
there were that would be a consideration too.

One could make an argument that the grab-bag-choose-your-own-adventure
of many cryptographic options is a bad design, but I think the ship
has already sailed on that one in OpenPGP. :)