Subject: [Cfrg] Poll: hash functions for Ed448 (ends on December 22nd)

From: Alexey Melnikov <[email-masked]>
Date: Tue, 08 Dec 2015 15:30:49 +0000

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

---

From: Tony Arcieri <[email-masked]>
Date: Tue, 8 Dec 2015 12:24:55 -0800

-1: twoshakes-s: prefer twoshakes-d
+1: twoshakes-d: domain separation is a nice property
-1: simon1: prefer twoshakes-d
+1: simon2: SHA2-512 would allow a single hash function for both Ed25519
and Ed448. SHA2-512 is the fastest option, and there is presently no reason
to suspect its security
-1: ilari1: I am uncertain of the advantages of mixing SHA2-512 and
SHAKE256. All of the other options use a single hash family
0: ilari2: HKDF is a nice standard construction but I don't see the
advantage over simon2

It would've been nice to see a SHA2-512-based option supporting domain
separation. I'm not prepared to specify it though.

-- 
Tony Arcieri

---

From: Aaron Zauner <[email-masked]>
Date: Tue, 08 Dec 2015 22:21:17 +0100

Hey,

> 0: ilari2: HKDF is a nice standard construction but I don't see the

The point made in this proposal is somewhat valid as HKDF is the
"standard" KDF in IETF and it's going to be used (in some form) in TLS
1.3 [OPTLS]. That being said; I can't see why we should not take the
simon2 proposal.

Aaron

[OPTLS] - https://eprint.iacr.org/2015/978.pdf

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Tue, 8 Dec 2015 21:36:05 +0000

+1: (1), (3)
 0: (2)
-1: (4), (5), (6)
-- 
Regards,
Uri Blumenthal

On 12/8/15, 10:30 , "Cfrg on behalf of Alexey Melnikov"
<[email-masked] on behalf of [email-masked]> wrote:

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

---

From: Damien Miller <[email-masked]>
Date: Wed, 9 Dec 2015 10:14:39 +1100 (AEDT)

> -1, if you are against a particular choice

twoshakes-d: 1
simon1: 1
simon2: 0
ilari1: -1
ilari2: -1
twoshakes-s: -1

---

From: Bryan Ford <[email-masked]>
Date: Wed, 9 Dec 2015 05:53:54 +0100

twoshakes-s: 0
twoshakes-d: +1
simon1: -1, because SHA3-512 is unnecessarily slow. 
simon2: 0
ilari1: -1, let's not require 2 totally different hash algs in 1 sig scheme.
ilari2: 0

Cheers
Bryan

> On Dec 8, 2015, at 4:30 PM, Alexey Melnikov <[email-masked]> 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) "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).
> 
> 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>
>

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 09 Dec 2015 09:56:08 +0100

My thinking is:

twoshakes-s: 0
twoshakes-d: -1 (complexity!)
simon1: 1 (simplicity, conservative, consistency with ed25519)
simon2: 0
ilari1: 0
ilari2: 0

I have started to feel that the fact that we can have this poll with no
real-world feedback from experience with deployed Ed448 implementations
is a sign that standardizing Ed448 is premature.  There simply appears
to be little interest from implementers, at least from what I can see
From my perspective.  I suppose it may be too late to back down from
this tree though.

/Simon

Alexey Melnikov <[email-masked]> writes:

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

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 9 Dec 2015 13:07:31 +0200

> From my perspective.  I suppose it may be too late to back down from

Well, if we had deployed Ed448 implementations, this whole poll would
likely have been unnecressary...

That said, there doesn't appear to be that much disagreement on the
main hash, just on prehash (which I think is more of invitation to
misuse, anyway).

That said, having written Python (reference) and C implementations for
Ed448, I would consider following proposals above others in
implementation annoyance (at least for modifying the present
implementation):

1) Twoshakes-d:
---------------
The contexts percollate all the way to the global API, and aren't
supported on Ed25519 anyway. Hashes are now multi-input and there
is now coupling between the prehash and primary.

(Yes, my proposal while back did similar things, but the API I
had in implementations was designed differently and cut in different
place).

2) Ilari 2:
-----------
Multi-input structure of HKDF is poor match for hash-function-like
construct. Needs IUF in IKM for efficient operation (wonder how many
ready-made implementations are capable of that?).

... Then there are non-implementation problems like speed problems
(SHA3-512) and bad usecases (SHA-512 prehash).

-Ilari

---

From: Russ Housley <[email-masked]>
Date: Wed, 9 Dec 2015 12:49:51 -0500

twoshakes-s: -1
twoshakes-d:  0
simon1: -1
simon2: +1
ilari1: -1
ilari2: 0

Rationale: simon2 allows SHA2-512 for both Ed25519 and Ed448.

Russ

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 9 Dec 2015 13:13:10 -0500

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 <[email-masked]>
wrote:

> 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>
>
> More details: <
> http://www.ietf.org/mail-archive/web/cfrg/current/msg07644.html>
>
> 6) "ilari2"
>
> More details: <
> http://www.ietf.org/mail-archive/web/cfrg/current/msg07644.html>
>

---

From: Gilles Van Assche <[email-masked]>
Date: Fri, 11 Dec 2015 17:26:43 +0100

- twoshakes-s:  0
- twoshakes-d: +1 (Or in general any variant that provides domain
separation in the internal hash between PureEdDSA and HashEdDSA. Bryan's
proposal is fine as is, but I am not against variants that can help
reach a consensus.)
- simon1:      -1 (It would be a pity to use a slower-than-needed hash
function.)
- simon2:      -1 (The construction behind the internal hash is less
efficient.)
- ilari1:       0
- ilari2:      -1 (The construction behind the internal hash is less
efficient.)

---

From: Rene Struik <[email-masked]>
Date: Fri, 11 Dec 2015 12:09:22 -0500

Dear colleagues:

I do concur with Gilles Van Assche's ranking (and earlier email on 
domain separation).

{As an aside: I am not sure whether one should standardize the 
"internal" hash, since untestable, but that is a different topic.}

Best regards, Rene

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: James Cloos <[email-masked]>
Date: Fri, 11 Dec 2015 13:18:18 -0500

twoshakes-s : +1
twoshakes-d : +1 (but prefer ts-s)
everything else : 0

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 0x997A9F17ED7DAEA6

---

From: Alyssa Rowan <[email-masked]>
Date: Sat, 12 Dec 2015 11:00:07 +0000

On 2015-12-08 15:30, Alexey Melnikov 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

twoshakes-s: 0   OK, but prefer twoshakes-d, because...
twoshakes-d: +1  domain separation for XOF of different length outputs.
simon1: 0        SHA3-512 is a bit slow.
simon2: 0        Could live with, but prefer Keccak to SHA-2 for Ed448.
ilari1: -1       Using both a legacy SHA-2 hash and Keccak is weird.
ilari2: 0        Could live with, but prefer Keccak to SHA-2 for Ed448.

For the record: I'm against any change to Ed25519, and I ... actually
don't care much about Ed25519ph because I don't plan on ever using it.

If I wanted to sign big files (or several big files), I'd probably
prefer to sign a BLAKE2b (b2sum) or some tree-hash manifest instead.
I have no other use-case for IUF.

- -- 
/akr

---

From: Mike Jones <[email-masked]>
Date: Sun, 13 Dec 2015 00:29:52 +0000

Please record my poll result as being the same as Russ's, for the same reasons.

				Thanks,
				-- Mike

-----Original Message-----
From: Cfrg [mailto:[email-masked]] On Behalf Of Russ Housley
Sent: Wednesday, December 9, 2015 9:50 AM
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Subject: Re: [Cfrg] Poll: hash functions for Ed448 (ends on December 22nd)

twoshakes-s: -1
twoshakes-d:  0
simon1: -1
simon2: +1
ilari1: -1
ilari2: 0

Russ

---

From: Ruggero SUSELLA <[email-masked]>
Date: Tue, 22 Dec 2015 11:18:22 +0100

1) twoshakes-s:  0. Simplest method, but I'd prefer to have domain separation.
2) twoshakes-d: +1. My preference.
3) simon1: 0. I can understand the use of SHA3-512 for prehash, although it's slower.
4) simon2:  -1. No mixing SHA-2 and SHA-3.
5) ilari1:  -1. I don't like SHA2-512/xxx where xxx > 512. SHAKE has a much more natural way to do the same. 
6) ilari2:  -1. I'm a bit conflicted on this. I don't like HKDF and HMAC, but HKDF is used and can do the job. I'm going for -1 instead of 0 due to efficiency of HKDF compared to SHAKE.

Best Regards,
Ruggero

-----Original Message-----
From: Cfrg [mailto:[email-masked]] On Behalf Of Alexey Melnikov
Sent: Tuesday, December 08, 2015 4:31 PM
To: [email-masked]
Subject: [Cfrg] Poll: hash functions for Ed448 (ends on December 22nd)

Choices are:

More details: 

2) "twoshakes-d",

More details: 

More details: 

6) "ilari2"

More details: 

Best Regards,
Kenny and Alexey

---

From: Mike Hamburg <[email-masked]>
Date: Tue, 22 Dec 2015 21:50:36 -0500

My vote is the same. Cheers, -- Mike

Sent from my phone.  Please excuse brevity and typos.

> On Dec 8, 2015, at 23:53, Bryan Ford <[email-masked]> wrote:
> 
> twoshakes-s: 0
> twoshakes-d: +1

---

From: Ruggero SUSELLA <[email-masked]>
Date: Wed, 23 Dec 2015 12:03:39 +0100

As correctly pointed out to me by Tony Arcieri, I have swapped the comments between 4 and 5.

Luckily I both voted them -1.

Best Regards,
Ruggero

-----Original Message-----
From: [email-masked] 
Sent: Tuesday, December 22, 2015 11:18 AM
To: [email-masked]
Subject: RE: [Cfrg] Poll: hash functions for Ed448 (ends on December 22nd)

Best Regards,
Ruggero

-----Original Message-----
From: Cfrg [mailto:[email-masked]] On Behalf Of Alexey Melnikov
Sent: Tuesday, December 08, 2015 4:31 PM
To: [email-masked]
Subject: [Cfrg] Poll: hash functions for Ed448 (ends on December 22nd)

Choices are:

More details: 

2) "twoshakes-d",

More details: 

More details: 

6) "ilari2"

More details: 

Best Regards,
Kenny and Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 28 Dec 2015 15:53:20 +0000

> 7) You can specify an alternative proposal, if you wish

After reviewing all messages received it looks like twoshakes-d is the
first choice and simon2 is a distant second.