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

[George Kadianakis <desnacked@xxxxxxxxxx>]

Tony Arcieri <bascule@xxxxxxxxx> writes:

> 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.
>

An update:

After lots of discussions in the Amsterdam Tor meeting, the following
approach was suggested for cleansing keys of their torsion components
that is more friendly towards hierarchical key-derivation schemes:
        https://moderncrypto.org/mail-archive/curves/2017/000866.html

However, my current intuition is to just not do this for hidden service
ed25519 blinded keys. Those keys are only used for signing descriptors
which should be safe to do, and we don't plan to use them for D-H any
time soon. If we or some crazy app EVER decides to use those ephemeral
keys for key exchange, we would need to use a special DH function that
kills the tensor component of keys before using them, as suggested by
Trevor here: https://moderncrypto.org/mail-archive/curves/2017/000874.html

Please let me know if you think this is not a good idea!
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev