[curves] XEdDSA specification

[Brian Smith]

On Thu, Oct 27, 2016 at 8:40 PM, Brian Smith <brian at briansmith.org> wrote:

> On Thu, Oct 27, 2016 at 7:44 AM, Trevor Perrin <trevp at trevp.net> wrote:
>
>> On Thu, Oct 27, 2016 at 2:08 AM, Brian Smith <brian at briansmith.org>
>> wrote:
>>
> > In xeddsa_sign, why set:
>> >
>> >       r = hash1(a || M || Z)
>> >
>> > instead of one of:
>> >
>> >       r = hash1(Z || a || m)
>> >       r = hash1(a || Z || M)?
>> >
>> > It seems like it would be better to incorporate the randomness into the
>> > state of the hash function as early as possible to reduce risk of some
>> > (non-timing) differential side-channel attacks on the hashing step.
>>
>> I don't think it matters much.
>>
>> But if an attacker could choose M to cause a collision between M1 and
>> M2 or biased output, even with unknown/randomized prefix, then hashing
>> Z at the end might be better [1].
>
>
>
> That's an unlikely scenario.  But hashing Z at the end also makes the
>> design look like EdDSA a little more, as the first two inputs are
>> secret key, then message, same as EdDSA.
>>
>
> Consider this "best of both worlds" scheme:
>
>      r = hash1(a || [first half of Z] || M || [second half of Z])
>
> I believe this has the benefit of being like EdDSA but also protects
> against two different kinds of attacks.
>

Sorry, I meant to share a link that gives some motivation for choosing a
different construction by describing the other kind of attack, and
specifically criticizes the EdDSA construction:

https://dl.acm.org/purchase.cfm?id=2858932&CFID=686720127&CFTOKEN=45906669

Note that the alternative constructions I suggested above had approximately
zero thought put into them. They're more intended to illustrate that it
isn't obvious that the construct in the paper is the best one, and maybe it
is worth considering different constructions with a clear justification for
the construction finally chosen.

Cheers,
Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/curves/attachments/20161027/12213195/attachment.html>