Re: [Cfrg] On the differences of Ed25519/448 and how it affects a vote on twoshakes-d

[Tony Arcieri <[e-mail]>]

On Mon, Dec 28, 2015 at 8:15 AM, Alexey Melnikov <[e-mail]>
wrote:

> My personal preference would be to use the decision for 448 as the
> future template, however I realize that that might be a rathole I would
> rather not descend into right now.
>
> So realistically, if CFRG ever to recommend another EC curve, we would
> have to [quicly] revisit hash choices. As a co-chair, I would like to
> see a justification why future hash choices would be different from what
> we pick for Ed448.


As someone who +1'd twoshakes-d for the Ed448 decision, I guess it's
probably a bit late to change my mind, and once the SHA2/3 families are
agreed upon as standards, there's little need to change.

The only reason I have any reluctance is because there haven't been, to my
knowledge, any sort of attack on the SHA2 family, and it continues to
provide the best performance.

Ryan Sleevi recently detailed a history of the role of (broken) hash
functions in digital signatures on TLS certificates:

https://medium.com/@sleevi_/a-history-of-hard-choices-c1e1cc9bb089#.ykzwmnjyp

My main takeaway from this was if there were any reason to doubt the SHA2
family now, we should immediately move away from it, but thus far there is
not.

I don't doubt that SHAKE256 is the more conservative choice, but I do speak
as someone who cares about the capacity of TLS-terminating frontend
servers. I'm guessing people who are interested in FourQ would probably
want the most performant option in a hash function (given the performance
impact of scalar multiplication will greatly outweigh that of calculating a
hash)

I guess my point is: if this is to be a framework for future curves, is
there any possibility of specifying both a SHA2 and SHA3 option?
(effectively parameterizing the signature algorithm around a hash function
in addition to a curve)

--
Tony Arcieri