[tor-dev] Interest in collaborating on a standard Ed25519 key blinding scheme?

[Nick Mathewson]

On Mar 21, 2017 9:47 PM, "Tony Arcieri" <bascule at gmail.com> wrote:

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:

https://mailarchive.ietf.org/arch/msg/cfrg/lM1ix9R-0tVzhZorQhQlKvi4wpA

The post makes several mentions of Tor's work in the space in regard to the
next-generation hidden services design.

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.

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:

https://moderncrypto.org/mail-archive/curves/2017/000862.html

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.

-- 
Tony Arcieri


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?

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.

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.

George, David: any thoughts on the moderncrypto post? I think nicoo maybe
mentioned it to me a couple of weeks back?

-- 
Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20170322/c8d04bf2/attachment.html>