Subject: [Cfrg] Ed448 hash choice

From: Simon Josefsson <[email-masked]>
Date: Fri, 16 Oct 2015 11:35:53 +0200

Let's try to summarize where we are.

First I'd like to establish something around Ed25519: It uses SHA2-512
for the internal hash and the pre-hash is Ed25519ph.  I don't recall any
objections to this, and this has been deployed and is in use already.
So let's focus on Ed448(ph).

I don't believe we can make separate decisions on 1) the internal hash
function and 2) the pre-hash function.  The preferences regarding one of
them typically depend on what the other will be, and vice versa.

So far, I've seen several people support SHAKE256 over SHA2 for the
internal hash of Ed448 (please correct me if I misinterpreted your
emails): Uri Blumenthal, Taylor R Campbell, Damien Miller, Dan Brown,
James Cloos, Alyssa Roawn, Peter Schwabe.  But it hasn't been clear what
the pre-hash algorithm would be if SHAKE256 is used internally.
Summarizing again options:

1) SHAKE256 for internal hash and SHA3-512 for pre-hash.

2) SHAKE256 for internal hash and SHA2-512 for pre-hash.

3) SHA2-512/912 for internal hash and SHA2-512 for pre-hash.

4) HKDF-SHA2-512 for internal hash and SHA2-512 for pre-hash.

5) Blake2.  This came up recently, and probably needs more fleshing out.
I assume (hope) people talk about Blake2b, not Blake2s.  The challange
with Blake2b is the same as for SHA2: it cannot support 912-bit outputs.
So to be able to use Blake2b we have to build a 912-bit hash.  Ideas
include:

   5A) HKDF-Blake2b for internal hash and Blake2b for pre-hash.

   5B) HKDF-Blake2b for internal hash and SHA2/SHA3-512 for pre-hash.

   5C) Homebrew CTR-mode of Blake2b for internal hash, and Blake2b for
   pre-hash.

   5D) Homebrew CTR-mode of Blake2b for internal hash, and SHA2/SHA3-512
   for pre-hash.

   5E) Homebrew concatenated mode (same as homebrew SHA2 idea below) of
   Blake2b for internal hash, and Blake2b/SHA2/SHA3-512 for pre-hash.

   5E) Blake2b with personalization string (e.g., eddsa-912-1 and
   eddsa912-2 as suggested by Jean-Philippe) for internal hash, and
   Blake2b/SHA2/SHA3-512 for pre-hash.

Did I miss any option?

If people can agree the above is a complete summary of options, maybe we
can formulate a poll around this.

For completeness, I believe the following ideas are non-starters:

A) SHA2-based internal hash and SHA3 for pre-hash -- the only reason for
chosing SHA2 internally appears to avoid SHA3 dependency.

B) Homebrew SHA2-variant a'la Truncate-912-bits(SHA512("0" | M) |
SHA512("1" | M)) for internal hash -- several people disliked it.

/Simon

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 16 Oct 2015 15:04:47 +0000

On Fri, Oct 16, 2015 at 11:35:53AM +0200, Simon Josefsson wrote:

> ...

Is there a good reason to not consider SHAKE256 also as the prehash?

 1.5) SHAKE256 for internal hash and SHAKE256 for pre-hash.

-- 
	Viktor.

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Fri, 16 Oct 2015 16:13:54 +0000

> 1.5) SHAKE256 for internal hash and SHAKE256 for pre-hash.

+1 for 1.5 (SHAKE256 for internal hash & for pre-hash).

---

From: Alyssa Rowan <[email-masked]>
Date: Fri, 16 Oct 2015 21:07:26 +0100

> 1.5) SHAKE256 for internal hash and SHAKE256 for pre-hash.

Another +1 for this option overall - it makes perfect sense.

BLAKE2 is brilliant, and I'm OK with that too, but we've got
choices to make as to how to stretch it if we use that.

Using the SHAKE256 XOF, and sticking with that for Ed448, seems
like the most natural solution to me.

Remember that NIST approved SHAKE256 as an XOF, _not_ a hash
function, because different length outputs of the SHAKE* functions
with the same inputs share prefixes. Maybe avoid calling it a hash?

As Taylor suggests, for that reason, domain-separation of the two
uses would be a sensible, conservative choice to avoid any potential
problems.

- -- 
/akr

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 17 Oct 2015 09:19:33 +0200

> uses would be a sensible, conservative choice to avoid any potential

Thanks to all for adding the SHAKE256+SHAKE256 option.

I generally like the idea of using the same internal hash as the
pre-hash for Ed448.  However I'm a bit uncomfortable picking something
not intended to be used as a hash function and use it as a hash
function.  Not calling it a hash doesn't seem to be an option, since we
use it as a hash and depend on the traditional cryptographic hash
properties (pre-image+collision).

If someone could provide details of how to use it and a substantial
argument why it provides sufficient security guarantees [1], I would
likely support SHAKE256+SHAKE256 as well.

Does anyone have any strong preference AGAINST using a
truncated-and-possibly-domain-separated SHAKE256 as the prehash?

/Simon

[1] Preferrably in a form that could go into the document :-)

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 17 Oct 2015 13:03:26 +0300

> properties (pre-image+collision).

Well, "function", and then specify CR for the function? I don't think
we need PIR (beyond CR).

(One can easily prove the identity function is CR).

> likely support SHAKE256+SHAKE256 as well.

Basically, H(x)=PH(x)=SHAKE256[output = 912 bits](x).

The current best estimates for stand-alone security:
Collision: ~2^256
Preimage1: ~2^256
Preimage2: ~2^256

(Should be enough: There is ~2^224 universal forgery attack (dlog the
public key)).

As for cross-function security, there are no valid attacks, since PH
is fixed by the scheme and there is explicitly no cross-scheme
security.

And for using the same function for both, if that is a problem, there
is already a problem with Ed25519ph (with it using SHA-512 for two
purposes).

> truncated-and-possibly-domain-separated SHAKE256 as the prehash?

One has to be bit careful with domain separation as not break using
the same quasi-hash function for both (API limitations).

-Ilari

---

From: Natanael <[email-masked]>
Date: Sat, 17 Oct 2015 13:44:05 +0200

> with the same inputs share prefixes. Maybe avoid calling it a hash?

I'd like to note two things:

1) from my point of view as a novice, it resembles a stream cipher with
arbitary size keys.

2) prefixing the data to process with the output size parameter (196 for
196 bits, 512 for 512 bits, etc) will effectively ensure the prefix isn't
shared for different calls to the function where different lengths are
requested. Thus acting like the hashes you'd normally expect to see.

---

From: Gilles Van Assche <[email-masked]>
Date: Mon, 19 Oct 2015 17:29:57 +0200

> properties (pre-image+collision).

SHAKE128 and SHAKE256 implement a generalized hash function. Their exact
claimed security can be found in Section 1.5 of [Bertoni et al., The
Keccak reference, http://keccak.noekeon.org/Keccak-reference-3.0.pdf],
with c=256 and c=512, respectively. In particular, when restricted to
their first d output bits, they become d-bit hash functions with
security strength 128 and 256 bits, resp., as summarized in Section A.1
of [FIPS 202].

The only "catch" is that a XOF cannot be directly used to generate a
family of hash functions in the tradition of {SHA-1, SHA-224, …,
SHA-512} since these latter functions simultaneously provide different
output lengths *and* unrelated outputs. E.g., if a system uses SHA-512
and SHA-384 and relies on the property that they provide two unrelated
digests, than SHAKE256 truncated to 512 and 384 bits cannot be used as
such. Instead, one could use domain separation, e.g.,
F0(x);=SHAKE256(x|0) and F1(x):=SHAKE256(x|1); the resulting functions
F0(x) and F1(x) generate unrelated outputs for the same input x.

One notes that "different output lengths" and "unrelated outputs" are
orthogonal requirements in general, which can be satisfied
independently: output length can be varied by truncation, while
unrelated outputs can be obtained with domain separation.

> Basically, H(x)=PH(x)=SHAKE256[output = 912 bits](x).

Yes, except that I would keep the pre-hash to 512 bits of output [*]. So:
H(x) = SHAKE256(x) truncated to 912 bits
PH(x) = SHAKE256(x) truncated to 512 bits

> The current best estimates for stand-alone security:

I agree, and also any other attack ~2^256 unless easier on a random oracle.

[*] Even 448 bits would be enough for the pre-hash.

Kind regards,
Gilles

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 19 Oct 2015 19:49:52 +0300

> PH(x) = SHAKE256(x) truncated to 512 bits

Except if one has Lookup-Reset-Update-Final type API, SHAKE256@512b
and SHAKE256@912b are two different (quasi-)hash functions (nevermind
how much those two have in common).

(To compute both using the same (quasi-)hash in such API, one would
have to compute it first at 912 bits and then to truncate the 912
bit result to 512 bits post-hashing).
 
> [*] Even 448 bits would be enough for the pre-hash.

Careful. The strength scaling of hashes and ECC is different, so
"WF224 for both" is meaningless. ECC tends to scale better than
symmetric crypto, so symmetric crypto should have higher "WF"
(unless either hits stratosphere anyway).

-Ilari

---

From: Dan Brown <[email-masked]>
Date: Mon, 19 Oct 2015 17:52:50 +0000

Clarifying my preferred hash for Ed448:

1) For message digesting, i.e. all the hashing done by the verifier:
Pre-hash = internal hash = H = SHA3-512
So both the signer and verifier compute H(R,H(M))

2) For key derivation, i.e. secret integers computed by the signer:
PRF-hash = SHAKE256

Of the above, 1 is a strong preference, while 2 is a weak preference.

Why I recommend different hashes for the different tasks:

In the message digesting, no inputs are secrets, yet resisting forgery
depends on the security of H.  For these types of no-secret security
properties, I feel that the extra-large pipe of 1024 in SHA3-512 is a
reasonable security cushion for the hash, i.e. compensation for the lack of
a secret input.  

Sorry if I'm being a bit harsh on hashes here. But when I recall the MD5 and
SHA1 collision and length extension attacks, and the novel ways in which we
are relying on hashes, I gravitate to a security buffer.

For key derivation, there are secret inputs, so I see less need for the
extra-wide pipe.  But there is more need for proper expansion, and SHAKE256
is already established for this.    Possible alternatives: HKDF or the
various methods in the generalized EdDSA proposal (applied to SHA3-512, or
some other Keccak).

Sorry for my earlier mistake of recommending SHAKE256 for the internal hash:
I was misinterpreting what the EdDSA internal hash to mean the key
derivation steps.  This correction should now align pretty much with what I
recommended in my ECDSA_CFRG proposal, so at least I am not contradicting
myself.

---

From: "Dang, Quynh" <[email-masked]>
Date: Tue, 20 Oct 2015 13:01:48 +0000

Hi Dan,

SHAKE256 if being used as 512-bit hash function is a wide-pipe hash function: the rate r is (1600 - 512) 1088 bits, but the hash output is only 512 bits.

Regards,
Quynh. 

________________________________________
From: Cfrg <[email-masked]> on behalf of Dan Brown <[email-masked]>
Sent: Monday, October 19, 2015 1:52 PM
To: [email-masked]'; [email-masked]'
Cc: [email-masked]'
Subject: Re: [Cfrg] Ed448 hash choice

---

From: "Dang, Quynh" <[email-masked]>
Date: Tue, 20 Oct 2015 14:21:23 +0000

To clarify my previous message, If you successfully find a collision on the hash value, then the extension property does not happen. However, if you successfully find a collision on the c bits of the permutation, then the extension property happens. But, this is 2^256 work factor for SHAKE256.  

Regards,
Quynh. 

________________________________________
From: Cfrg <[email-masked]> on behalf of Dang, Quynh <[email-masked]>
Sent: Tuesday, October 20, 2015 9:01 AM
To: Dan Brown
Cc: [email-masked]'
Subject: Re: [Cfrg] Ed448 hash choice

Hi Dan,

Regards,
Quynh.

_______________________________________________
Cfrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/cfrg

---

From: Mike Hamburg <[email-masked]>
Date: Tue, 20 Oct 2015 23:15:15 -0700

Sorry to be late to the party here, but is it strictly necessary that we 
accept the draft as-is, instead of setting the key derivation as 
SHA-512?  Even SHA-512/446 would be safe.  Or we could use SHA3-512 for 
both of them.  I understand that we agreed to do EdDSA, and the new 
EdDSA spec says 912 bits (and not 896 bits for some reason?).  But if 
following this unnecessary aspect of the spec is causing this much 
trouble, perhaps we should change that constant to avoid the trouble.

It is my impression that DJB would not have specified SHA-512 for EdDSA 
1.0 if it had been much more horrible than SHA-256.  But since SHA-512 
was available, and indeed was faster than SHA-256, it was convenient to 
use the extra-wide function.  In the present case, we have a perfectly 
adequate function in SHA-512, and we do not have as easy a choice for 
912-bit hash.

Cheers,
-- Mike

On 10/16/2015 2:35 AM, Simon Josefsson wrote:
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cfrg

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 21 Oct 2015 16:20:52 +0300

On Tue, Oct 20, 2015 at 11:15:15PM -0700, Mike Hamburg wrote:
> accept the draft as-is, instead of setting the key derivation as SHA-512?

Well, the only place where there are significant compat conerns is Ed25519,
which seemingly has consensus on using SHA-512.

The hash function and prehash function for Ed448 are very much TBD.

> Even SHA-512/446 would be safe.  Or we could use SHA3-512 for both of them.

Well, pretty the only things SHA-3 has over SHA-2:
- Mode with longer outputs (SHAKE)
- Resistance to extension attacks

Now, the second doesn't matter here. And if needed output is 512 bits, why
not just use SHA-512?

> I understand that we agreed to do EdDSA, and the new EdDSA spec says 912
> bits (and not 896 bits for some reason?).

It is 912, because p must fit into b-1 bits, that is b>=449, and since b
should be multiple of 8, that means b=456. And that impiles 2b=912-bit
"hash".

>  But if following this unnecessary aspect of the spec is causing this
> much trouble, perhaps we should change that constant to avoid the
> trouble.

The hash shared between signer and the verifier is the H(R,A,M) in
formula for S. for 448-bit curve, 512-bit hash there should be more than
enough (in fact, 512-bit hash should be more than enough for any curve).

But EdDSA also uses the H for internal key derivations. And those
derivations assume double-width hashes.

> It is my impression that DJB would not have specified SHA-512 for EdDSA 1.0
> if it had been much more horrible than SHA-256.  But since SHA-512 was
> available, and indeed was faster than SHA-256, it was convenient to use the
> extra-wide function.  In the present case, we have a perfectly adequate
> function in SHA-512, and we do not have as easy a choice for 912-bit hash.

Well, AFAIK, DJB could have used much weaker function (doesn't have to be
collision-resistant!), but chose SHA-512 just to be conservative (the
speed difference isn't much with realistic message lengths).

And the problem with SHA-512 is the output length.

-Ilari

---

From: Watson Ladd <[email-masked]>
Date: Wed, 21 Oct 2015 09:51:37 -0400

> > accept the draft as-is, instead of setting the key derivation as
SHA-512?
> derivations assume double-width hashes.

But they don't need to: 64 extra bits reduces the discrepancy FFT attacks
rely on to very small levels. I don't think people realize that SHA512 can
be used in Ed448.

---

From: Mike Hamburg <[email-masked]>
Date: Wed, 21 Oct 2015 09:10:30 -0700

On 10/21/2015 6:51 AM, Watson Ladd wrote:
>
>
> On Oct 21, 2015 9:21 AM, "Ilari Liusvaara" <[email-masked] 
> <mailto:[email-masked]>> wrote:
> >
> But they don't need to: 64 extra bits reduces the discrepancy FFT 
> attacks rely on to very small levels. I don't think people realize 
> that SHA512 can be used in Ed448.
>
Right.  More specifically, on a generic curve, 64 extra bits would be 
enough to defeat known attacks, but not enough to rule out unknown 
ones.  But on a near-power-of-2 curve like Ed448, 64 extra bits or even 
no extra bits are enough.

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.

2) Use SHAKE256 for everything including Ed25519 and Ed448, which will 
annoy existing users.

3) Give up and say it's per curve or per deployment or whatever, in 
which case we can use SHA512 for Ed448.

Right?
-- Mike

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Wed, 21 Oct 2015 16:23:19 +0000

> 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. :-)

---

From: Mike Hamburg <[email-masked]>
Date: Wed, 21 Oct 2015 10:08:26 -0700

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:
>
> 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.
>
>
>     3) Give up and say it's per curve or per deployment or whatever,
>     in which case we can use SHA512 for Ed448.
>
>
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

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Wed, 21 Oct 2015 17:35:23 +0000

>> Or 4) Keep using whatever we use now for Ed25519, and use SHAKE256 for Ed448.
> 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?

That’s what I want and hope for, though the rest of the group may have other
preferences. IMHO *at this time* SHAKE256 seems the best candidate for
future-proof approach.

> 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.)

Ohh-hand, no comment or opinion.

> 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.

Off the record (because off-hand I can’t think through all the implications
and consequences), I agree.

---

From: "Dang, Quynh" <[email-masked]>
Date: Wed, 21 Oct 2015 18:15:14 +0000

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.

Quynh.

________________________________
From: Cfrg <[email-masked]> on behalf of Mike Hamburg <[email-masked]>
Sent: Wednesday, October 21, 2015 1:08 PM
To: Blumenthal, Uri - 0553 - MITLL; Watson Ladd; Ilari Liusvaara
Cc: Simon Josefsson; [email-masked]
Subject: Re: [Cfrg] Ed448 hash choice

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:

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.

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

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Wed, 21 Oct 2015 18:28:34 +0000

> 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

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 21 Oct 2015 22:12:51 +0300

On Wed, Oct 21, 2015 at 06:15:14PM +0000, Dang, Quynh wrote:
> It is hard for me to understand why TLS 1.3 is not using SHA3 right now.

Basically, the only new crypto thing TLS 1.3 has over TLS 1.2 are:
- Being able to accomodate PRF-hash >384 bits
- Being able to accomodate variable-expansion AEAD.

And unless ciphersuite involves either of those, it should work in
TLS 1.2 just as well. So if one added ciphersuite with SHA-3 PRF,
it would likely work in TLS 1.2 too.

If you are talking about fixing TLS 1.3 PRF-hash to SHA-3, then I
regard fixing that a _very_ bad idea. TLS is very vulernable to
breakage of the prf-hash. Replacing it is horrible enough, but
if it takes a version bump, we are utterly screwed.

Also, with regards to performance, the performance of PRF-hash
is very minor aspect, since the amounts of data digested are
fairly minor.

Finally, it looks like TLS WG is against changing ciphersuite
negotiation in any way (heck, they rejected unifying Diffie-Hellman
or certificates in ciphersuites).

-Ilari

---

From: Quynh Dang <[email-masked]>
Date: Wed, 21 Oct 2015 15:26:17 -0400

Hi IIari,

> if it takes a version bump, we are utterly screwed.

In TLS 1.2, PRF depends on cipher suite, but default is HMAC with SHA256.
This default could be a SHA3 (no HMAC and no many rounds to generate keys).

> is very minor aspect, since the amounts of data digested are

I don't know minor or not. Assuming it is minor, a more efficient solution
is a more efficient solution.

> or certificates in ciphersuites).
Everything is built from a Keccak permutation including a possible
(potential) authenticated encryption function in the future and this would
be efficient!

Quynh.

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 21 Oct 2015 22:38:45 +0300

> This default could be a SHA3 (no HMAC and no many rounds to generate keys).

No ciphersuite that works with TLS 1.3 has default PRF. All the
ciphersuites have explicit PRF hashes.

The reason for this is that TLS 1.2 grandfathered SHA-256 PRF for old
ciphersuites but required explicit PRF for new ones. But none of these
old ciphersuites are AEAD, and thus none work with TLS 1.3.
 
> (potential) authenticated encryption function in the future and this would

Well, I don't think TLS WG would mind too much a draft specifying
ciphersuites with all symmetric parts based on Keccak (e.g. SHA3-256
PRF-hash and some Keccak sponge AEAD).

Unfortunately, it doesn't look like you can replace HKDF or even HMAC,
since those are seemingly fixed in the specs.

-Ilari

---

From: Tony Arcieri <[email-masked]>
Date: Wed, 21 Oct 2015 20:39:13 -0700

On Wed, Oct 21, 2015 at 9:23 AM, Blumenthal, Uri - 0553 - MITLL <
[email-masked]> wrote:

> add support for new curves without another quagmire of polling?  If that's
> the problem, then it seems we have to either:
>

I disagree with your perceived "consensus". My read of things is people are
generally rather ambivalent and support many proposals, and Mike's question
is rather important for framing the argument.

For example, I supported SHAKE256 as a "spinal tap grade"[1] option to go
along with Ed448, because I don't expect Ed448 will get a whole lot of
users as Curve25519/Ed25519 is good enough and faster and the things that
are likely to break it will probably break Ed448 too. So if we're picking
pie-in-the-sky primitives for a disaster scenario, why not? Of course, I
also said SHA-512 as described in the EdDSA paper or HKDF would be fine.

If the question at hand is the one Mike is asking about, i.e. a generic
solution to be used with future curves, that's a much different question,
and I expect it would influence people's decisions and whatever "consensus"
you think you're seeing. I also think it's the question we should probably
be asking.

[1]: https://silentcircle.wordpress.com/2013/10/17/this-one-goes-to-414/

-- 
Tony Arcieri

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 22 Oct 2015 11:04:39 +0200

Mike Hamburg <[email-masked]> writes:

> Sorry to be late to the party here, but is it strictly necessary that
> we accept the draft as-is, instead of setting the key derivation as
> SHA-512?  Even SHA-512/446 would be safe.  Or we could use SHA3-512
> for both of them.  I understand that we agreed to do EdDSA, and the
> new EdDSA spec says 912 bits (and not 896 bits for some reason?).  But
> if following this unnecessary aspect of the spec is causing this much

Right, and I think it is possible to discuss anything until the chairs
believe we are going around in circles and herds us out of it.

I believe that for Ed448 we have approached something that could be
tested for consensus around the internal hashes (i.e., use SHAKE256) but
the choice of prehash needs to be settled -- however picking SHAKE256
for the internal hashes implies to me that the choice for pre-hash
should be a Keccak-based design.

For Ed25519 I haven't seen anyone wanting to modify anything, and there
has been voices against modifying it.  I think attempting to change how
Ed25519 works at this point is plain stupid.

/Simon

> It is my impression that DJB would not have specified SHA-512 for
> EdDSA 1.0 if it had been much more horrible than SHA-256.  But since
> SHA-512 was available, and indeed was faster than SHA-256, it was
> convenient to use the extra-wide function.  In the present case, we
> have a perfectly adequate function in SHA-512, and we do not have as
> easy a choice for 912-bit hash.
>
> Cheers,
> -- Mike
>

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 22 Oct 2015 11:17:20 +0200

> further discussion about them?

I don't think anyone wants to bind us to a decision on other curves.
The chairs picked Curve25519 and Curve448.  We are now doing signatures
on those curves.  Other curves aren't on the table, as far as I
interpret things at least.

> to implement multiple hashes which isn't free.)

I'm not confident it is possible to design something that flexible and
secure.  First, TLS isn't always using SHA256, or are you thinking of an
TLS1.3-only world?  Secondly, prehash flexibility opens up for your next
question/concern.

> EdDSA and EdDSAph?  That seems like an unnecessary proliferation.

If someone can build a case for doing that securely with low complexity,
and preferrably without breaking Ed25519, it would be nice.  I'm not
sure that is possible to achieve at the CFRG-level, maybe it is only
possible on a higher level.  I tried a strawman:
https://moderncrypto.org/mail-archive/curves/2015/000630.html

> I would have liked keys which can be used for DH and signing, but not

The problem is preventing the obvious attack.  Right now, I'm in the
mind that to actually get closure on this work, it was simpler to reject
this possibility than to endeavour into designing new things.

/Simon

---

From: Björn Edström <[email-masked]>
Date: Thu, 22 Oct 2015 12:25:17 +0200

I'm gonna chime in with my two cents and vote for option 1, that is
SHAKE256 internally and SHA3-512 for the pre-hash. Ed25519 should be
left as-is.

I don't have super strong opinions on the above from a technical merit
and I will not sleep bad at night if another option is decided. I am
however getting quite strong opinions that a decision should be made
soon before a hundred more emails will be written on this (slightly
bikeshed-y) topic. :-)

1) The SHAKE256 construct is the most aesthetically pleasing of the
choices to get the conservative 912 bits the paper asks for. The EdDSA
paper asks for "A cryptographic hash function H producing 2b-bit
output." and I don't believe that this should be changed now just
because it is possible to solve the Ed448 case (barely) in a different
way (i.e. the point that Ed448 "could" use SHA2-512).

2) The SHA-3 standard is out and I see no danger in using it.  I don't
think this will hinder adoption as new code has to be written anyway.

3) The choice of SHAKE256 implies, as said, the choice of a Keccak
based construct for the pre-hash. SHA3-512 would be the conservative
choice.

4) I believe that regardless of what is recommended for Ed448ph,
people will use Ed448 on hashes in various ways anyway. So personally
I see Ed448ph more of a recommendation than a construct that really
needs to be specified to the same extent as Ed448. It could very well
be the case that the committee decides on one pre-hash and it will be
used completely differently in TLS.1.3 should TLS 1.3 get support for
a cipher suite with Ed448. So I don't think that the discussions about
what will happen with TLS 1.3 are relevant enough to change the work
on this draft.

Cheers
Björn

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 22 Oct 2015 12:32:45 +0200

> SHAKE256 internally and SHA3-512 for the pre-hash. Ed25519 should be

Maybe we can do a poll for complete Ed448 hash proposals to consider,
with a fixed timeline, and then a poll between these proposals, also
with a fixed timeline?  That seems to be one way of proceeding.

> soon before a hundred more emails will be written on this (slightly

We haven't discussed nearly as long as endianness yet. :-)

> what will happen with TLS 1.3 are relevant enough to change the work

It may be that TLS uses Ed25519/Ed448 directly instead of
Ed25519ph/Ed448ph too.  I don't believe pre-hashing make sense for
interactive TLS-like protocols that sign short messages.

/Simon

---

From: Björn Edström <[email-masked]>
Date: Thu, 22 Oct 2015 12:38:31 +0200

I like the idea of a time fixed poll to keep the work moving forward.
Kenny, Alexey?

(Also +1 for changing everything to big endian ;-)).

Cheers
Björn