Re: [Cfrg] Poll: hash functions for Ed448 (ends on December 22nd)
Phillip Hallam-Baker <phill@hallambaker.com> Wed, 09 December 2015 18:13 UTC
Return-Path: <hallam@gmail.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03F0E1B2BB0 for <cfrg@ietfa.amsl.com>; Wed, 9 Dec 2015 10:13:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.155
X-Spam-Level:
X-Spam-Status: No, score=-0.155 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URI_HEX=1.122] autolearn=no
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 Y0TrIicdQbNk for <cfrg@ietfa.amsl.com>; Wed, 9 Dec 2015 10:13:13 -0800 (PST)
Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F3391A0204 for <cfrg@irtf.org>; Wed, 9 Dec 2015 10:13:12 -0800 (PST)
Received: by lfdl133 with SMTP id l133so40101911lfd.2 for <cfrg@irtf.org>; Wed, 09 Dec 2015 10:13:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=NybqiFkH7VGRkWZt8SQgxKm3zuz0HCqQEtbBV/wYJyU=; b=oQqqppLlxrh3V5MQ6y1VKxCHlpG/ENC7zPql8M1ZAxOAcs5GKC+f3LT+VDVJBJefsz C9MFIO5WuVCF1KTMrr6AgH7x4+wUzljxFN1fua5VuSCUHdS27S0RjwwNdzmXvOLAKTO0 TZLkKaN3RaprOeSqNyECrvfQ8j+q1B8mlMFZXhHzXXKu1XYYD7zLQpnxn2omgwhvq/Vt bwxhS9nDEmQi3PXIpSfMGYp4CSTkwsnC0+5MU6otxlcVHiuK/b031hklnnPs+DrJ8CYw 3TGR6c7rXA0VCNpB2u+PQwL5ZhgJJ6jzw7Td7nYX7rC4JRWuOJv+UR0JDfta7vJ+sEy+ snag==
MIME-Version: 1.0
X-Received: by 10.25.156.73 with SMTP id f70mr2953844lfe.70.1449684790587; Wed, 09 Dec 2015 10:13:10 -0800 (PST)
Sender: hallam@gmail.com
Received: by 10.112.1.227 with HTTP; Wed, 9 Dec 2015 10:13:10 -0800 (PST)
In-Reply-To: <5666F7A9.7020608@isode.com>
References: <5666F7A9.7020608@isode.com>
Date: Wed, 09 Dec 2015 13:13:10 -0500
X-Google-Sender-Auth: Rz5bVlBeMA3b8Jqyn9rAbAqXFoo
Message-ID: <CAMm+LwgWA3NGL3MgurT9CYG9HExVWWCgCOLHsatdBiyYev9b9g@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
To: Alexey Melnikov <alexey.melnikov@isode.com>
Content-Type: multipart/alternative; boundary="001a114017c6fab75605267b0a01"
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/-7fsURJYmcijxx9Ww_rD9CsWPu8>
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] Poll: hash functions for Ed448 (ends on December 22nd)
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Dec 2015 18:13:20 -0000
0: twoshakes-s: prefer twoshakes-d. +1: twoshakes-d: domain separation is a nice property 0: prefer Simon-2 or twoshakes-d. +1: Simon-2 -1: ilari1. No, mixing up two different hashes in that fashion might give you the stronger of the two, but it is also giving the attacker two systems to attack and you might well find that a break of either one will work. -1: ilari2. I think the SHAKE functions are a better way to go than HKDF. My preference is that in the future, every IETF crypto primitive has two preferred options, a mandatory to implement and a 'hot backup'. Right now SHA-2 is the best choice for mandatory to implement on the basis of performance and deployment. But I also want to see SHA-3 implemented in every toolkit so that it is ready for use as a hot backup. So my preferred choice would be to specify twoshakes-d AND Simon-2 in a plug interchangeable fashion. This would only be a little bit extra work for the WG now but means that folks writing toolkits have a lot less work to do. 90% of the implementation effort for crypto goes into writing the validation suites and running the permutations. I would like to have that all happen and be done. >From a protocol design point of view, I would like to see us move to using the SHAKE functions as the primitive to build protocols on. HKDF and HMAC are two constructions that were very much constrained by the circumstances in which they were designed. People wanted a very conservative design because they were not confident of the available review resources. The SHAKE functions have been subjected to a lot of review. So my proposal is: 7) Do twoshakes-d and Simon-2 Yes, this results in two different signature algorithms, but if you look at the crypto identifiers for signature algorithms, most of them are for the signature, hash combo 'RSA-with-MD5'. Yes, I know that here we have an internal and an external hash thing going on. The point is that digest function and signature have always been very closely related. In fact in quite a few protocols you see the RSA ( SHA2 ( SHA2 (Data))) because the deployment constraints make you want to break those two apart and the crypto libs available don't allow that. I don't think it would be a bad thing to have the default set be: RSA2048-SHA2 [Incumbent, expecting this to be replaced] Curve25519-SHA2 Curve448-SHA2 Curve448-SHA3 The reason for dropping Curve25519-SHA3 out of the set is that right now I see it as a hot backup. I am going to make sure that I have all the keys/certs etc. that I might need in place so that I can switch to that if there is a disaster but I don't need a high security and a ludicrously high security keystrength for that. Just give me ludicrously high for both. [Yes I am also thinking about backup plans to save crypto if quantum crypto strikes. But right now, those involve Kerberos type approaches.] Of course people are going to specify the code point for Curve25519-SHA3 and test it etc. but in terms of load on applications, I am seeing us put 3 new options on the table, not 4. I expect the future WebPKI to be based on Curve448-SHA2 roots. On Tue, Dec 8, 2015 at 10:30 AM, Alexey Melnikov <alexey.melnikov@isode.com> wrote: > This message starts 2 weeks Quaker Poll on hash functions to be used for > definition of Ed448 in draft-irtf-cfrg-eddsa. Please reply for each choice: > +1, if you prefer a particular choice > 0, if you can live with it > -1, if you are against a particular choice > > Choices are: > > 1) "twoshakes-s", (SHAKE256@912(x) for the internal hash, SHAKE256@512(x) > as the prehash) > > More details: < > http://www.ietf.org/mail-archive/web/cfrg/current/msg07629.html> > > 2) "twoshakes-d", > > This scheme again uses the SHAKE256 extensible-output functions (XOFs) to > implement both hashes, with the inputs prefixed as specified below for > explicit domain separation purposes. > > More details: < > http://www.ietf.org/mail-archive/web/cfrg/current/msg07629.html> > > 3) "simon1" (SHAKE256@912(x) for the internal hash, SHA3-512 as the > prehash). > > 4) "simon2" (Use SHA2-512/912 as described in [1] as the internal hash and > SHA2-512 as the prehash). > > [1] - <http://ed25519.cr.yp.to/eddsa-20150704.pdf> > > 5) "ilari1" (SHAKE256@912bits(x) for the internal hash, SHA2-512(x) as > the prehash) > > More details: < > http://www.ietf.org/mail-archive/web/cfrg/current/msg07644.html> > > 6) "ilari2" > > Hash: HKDF-EXPAND(hash=SHA2-512, prk=HKDF-EXTRACT(hash=SHA2-512, > salt=<blank>, ikm=x), info=<blank>, 114) Prehash: SHA2-512(x) > > More details: < > http://www.ietf.org/mail-archive/web/cfrg/current/msg07644.html> > > 7) You can specify an alternative proposal, if you wish > > Best Regards, > Kenny and Alexey > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg >
- [Cfrg] Poll: hash functions for Ed448 (ends on De… Alexey Melnikov
- Re: [Cfrg] Poll: hash functions for Ed448 (ends o… Blumenthal, Uri - 0553 - MITLL
- Re: [Cfrg] Poll: hash functions for Ed448 (ends o… Tony Arcieri
- Re: [Cfrg] Poll: hash functions for Ed448 (ends o… Aaron Zauner
- Re: [Cfrg] Poll: hash functions for Ed448 (ends o… Damien Miller
- Re: [Cfrg] Poll: hash functions for Ed448 (ends o… Bryan Ford
- Re: [Cfrg] Poll: hash functions for Ed448 (ends o… Simon Josefsson
- Re: [Cfrg] Poll: hash functions for Ed448 (ends o… Ilari Liusvaara
- Re: [Cfrg] Poll: hash functions for Ed448 (ends o… Russ Housley
- Re: [Cfrg] Poll: hash functions for Ed448 (ends o… Phillip Hallam-Baker
- Re: [Cfrg] Poll: hash functions for Ed448 (ends o… Gilles Van Assche
- Re: [Cfrg] Poll: hash functions for Ed448 (ends o… Rene Struik
- Re: [Cfrg] Poll: hash functions for Ed448 (ends o… James Cloos
- Re: [Cfrg] Poll: hash functions for Ed448 (ends o… Alyssa Rowan
- Re: [Cfrg] Poll: hash functions for Ed448 (ends o… Mike Jones
- Re: [Cfrg] Poll: hash functions for Ed448 (ends o… Ruggero SUSELLA
- Re: [Cfrg] Poll: hash functions for Ed448 (ends o… Mike Hamburg
- Re: [Cfrg] Poll: hash functions for Ed448 (ends o… Ruggero SUSELLA
- [Cfrg] Poll Results: hash functions for Ed448 Alexey Melnikov
- Re: [Cfrg] Poll Results: hash functions for Ed448 Alexey Melnikov