Subject: Re: [Cfrg] draft-irtf-cfrg-eddsa-00

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Fri, 9 Oct 2015 18:23:45 +0000

I could certainly live with BLAKE2, but IMHO it would be ‎more prudent to stick with NIST-approved (standardized) algorithms.

Another possibility is offering "negotiable" options, but I suspect this group would prefer the "one function fits all" approach. ;-)

Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
  Original Message  
From: Paul Lambert
Sent: Friday, October 9, 2015 14:19
To: Ilari Liusvaara; Blumenthal, Uri - 0553 - MITLL
Cc: Simon Josefsson; [email-masked]; James Cloos
Subject: Re: [Cfrg] draft-irtf-cfrg-eddsa-00

On 10/9/15, 8:37 AM, "Cfrg on behalf of Ilari Liusvaara"
<[email-masked] on behalf of [email-masked]>
wrote:

>On Thu, Oct 08, 2015 at 08:41:07PM +0000, Blumenthal, Uri - 0553 - MITLL
>wrote:
>> 
>> >But I'd suggest ignoring sha3 and using shake256 for every type of
>> >digest needed by an ed448 ecosystem.
>> 
>> I'd probably prefer sha3 except where non-standard output length is
>> needed, but I would be happy with your suggestion too.
>
>FYI: SHA3-512 has the problem of being very slow[1].

Are we constrained to NIST approved hash algorithms?
If not, BLAKE2 has some impressive performance benefits:
https://blake2.net/ and
https://datatracker.ietf.org/doc/draft-saarinen-blake2/

Paul

>
>SHA3-256 or SHAKE256 (you need 512 bit output for 256-bit collision
>resistance) is like 85% faster. And even then those are slower than
>SHA-512 (apparently quite a bit on Skylake).
>
>
>[1] The reason for this is that 64-bit Keccak needs to have relative
>rate go way down in order to get 512-bit preimage resistance expected
>from 512-bit hash.
>
>
>-Ilari
>
>_______________________________________________
>Cfrg mailing list
>[email-masked]
>https://mail.ietf.org/mailman/listinfo/cfrg