Re: [Cfrg] Summary of the poll: Elliptic Curves - signature scheme: friendliness to low memory implementations (ends on June 3rd)

[Björn Edström <[e-mail]>]

I like Option #3. That seems likely what people are going to do anyway
(modulo choice of hash function).

As a working software engineer in the industry a potential break of
the hash function in this case would be the least of my concern.

- Björn

On Fri, Jun 19, 2015 at 8:27 AM, D. J. Bernstein <[e-mail]> wrote:
> I'm still unable to figure out what the chairs are saying the rough
> consensus is. I'll keep using Ed25519 and SHA-3-512 to illustrate the
> options available:
>
>    Option #1: Specify Ed25519(SHA-3-512(m)) with an IUF API.
>    Option #2: Specify higher-security Ed25519(m).
>    Option #3: Specify Ed25519(m) as the higher-security default and
>               Ed25519(SHA-3-512(m)) for applications that need IUF.
>
> I understand that the chairs are saying that the following position has
> rough consensus: the demand for deploying IUF APIs in some applications
> outweighs the security concerns regarding those APIs; consequently, CFRG
> needs to specify an IUF signature scheme, such as Ed25519(SHA-3-512(m)).
>
> This is, however, compatible with _also_ specifying the more fundamental
> Ed25519(m) layer as the default higher-security signature scheme. My
> reading of the discussions so far is that it would be easy to justify
> doing this: specifying Ed25519(m) as the higher-security default and
> Ed25519(SHA-3-512(m)) for applications that need IUF. Both Ed25519(m)
> and Ed25519(SHA-3-512(m)) have clearly attracted significant interest.
>
> Are the chairs saying that the rough consensus is to do this? Or that
> the rough consensus is to _not_ do this? Or still unsettled?
>
> I would expect the first answer, but what I've seen is a completely
> unclear mix of the second answer and the third answer. See quotes below.
> Obviously clarification is required.
>
> Alexey Melnikov writes:
>> In your example, this means that "Ed25519(SHA-3-512(m)), with an IUF
>> API" satisfies the requirement and CFRG poll result doesn't say
>> anything about (doesn't recommend and doesn't prohibit) "Ed25519(m) as
>> the higher-security default".
>
> Okay. This seems to be a clear statement that the rough consensus is
> against option #2---the choice between option #1 and option #3 hasn't
> been resolved yet. "Doesn't recommend" allows option #1, and "doesn't
> prohibit" allows option #3.
>
> In other words, you're saying that the rough consensus is that CFRG
> needs to provide Ed25519(SHA-3-512(m)) or something else with an IUF
> API, and that it isn't settled yet whether CFRG will also provide
> something like Ed25519(m).
>
>> There was rough consensus for the option #1.
>
> This contradicts the "doesn't prohibit" statement. Option #1 would mean
> specifying _only_ Ed25519(SHA-3-512(m)), and _not_ specifying Ed25519(m)
> as the higher-security default.
>
> ---Dan
>
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> http://www.irtf.org/mailman/listinfo/cfrg