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

Paul Wouters <> Mon, 30 October 2017 20:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8AF8213FAF2 for <>; Mon, 30 Oct 2017 13:29:27 -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] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MTRkkL4wzkHQ for <>; Mon, 30 Oct 2017 13:29:25 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 172CD13FB24 for <>; Mon, 30 Oct 2017 13:29:24 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by (Postfix) with ESMTP id 3yQmKs5C8szF7N; Mon, 30 Oct 2017 21:29:21 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=default; t=1509395361; bh=gtQ3yoNHk3Lt55455egh2I1Vk5q4+R5YDrF7Zv4r1gU=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=fRSfLudc6XG0xkU2v7wqxTyRCT5qDUMoI9aaa2ne0oeJ0etTUNAopskWZKEwh03X4 HeywQnEpgUASOtYma+01Z9Ii9Lv3VYX0DEgOlLBdklzcwlZ+T7u08CgeIB6jAftWVG 5Ad8khZV3NzGPjFyTlFOEDZwXSSaRQxLyrWFvn18=
X-Virus-Scanned: amavisd-new at
Received: from ([IPv6:::1]) by localhost ( [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id qnIFs0TZIj-B; Mon, 30 Oct 2017 21:29:18 +0100 (CET)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS; Mon, 30 Oct 2017 21:29:18 +0100 (CET)
Received: by (Postfix, from userid 1000) id B0FCA62D29; Mon, 30 Oct 2017 16:29:17 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 B0FCA62D29
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9D40440D35AF; Mon, 30 Oct 2017 16:29:17 -0400 (EDT)
Date: Mon, 30 Oct 2017 16:29:17 -0400 (EDT)
From: Paul Wouters <>
To: Derek Atkins <>
cc: Rick van Rein <>, "" <>
In-Reply-To: <>
Message-ID: <>
References: <> <> <> <> <> <> <> <> <>
User-Agent: Alpine 2.21 (LRH 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
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: Mon, 30 Oct 2017 20:29:27 -0000

On Mon, 30 Oct 2017, Derek Atkins wrote:

> On Mon, October 30, 2017 3:22 pm, Paul Wouters wrote:
>> It was an example of how some people having IDEA and other not having it
>> causes interop issues to the point that I need to manually hack my
>> implementation to talk to those people.
> Yes, and IMHO, IDEA should get added back in.  In this day and age there
> is zero reason to prohibit it.

You miss my point. Implementors made decisions and as a result, non-expert
endusers ended up not being able to send each other encrypted email. I
am sayong don't repeat that mistake.

> Note that it's not "PEOPLE" who are choosing them, per se.  It's the
> implementers, who one would think would have a better idea of what to
> implement and why.

That still does not help much against someone using a new algorithm and
someone else using old software that does not have that algorithm.

How long does it take for any now added algorithm to be commonly
supported? By paranoid people who dont want to upgrade their offline
systems? :)

> Maybe that implementer is doing something privately, but still wants to do
> it in a standard way.  We should let them.

That's what private number ranges are for.

> Maybe the implementer who wants to add OCB doesn't care if your
> implementation can read it, because your implementation is very unlikely
> to ever see an OCB message.  Why do you want to say that they may not do
> that (which is what you're saying by implying that your implementation
> must support every feature and that the protocol may not support features
> that your implementation does not support).

As long as you can detect the support when you have the public key, that's
probably okay. But that's still a weak argument to allow vanity
algorithms, as it will still increase the chance that multiple parties
don't share those in their implementation.

And how does this work when my phone supports some algorithms, and my
laptop supports other. How do I announce that in my public key? It
looks like you'd be forced to only publish the shared algorithms. I
wouldn't even know how to announce that.

>>> But if the protocol does NOT support some methods
>>> it might prevent some users from using the protocol.
>> Which is a good thing?
> No.  It's not.  We should encourage people to use OpenPGP.  It's a great
> protocol, and anything we do that prohibits adoption is a bad thing.

Swiss army knives are great tools. Raise your hand if you never cut
yourself with one.

> I'm running OpenPGP specifically because the data formats are smaller and
> easier to generate/parse than X.509, so I *CAN* actually run it in an IoT
> device.  Of course I'm extremely limited in what methods I support, but I
> happen to control both ends of the communication so I can work in an
> enclave and control the implementation.
> This is exactly why we should be open in what we accept.  In my case, I
> don't care if your implementation does not support my methods, but I want
> to ensure that I can implement my methods in a standard way such that it
> wont interfere with you (and you wont interfere with me).

Ok, well if all of that needs to be supported I guess we will be cursed
with an amount of failure as the price to pay for the freedom to
shoehorn openpgp on everything. I still think it is wise to try and
limit the number of algorithms with similar cryptographic and
architectural properties.