Re: [openpgp] SHA3 algorithm ids.

ianG <iang@iang.org> Tue, 11 August 2015 20:08 UTC

Return-Path: <iang@iang.org>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 803521B2A30 for <openpgp@ietfa.amsl.com>; Tue, 11 Aug 2015 13:08:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQ2pEtTrMgiJ for <openpgp@ietfa.amsl.com>; Tue, 11 Aug 2015 13:08:31 -0700 (PDT)
Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFC081B2A2A for <openpgp@ietf.org>; Tue, 11 Aug 2015 13:08:30 -0700 (PDT)
Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 9B6116D73E; Tue, 11 Aug 2015 16:08:29 -0400 (EDT)
Message-ID: <55CA5654.4000400@iang.org>
Date: Tue, 11 Aug 2015 21:08:52 +0100
From: ianG <iang@iang.org>
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
To: openpgp@ietf.org
References: <87y4hmi19i.fsf@vigenere.g10code.de> <7540C7A9-2830-4A63-8310-B684796DA279@nohats.ca> <55C681FC.9010100@iang.org> <sjma8tztbgo.fsf@securerf.ihtfp.org> <CAMm+Lwj7SxXTn+KD-eQSeZHwJB36tCgD1t0bodVsp3ovOaZ8mw@mail.gmail.com> <87si7qf84a.fsf@vigenere.g10code.de> <55C9EAA2.8040500@iang.org> <87wpx1erkl.fsf@vigenere.g10code.de>
In-Reply-To: <87wpx1erkl.fsf@vigenere.g10code.de>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/openpgp/-queg_54U0q_xQGLUUjibz7Fgmk>
Subject: Re: [openpgp] SHA3 algorithm ids.
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:openpgp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/openpgp/>
List-Post: <mailto:openpgp@ietf.org>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:openpgp-request@ietf.org?subject=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, iang@iang.org 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 
defer.)



iang


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