<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"><span class="gmail-">On Wed, Nov 2, 2016 at 3:00 PM, Brian Smith <<a href="mailto:brian@briansmith.org">brian@briansmith.org</a>> wrote:</span></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">> It seems worth expanding on what exactly compatibility and incompatibility<br></span></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">
> is intended. It's unclear to me.<br>
<br>
</span>XEd25519 signatures are intended to be equivalent to Ed25519<br>
signatures, just with the public keys converted.  So we need to<br>
calculate "h" the exact same way, i.e. h = HASH(R || A || M).<br>
<br>
Agreed this should be explained, somewhere.<br>
<br>
(XEd448 may not be identical to the CFRG's version of Ed448, because<br>
they're not using the equivalent curve to X448, but that's a separate<br>
issue).<br></blockquote><div><br></div><div>Yes, I found (and find) it confusing that XEd448 is different than Ed448 in obvious ways, but yet a of XEdDSA is to be co,[compatible with EdDSA in some way. More on the equivalence of Ed25519 and XEd25119 below.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Nice - That works well, another reason for moving Z earlier.<br>
<br>
So you're thinking of similarly factoring out h and s computation into<br>
a helper function, with V and Rv moved to a prefix?<br></blockquote><div><br></div><div>Yes. Basically, I'm simply trying to understand make make plain the differences between these three functions. Also, I'm suspicious of trivial but unnecessary differences between the functions in general.</div><div><br></div><div>Assuming I didn't make a huge mistake, here's another factoring of the logic that shows that XEd22519 signing can be used with either XEd25519 keys or Ed25519 keys. In particular, the randomization of the nonce and the derivation of an Ed25519 key from an X25519 key are orthogonal and XEd25519 signing is equivalent to Ed25519 signing with a nonce that has a fixed || random || fixed prefix.</div><div><br></div><div><div>xed25519_precompute(k):<br></div><div>    A, a = calculate_key_pair(k)</div><div>    prefix = domain_separator(1) || a</div><div>    return (A, a, prefix)</div><div><br></div><div>ed25519_precompute(k):</div><div>    A, seed = k.split_at(32)</div><div>    a', prefix = hash(seed).split_at(32)</div><div>    a = a' & 248 & 63 | 64</div><div>    return (A, a, prefix)</div><div><br></div><div>xed25519_sign((A, a, prefix), M, Z):</div><div>    pad = ""</div><div>    randomized_prefix = prefix || Z || pad</div><div>    return ed25519_sign((A, a, prefix), M)</div><div><br></div><div># Uses naming from draft-irtf-cfrg-eddsa-05</div><div>ed25519_sign((A, a, prefix), M):</div><div>    r = hash(prefix || M) (mod L)</div><div>    R = rB</div><div>    k = hash(R || A || M) (mod L)</div><div>    S = r + k * a (mod L)</div><div>    return R || S</div></div><div><br></div></div>I've not bothered to do VXEd25519 yet.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Cheers,</div><div class="gmail_extra">Brian<br>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><a href="https://briansmith.org/" target="_blank">https://briansmith.org/</a></div><div><br></div></div></div></div></div></div></div>
</div></div>