<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Mar 22, 2017 at 6:15 AM, Nick Mathewson <span dir="ltr"><<a href="mailto:nickm@torproject.org" target="_blank">nickm@torproject.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div><div class="h5"><div><span style="font-family:sans-serif;font-size:13.696px;color:rgb(34,34,34)">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?</span></div></div></div></div></blockquote><div><br></div><div>The main notable points of discussion so far have all been around preserving Ed25519's original "clamping" invariants. I didn't see any discussion of this in the current Tor spec.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div><div class="h5"><div><span style="font-family:sans-serif;font-size:13.696px;color:rgb(34,34,34)">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. </span></div></div></div></div></blockquote></div><br>Yeah, that's a blink of an eye in the IETF timescale. However, I think if you incorporate some feedback into your current design and do end up shipping it before a draft standard undergoes the requisite bikeshedding, the "running code" aspect of Tor using it in the wild will probably help the standard converge around whatever you ship. Worked out for Ed25519 itself, anyway.<br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Tony Arcieri<br></div>
</div></div>