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

[Ian Goldberg]

On Wed, Apr 12, 2017 at 05:57:00PM +0300, George Kadianakis wrote:
> 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!

You're correct that you don't need to do anything special for
signatures, since you created the key yourself.

For DH, the torsion-safe representative method was meant to be a
replacement for the "special DH function" you point to at the end of
your message.  The win of TSR is that, if no one's doing anything
dastardly, you get the *same answer* as a regular unmodified DH, but any
attempt at a malicious component to a received DH value is silently
zeroed out, at basically no extra cost.  The method you cite above also
has basically no extra cost, but produces a *different* answer, so
everyone has to upgrade at once if you've got an already-deployed
system.  (Which we don't, to be sure.)  The method of "explicitly check
for a torsion component and fail if there is one" does produce the same
answer as plain DH, but has about double the cost of plain DH (though
there are some tricks to cut that down a bit).

   - Ian