[curves] EdDSA specification

[Brian Smith]

Trevor Perrin <trevp at trevp.net> wrote:

> The document also generalizes this signature algorithm to the 448
> curve, and extends it to include VRF functionality, which Signal might
> use in the future.  These extensions are somewhat new, and should
> probably get more public review before people rush to implement.
>

In the motivation for the randomized scheme, the document says "However, if
the same message is signed repeatedly, a glitch that affects the
calculation of h could cause this to happen (an observation due to Benedikt
Schmidt)." Could you provide a reference to a paper/message that explains
what is being referred to here, and/or add a description of the issue to
the paper?

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.

Why is Z fixed at 64 bytes? That is, why is its length not a function of
the size of the key and/or the digest function output length?

Do you have any suggestions for how one would mark a key as to whether it
is intended to be used for X25519 and/or EdDSA and/or XEdDSA and/or VXEdDSA?

The security considerations say that the caller "must pass in a new secret
and random 64 byte value each time the signing function is called." I
suggest s/64 byte value/**Z**/. Also, it would be nice to clarify the
extent of the badness if a Z value were to be reused.

Would you be open to using a different name than `q` for the order of the
base point? `q` is commonly used in code and specifications to refer to
what this paper calls `p`. Another name would be less confusing. The EdDSA
RFC uses `L`, IIRC.

Section 2.5 says "since the first |p| bits encode an integer greater than
p." I think it would be useful to add a clarification such as "(This is why
it is required 2**|p| - 1 - i > p.)" or otherwise clarify the motivation
for that precondition.

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