<div dir="auto"><div><br><div class="gmail_extra"><br><div class="gmail_quote">On Mar 21, 2017 9:47 PM, "Tony Arcieri" <<a href="mailto:bascule@gmail.com">bascule@gmail.com</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I'm trying to gauge interest on the IRTF's CFRG mailing list regarding collaborating on a draft for a standard Ed25519 hierarchical derivation / key blinding scheme:<div><br></div><div><a href="https://mailarchive.ietf.org/arch/msg/cfrg/lM1ix9R-0tVzhZorQhQlKvi4wpA" target="_blank">https://mailarchive.ietf.org/<wbr>arch/msg/cfrg/lM1ix9R-<wbr>0tVzhZorQhQlKvi4wpA</a></div><div><br></div><div>The post makes several mentions of Tor's work in the space in regard to the next-generation hidden services design.</div><div><br></div><div>I think it'd be great if Tor were to collaborate on the design of such a scheme and adopt it for the new hidden services design. I see a lot of convergent evolution in this space and think it would be great if there were a single standard everyone could implement.</div><div><br></div><div>Even if you don't, I think there are some ideas from similar schemes Tor should fold back into its own design, particularly in regard to how certain bits of the private scalar are "clamped". Some discussion of that here:</div><div><br></div><div><a href="https://moderncrypto.org/mail-archive/curves/2017/000862.html" target="_blank">https://moderncrypto.org/mail-<wbr>archive/curves/2017/000862.<wbr>html</a><br clear="all"><div><br></div><div>tl;dr: clamp the third highest bit of the root scalar to zero (in addition to the bits normally clamped in the non-canonical Ed25519 private scalar), and use 224-bit child scalars.</div><font color="#888888"><div><br></div>-- <br><div class="m_-5700888755083114303gmail_signature">Tony Arcieri</div></font></div></div></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto"><div style="font-family:sans-serif;font-size:13.696px" dir="auto"><div style="margin:16px 0px"><div><div dir="auto"><div dir="auto">Hi! I guess we could keep an eye on the process, though I don't know that I'd have much to contribute myself: I'm more of a crypto consumer than a crypto generator.  Maybe one of the developers who knows crypto better can join in here?</div><div dir="auto"><br></div><div dir="auto">As for adoption: we're on track to deploy next generation hidden services some time this year, ideally in the next 4 or 5 months, so the window to converge on a common system is small by standards-body standards. </div><div dir="auto"><br></div><div dir="auto">Of course, I'd rather we adopt a standard scheme than not, but I think we are instead likeliest to adopt whatever scheme we have available to us on our timescale.</div><div dir="auto"><br></div><div dir="auto">George, David: any thoughts on the moderncrypto post? I think nicoo maybe mentioned it to me a couple of weeks back?</div><div dir="auto"><br></div><div dir="auto">-- </div><div dir="auto">Nick</div></div></div></div></div></div></div>