<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-">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-">> hash_0(x) is reserved for other specifications. But, if hash_0(x) is never<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-"> > used, then it is clear that Curve25519 and Curve448 are fully domain<br> > separated, right?<br> <br> </span>I was thinking about domain separation with respect to the same key.<br> <br> With respect to separating hash functions for different types of keys,<br> I'm not sure that's important, but it's worth mulling over a bit more.<br></blockquote><div><br></div><div>I don't think it matters, because for different values of b, signatures will be different sizes, and for the same value of b, such domain separation doesn't work. So, forget this idea of mine.</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"><span class="gmail-">> In this paper, should we also consider the EdDSA public key to be a secret<br> > worth protecting?<br> <br> </span>Where does that make a difference? You could do const-time<br> verification, I suppose?<br></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-"><br> > In VXEdDSA, will the call to hash_to_point change from hash_to_point(A || M)<br> > to something similar to the proposed change for the first hashing in XEdDSA?<br> > (I guess this may depend on whether the EdDSA public key is supposed to be<br> > secret.)<br> <br> </span>This can't be randomized, it needs to be deterministic.<br> <br> There's not a very strong argument for padding, either, since we're<br> not trying to make this a PRF based on A (hashing A just prevents the<br> possibility of different keys that are equivalent in their VRF<br> outputs, which isn't technically a VRF attack, but seems confusing<br> enough that it's worth preventing).<br></blockquote><div><br></div><div><div>I understand it can't be randomized. My question was this: If A is secret then when we call hash_to_point(A || M), should we do anything to prevent any kind of (side channel) attacks on A where the attacker controls M, like we reordered the inputs to hash_1(...) for.</div></div><div> <br></div><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-">> In VXEdDSA, every use of a hash function is a hash_i(x). But, in XEdDSA, the<br> > first use of the hash function is hash_1(x) but the second use of the hash<br> > function is just hash(x). Why isn't it hash_2(x) instead for the second<br> > hashing?<br> <br> </span>Compatibility with EdDSA.<br></blockquote><div><br></div><div>It seems worth expanding on what exactly compatibility and incompatibility is intended. It's unclear to me.</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"><span class="gmail-">> In XEdDSA and EdDSA, near the end we calculate:<br> ><br> > h = hash(R || A || M).<br> ><br> > But in VXEdDSA we calculate:<br> ><br> > h = hash_4(A || V || R || Rv || M).<br> ><br> > Why doesn't VXEdDSA use this instead?:<br> ><br> > h = hash_4(V || Rv || R || A || M)<br> ><br> > Note that that is equivalent to:<br> ><br> > h = hash(P || R || A || M) where P = 2**b - 1 - i || V || Rv<br> <br> </span>The order doesn't matter. I see your point about aligning with EdDSA,<br> but the current order somewhat matches the "order of appearance" of<br> the variables. Since this is arbitrary, I'm inclined to leave it<br> as-is.</blockquote><div><br></div><div>See below where I try to demonstrate how code that implements both XEd25519 and Ed25519 would be factored. I would like to do similar for VXEdDSA, which is why I think consistency is useful. Also, I think that maximizing similarity is probably better for maximizing reuse of analysis of EdDSA and XEdDSA for VXEdDSA. This is also the motivation for my suggestions to use naming consistent with the EdDSA specification. Note that I'm not suggesting that you rewrite the paper in this form.</div><div><br></div><div>Note in particular how it is more convenient in this factoring to replace the the hash_i(x) hash family with a prefix_i construct, where prefix_i = 2**b - 1 - i.</div><div><br></div><div><br></div><div># Uses naming from the XEdDSA specification.<br></div></div><div><div>xed25519_sign(k, M, Z):</div><div> pad = ""</div><div> A, a = calculate_key_pair(k)</div><div> prefix = prefix(1) || a || 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, seed, M):</div><div> a, prefix = hash(seed).split_at(32)</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>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>