Ed25519 ECDH

[cloudhead]

Hey there, we're using this great library to implement an authenticated handshake between nodes that run on user machines. Users are also able to sign objects with their node key and it's important to be able to authenticate user nodes with the same key as the one they sign objects with. We've identified three potential ways to make this happen:

1. Do the ECDH using ed25519 -- this would require the functionality be implemented in this library
2. Move to ristretto255, which has library support for both ECDH and signing.
3. Use an unauthenticated handshake, eg. Noise_NN with x25519, and do ed25519 authentication by sending certificates on the secure channel

The issue with (2) is that we store private keys in SSH format and make heavy use of ssh-agent, so moving to ristretto255 is not that straightforward. (3) is what we currently have, but it seems sub-optimal to have another roundtrip and protocol just for this, when DH is basically the right tool for the job.

I know it's possible to do ECDH with ed25519, just slower, and was hoping you'd consider adding support to your library, if you think it makes sense!

Cheers

[somehybrid]

I don't think ECDH would be necessary here. One, X25519 is much faster than ECDH, and secondly, it's trivial to convert an Ed25519 key to an X25519 key. For an example, see rust-crypto's way of converting between Ed25519 and Curve25519 keys, or signal's (V)XEdDSA

(plus, there might be some issues in public key exchange)

[jedisct1]

X25519 is ECDH, and is not really faster than DH over Edwards25519, especially if conversions are needed.

But if you need to convert from Ed25519 to Curve25519, that library already implements it.

[cloudhead]

It's not possible to convert an X25519 key to Ed25519 though, which is what I need to make this work. I guess there is also https://www.signal.org/docs/specifications/xeddsa/ as a solution, but haven't looked into it.