[curves] Ed25519 "clamping" and its effect on hierarchical key derivation

Ron Garret ron at flownet.com
Wed Mar 29 12:34:06 PDT 2017

On Mar 29, 2017, at 11:49 AM, Tony Arcieri <bascule at gmail.com> wrote:

> On Tue, Mar 28, 2017 at 5:25 PM, Trevor Perrin <trevp at trevp.net> wrote:
> So maybe the question is how much you care about spending a little
> extra effort in key derivation to make the keys a little safer with
> existing DH software?  I.e., do you multiply by the scalar as part of
> derivation, or leave that for a future DH operation?
> This is what has always confused me: the clamping procedure used by Ed25519 seems "inherited" from X25519[1], ostensibly for some case where you may want to take an Ed25519 key, convert it to an X25519 key, and use it for D-H. Aside from libsodium providing an API for doing so, I haven't actually seen anyone do this.

SC4 does this.  The idea is that it can help with identity binding.  If Alice publishes a proof-of-identity signed by an Ed25519 key then Bob can send her an asynchronously encrypted message using the corresponding Curve25519 key to derive a shared secret.  (Note that SC4 was designed before X3DH was published.)

> It seems like if you want to support a scheme which works for both signatures and D-H, maybe it would be better to define the scheme in terms of Montgomery, so it can be used directly with X25519, and then use XEd25519 for signatures.

What would be the benefit?  It seems to me that it doesn’t really matter much one way or the other, but if you’re going to convert one to the other then it seems to make more sense to derive the DH key from the DSA key because going the other way you lose the sign of the Y coordinate.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/curves/attachments/20170329/4afcc57b/attachment.html>

More information about the Curves mailing list