Re: [openpgp] SHA3 algorithm ids.

ianG <> Tue, 11 August 2015 20:08 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 803521B2A30 for <>; Tue, 11 Aug 2015 13:08:32 -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 NQ2pEtTrMgiJ for <>; Tue, 11 Aug 2015 13:08:31 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EFC081B2A2A for <>; Tue, 11 Aug 2015 13:08:30 -0700 (PDT)
Received: from tormenta.local ( []) by (Postfix) with ESMTPSA id 9B6116D73E; Tue, 11 Aug 2015 16:08:29 -0400 (EDT)
Message-ID: <>
Date: Tue, 11 Aug 2015 21:08:52 +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 20:08:32 -0000

On 11/08/2015 17:08 pm, Werner Koch wrote:
> On Tue, 11 Aug 2015 14:29, said:
>>    * 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.
> I don't think so.  Let's assume that 4880bis specifies SHA-256 as the
> replacement for SHA throughout the protocol.  Then it would be pretty
> clear that SHA3-256 can be used if surprisingly a Chinese researcher
> finds weaknesses in SHA2.

This assumes that any future breach of SHA2 is of the class that we can 
then drop in a replacement from SHA3 -- without any change.  Eg, a 
prediction that the Chinese researcher attack actually comes true a 
second time.

I find this unlikely.  We're fighting a mythical enemy here, indeed the 
Chinese research attacker hasn't as yet actually count coup [0] on SHA1 
let alone SHA2 :)

I suggest we get back to other things, we're wheel-spinning.  If you 
really want to allocate those numbers, go ahead - I think it is 
pointless but it does no harm to the document, and it's better to move on.

>>    * 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
> We already have this.  The preference systems greatly helped with the
> migration from SHA-1 to SHA-256 et al.

OK, I'd have to review that in the doc.  (But I don't have time, so I'll 


[0] old Hollywood term for scalping the enemy in westerns.