Re: [Cfrg] Ed448 hash choice

["Blumenthal, Uri - 0553 - MITLL" <[e-mail]>]

> It is hard for me to understand why TLS 1.3 is not using SHA3 right now. The
> protocol is completely new,  implementing a new simple elegant SHA3 function
> would be a very small expense.
> 
> 
> 
> A SHA3 function at 256 bit of security level would be security efficient for
> all purposes and cipher suites. It can be used to build a much more efficient
> and elegant key derivation method than what is currently specified.
> 
> 
> 
> Later, one could have an authenticated encryption based on Keccak. That would
> make the protocol very elegant. As Gilles from the Keccak team pointed out
> Keccak is very green which is a huge benefit.


+1



> On 10/21/2015 09:23 AM, Blumenthal, Uri - 0553 - MITLL wrote:
>>> Is the point of this exercise to find a generic solution so that we can add
>>> support for new curves without another quagmire of polling?  If that's the
>>> problem, then it seems we have to either:
>>> 
>>> 1) Use SHA-512/n for everything including Ed25519 and Ed448, as DJB
>>> specified.
>> 
>> It seems that the consensus has been to not use SHA-512/n, or any other
>> construct that would “contort” SHA-2.
>> 
>>> 2) Use SHAKE256 for everything including Ed25519 and Ed448, which will annoy
>>> existing users.
>> 
>> I’d be happy with this decision, BTW.
>> 
>>> 3) Give up and say it's per curve or per deployment or whatever, in which
>>> case we can use SHA512 for Ed448.
>> 
>> Or 4) Keep using whatever we use now for Ed25519, and use SHAKE256 for Ed448.
>> 
>>> Right?
>> 
>> Almost. :-)
> I'm happy with SHAKE256 and 912 bits.  I don't see it as an especially better
> or worse option than SHA-512.  Is the idea that SHAKE-256 will be the default
> choice for any future curves as well, unless there is further discussion about
> them?
> 
> Two other issues while we're on this topic:
> 1) I don't especially like mandating the prehash, because for TLS we will want
> to sign hashes of the running session state, which are already going to be
> SHA256.  If the prehash is something else, users will need an extra running
> hash context during the handshake.  (Not to mention that by mandating any hash
> that's not SHA256, we're forcing IoT devices to implement multiple hashes
> which isn't free.)
> 
> 2) Are we really going to give up on having a single key compatible with EdDSA
> and EdDSAph?  That seems like an unnecessary proliferation.  I would have
> liked keys which can be used for DH and signing, but not allowing both signing
> algorithms is frustrating.
> 
> Cheers,
> -- Mike