Re: [openpgp] New fingerprint: to v5 or not to v5

ianG <iang@iang.org> Tue, 29 September 2015 13:54 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 2317B1B3FDF for <openpgp@ietfa.amsl.com>; Tue, 29 Sep 2015 06:54:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Level:
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] 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 3Jc7FYo-qqpw for <openpgp@ietfa.amsl.com>; Tue, 29 Sep 2015 06:54:20 -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 4370D1B3FDE for <openpgp@ietf.org>; Tue, 29 Sep 2015 06:54:20 -0700 (PDT)
Received: from tormenta.local (iang.org [209.197.106.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by virulha.pair.com (Postfix) with ESMTPSA id 37A816D77F; Tue, 29 Sep 2015 09:54:19 -0400 (EDT)
To: openpgp@ietf.org
References: <878u84zy4r.fsf@vigenere.g10code.de> <55FD7CF0.8030200@iang.org> <87io742kz7.fsf@latte.josefsson.org>
From: ianG <iang@iang.org>
Message-ID: <560A982A.1040409@iang.org>
Date: Tue, 29 Sep 2015 09:54:50 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <87io742kz7.fsf@latte.josefsson.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/openpgp/HpVVHi_4-ggoF4Biiy-KkhV2A18>
Subject: Re: [openpgp] New fingerprint: to v5 or not to v5
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, 29 Sep 2015 13:54:22 -0000

On 21/09/2015 05:13 am, Simon Josefsson wrote:
> ianG <iang@iang.org>; writes:
>
>> Hi Werner,
>>
>>
>> On 17/09/2015 19:41 pm, Werner Koch wrote:
>>> I'd like to get opinions on one specific aspect of a new fingerprint
>>> format in 4880bis.
>>>
>>> In the past we bound the fingerprint format to the key packet version:
>>> v3 keys used MD5 and v4 keys SHA-1 fingerprints.  This gained us the
>>> benefit of having a bijective connection between fingerprint and key.
>>
>> I'm hugely on that side.  I'll always vote for that.  I even staked my
>> rep on it :)
>>
>> http://iang.org/ssl/h1_the_one_true_cipher_suite.html
>>
>> Which came directly from the experience of hacking PGP & OpenPGP in
>> Perl/Java as part of Cryptix.  The tears, the fears, the costs.
>>
>> So:  the only choice for me is which hash you pick for v5.  If you
>> want another one, start planning for v6.
>
> +1
>
> I believe sub-negotiating in security protocol leads to obscure problems
> and makes security evaluation harder.  If we can avoid that, and that
> appears to be the case, I'm all for it.
>
> Regarding which hash to use, SHA-256 is probably the simplest choice
>  From a practicallity and consensus point of view.  Are there any strong
> reasons to favor something else?
>
> What would be the relevant options be anyway?  SHA-256, BLAKE2,
> SHA3-256, SHA-512, CubeHash?  Would there be value in being able to use
> variable length SHAKE variants?


There are a few reasons to go to SHA3 or SHAKE, as far as I see it.

1.  It leaps us ahead by about a decade in terms of cryptographic 
experience.

2.  It can do any size so we can use the same algorithm for all the 
different uses, without getting into esoteric arguments about 
truncation.  Indeed this is intended -- although rare, the team that 
made SHA3 felt our pain and improved our interface to the black box 
known as the message digest.

3.  This further leads to the possibility that if we get scared of the 
"short" length, we can just lengthen the base array and let the software 
work it out.  Similar to PHB's concept, we could just pre-ordain some 
applicable lengths that work for all purposes.

4.  The same base algorithm can be used as a symmetric AE cipher.  This 
leads to the possibility of one algorithm family giving most of the 
cryptographic needs (we'd need an asymmetric one too).  The development 
savings and the size savings are not to be sniffed at:  leads to small 
lightweight deployments e.g., on IoT and many more and maintainable 
language implementations.

5.  As a higher level meta-advantage, getting us away from the alphabet 
soup approach to protocol design might clarify to us why it is that 
there is an advantage in having more than one of everything around.




iang