<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Nov 2, 2016 at 1:53 PM, Brian Smith <span dir="ltr"><<a href="mailto:brian@briansmith.org" target="_blank">brian@briansmith.org</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">I've not bothered to do VXEd25519 yet.</blockquote></div><br>I did spend a little bit of time figuring out what a newbie would have trouble understanding about VXEd25519 in relation to XEd25519. Below I reference the XEdDSA nonce calculation in the published draft, not the proposed modified calculation, just to keep things simpler. The same applies for the new calculation.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_extra">For reference, the first part of VXEd25519 is:</div><div class="gmail_extra"><div class="gmail_extra">    A, a = calculate_key_pair(k)</div><div class="gmail_extra">    Bv = hash_to_point(A || M)</div><div class="gmail_extra">    V = aBv</div><div class="gmail_extra">    r = hash3(a || V || Z) (mod q)</div></div></div><div class="gmail_extra"><div class="gmail_extra"><br></div><div class="gmail_extra">1. Does r really *need* to be calculated differently in VXEdDSA? That is, is there a risk of a security failure or that things otherwise stop working if it were calculated the same way as XEdDSA, r = hash2(a || M || Z)?</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">2. If the answer to #1 is "no," is there any material advantage to calculating it differently?</div><div class="gmail_extra"><br></div><div class="gmail_extra">Consider the following hand-wavy (and therefore probably wrong) argument. First, note</div><div class="gmail_extra"><br></div><div class="gmail_extra">    V = aBv</div><div>    V = a * hash_to_point(A || M)</div><div>    V = a * hash_to_point(public_from_private(a) || M)</div><div><br></div><div>When we compute r = hash3(a || V || Z) (mod q), we're already hashing a, therefore also hashing any function f(a) is redundant. Similarly, hashing the output of a function f(M) can't give us a larger set than M. Therefore, computing r the same was as in XEdDSA r = hash3(a || M || Z) is sufficient and actually at least slightly more secure than calculating hash3(a || V || Z), AFAICT. The only obvious advantage to calculating hash3(a || V || Z) instead of hash3(a || M || Z) is that the length of V will generally be smaller than the length of M, so less data will be hashed.</div><div><br></div><div>Regardless, it would be useful to note the rationale for this design.</div><div><br></div><div>3. To what extent does calculating hash3(a || V || Z) reduce security compared to hash3(a || M || Z) when Z is the output of a broken PRNG? In other words, how much worse is it to hash V instead of M? Put yet another way, it would be useful to explain how lossy hash_to_point is in the Elligator 2 summary.</div><div><br></div><div>Cheers,</div><div>Brian</div>-- <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>