Re: [openpgp] Proposed Patch to RFC4880bis to reserve two public key numbers

Stephen Farrell <> Thu, 07 July 2016 09:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BC18912D50C for <>; Thu, 7 Jul 2016 02:23:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.727
X-Spam-Status: No, score=-5.727 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_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] 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 R-_hHJzuzPAx for <>; Thu, 7 Jul 2016 02:23:41 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A811A12D186 for <>; Thu, 7 Jul 2016 02:23:41 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 155C4BDD8; Thu, 7 Jul 2016 10:23:40 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HWPrFz0gNIaq; Thu, 7 Jul 2016 10:23:38 +0100 (IST)
Received: from [] ( []) by (Postfix) with ESMTPSA id D2BE9BDD0; Thu, 7 Jul 2016 10:23:37 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mail; t=1467883418; bh=USfC2RdQ6xwg7WSdy0Je29apl/gSfZyyVjRa1tHGx2I=; h=Subject:To:References:From:Date:In-Reply-To:From; b=CqphEu78cZn8//S2DoZa/K6WgGYH5EvsiO3lTJw0onB2EA0MGB/kVY/E4YV5nTsGZ UKwrdnvcL453Ruwy9EaRWFgvANuAxyWcZ0yHnsQGKGRliiBzm+S1Zteg9NADZTFmir W9pc2jJMW095IA9WDVmvCj7zJurtee99dYWSlg0k=
To: Derek Atkins <>,
References: <> <> <>
From: Stephen Farrell <>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <>
Date: Thu, 07 Jul 2016 10:23:37 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms000303090807030408050408"
Archived-At: <>
Subject: Re: [openpgp] Proposed Patch to RFC4880bis to reserve two public key numbers
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: Thu, 07 Jul 2016 09:23:44 -0000


On 07/07/16 07:24, Werner Koch wrote:
> On Thu,  7 Jul 2016 01:36, said:
>> Hi,
>> Now that we've accepted the draft, I'd like to re-open this proposal to
>> reserve two public-key algorithm protocol numbers.  Note (again) that
> I opened an issue to track this proposal:

I forget if this cfrg posting [1] on AE was made visible here
or not. Apologies if this is repetitive but that posting from
Kenny Paterson on 20151113 seems quite relevant as it says:

My colleague Simon Blackburn and his collaborators have just
published an attack on the Algebraic Eraser scheme, breaking the
scheme at the designers' claimed 128-bit security level. Their
attack recovers the shared key using 8 CPU hours and 64MB of
memory. Their paper is here:

With no hats, I'd be against adding an algorithm, even as an
option, if there are current serious questions about it's real
security level. I do get the arguments for and against, but in
such cases am against adding codepoints where there is no way
to flag the codepoint as "likely dangerous" or some other
similarly negative/scary warning. And while it's good to go to
the effort to deprecate old codepoints that are now likely
dangerous, I don't see that it's a good idea to add new ones
"born" in that state.

But maybe there's an update on the state of cryptanalysis of
AE? If so, I guess posting to cfrg and then reflecting that
back here might be best, as the cfrg list has folks who're
better qualified to argue those merits. As far as I can see
there was no follow-up to [1] on the cfrg list, but I might
have missed it. There does seem to have been an update to
the paper on arxiv last month, but I didn't check to see what
changed - the abstract still claims the break anyway.

Putting my AD hat back on: if the WG do reach consensus to
add such codepoints, then when it comes time to publish, I'll
be looking back to the list to ensure that consensus was very
clear on the list. For the AE ones, that's clearly happening
via this thread which is fine process-wise, assuming more folks
opine and the chairs declare consensus. I'm just noting that
so we ensure the same clarify if there are other similarly
contentious codepoint requests in order to avoid having to
revisit stuff at publication time.



> Salam-Shalom,
>    Werner