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
>