<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Trevor Perrin <span dir="ltr"><<a href="mailto:trevp@trevp.net" target="_blank">trevp@trevp.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The document also generalizes this signature algorithm to the 448<br>
curve, and extends it to include VRF functionality, which Signal might<br>
use in the future.  These extensions are somewhat new, and should<br>
probably get more public review before people rush to implement.<br></blockquote><div><br></div><div>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?</div><div><br></div><div>In xeddsa_sign, why set:</div><div><br></div><div>      r = hash1(a || M || Z)</div><div><br></div><div>instead of one of:</div><div>     </div><div>      r = hash1(Z || a || m)</div><div>      r = hash1(a || Z || M)?</div><div><br></div><div>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.</div><div><br></div><div>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?</div><div><br></div><div>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?</div><div><br></div><div>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.<br></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Cheers,</div><div>Brian</div></div>
</div></div>