Re: [openpgp] SHA3 algorithm ids.

ianG <> Tue, 11 August 2015 12:29 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 70ADE1A8931 for <>; Tue, 11 Aug 2015 05:29:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id x2aquujL_tKU for <>; Tue, 11 Aug 2015 05:29:02 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DE1271A1B14 for <>; Tue, 11 Aug 2015 05:29:01 -0700 (PDT)
Received: from tormenta.local ( []) by (Postfix) with ESMTPSA id A586F6D775; Tue, 11 Aug 2015 08:28:59 -0400 (EDT)
Message-ID: <>
Date: Tue, 11 Aug 2015 13:29:22 +0100
From: ianG <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
References: <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [openpgp] SHA3 algorithm ids.
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 11 Aug 2015 12:29:03 -0000

On 11/08/2015 11:10 am, Werner Koch wrote:
> We have a lot of experience in how to deploy new algorithms and we are
> very conservative here.  My request for adding SHA3 algo ids does not
> mean in any way that I endorse its use or would even suggest that
> 4880bis should contain a SHOULD or MAY for implementing such an
> algorithm.  When we come to the point on deciding on algorithms I would
> suggest something like this:
>   - Implementations MUST implement SHA-1.  Implementations MAY implement
>   - other algorithms.  MD5 is deprecated.
>   + Implementations MUST implement SHA-1 and SHA2-FIXME.  Implementations
>   + MUST NOT implement MD5.  Implementations SHOULD NOT implement
>   + SHA3-xxxx.  Implementations MAY implement other algorithms.
> The algo ids are a different case and I would be fine with the RFC-7120
> method.  Iff the unexpected case happens that a severe weakness in SHA2
> is found, the pre-allocated SHA3 ids will allow us to quickly switch to
> SHA3.  Isn't that the whole point of SHA3 being plugin-in replacements
> for SHA2?
> I suggest to use a different thread for discussing algorithm selection
> because that is a different topic than assigning algorithm ids.

Hmmm... I understand that.  What I'm not convinced of is that at the 
current time we can sensibly allocate the numbers.

As far as I can see, to sensibly allocate the numbers, we'd want:

   * to choose which SHA3 we're going for.  This not only means 
addressing the additionals (like the 4 lengths) but also resolving the 
uncertainty (perhaps in my mind only) about SHAKES.

   * to build a more comprehensive alg-failure recovery strategy.  By 
this I mean, more than handwaving at SHA3 as a potential drop in; 
making it the actual drop in with a process by which we trigger that 
move and a series of events listed that we anticipate happening;  text 
in the draft that lays that out;  etc.

Otherwise, we're fortune gazing.

(It may sound like I'm engaging in waffly rhetoric again - but there is 
a known discipline for this.  It's called *disaster recovery* and it's a 
required component of many compliance programmes, taught and certified 
in various places.  There are many people who know how to do this stuff, 
it's just that it is a relatively new and/or infrequent delivery in the 
open source crypto world.)