2
$\begingroup$

I have implemented Ed25519 for a constrained-memory system, and I want to provide a Shared Secret functionality. The recommended method is to use X25519 for this; but then I would have to implement point multiplication over the Montgomery curve Curve25519, which I don't really have room for.

Would there be any downside to using Ed25519 directly for this? In other words, if PrK is my private key and PuK is your public key, our shared secret is [PrK]PuK computed over the curve Ed25519, and not the curve Curve25519. Perhaps then I could hash the result, as Bernstein recommends for X25519.

I am aware of two possible issues: firstly, Curve25519 is slightly faster here; but this is not a serious problem in my application. Secondly, such a custom algorithm is not recommended by any standard; this is a more serious problem, but I can live with it. Does anybody know of any more potential problems with this approach?

Improve this question
$\endgroup$
7
  • 1
    $\begingroup$ Related Why Curve25519 for encryption but Ed25519 for signatures? $\endgroup$
    – kelalaka
    Commented Oct 9, 2020 at 22:47
  • $\begingroup$ @kelalaka: Yes, thanks. I saw this. But it doesn't say anything about whether using Ed25519 directly for Shared Secret generation might be a bad idea. $\endgroup$
    – TonyK
    Commented Oct 9, 2020 at 22:51
  • $\begingroup$ The constant time due to the Montgomery ladder? Also, did you see the Squamish comment there? $\endgroup$
    – kelalaka
    Commented Oct 9, 2020 at 22:52
  • $\begingroup$ @kelalaka: My Ed25519 implementation is also constant-time. And Squeamish Ossifrage made three comments on that page, so I'm not sure which one you mean. In any case, nobody seems to have any theoretical reasons not to use Ed25519, so I think I'll go with that. But should I hash the result? $\endgroup$
    – TonyK
    Commented Oct 9, 2020 at 23:00
  • $\begingroup$ You need to KDF the result, not just hash it. $\endgroup$
    – SAI Peregrinus
    Commented Oct 10, 2020 at 2:26

1 Answer 1

Reset to default
3
$\begingroup$

A bit of nomenclature first: “Ed25519” is defined to refer to the EdDSA signature algorithm over the edwards25519 curve. What you appear to actually mean is whether you can reuse your edwards25519 code for Elliptic Curve Diffie–Hellman (ECDH).

There is no inherent reason that you can't use edwards25519 for ECDH. We've been doing ECDH with all kinds of curves for ages already, and edwards25519 works just fine as any other. You need to take the same precautions as for X25519, too: multiply by the cofactor $h=8$ or check against a blacklist of bad points (but the encoding of those points will differ between compressed edwards25519 points as for Ed25519 and X25519).

Since you say you're looking at a constrained-memory system, it is likely that you've first built signature verification (which not require constant-time code). If you're going to reuse this code for key exchanges, make sure all curve code and field arithmetic code (except the routines only used signature verification) are made to be constant-time.

A key exchange protocol requires more than just a curve, however, so you may want to look into e. g. the Noise protocol patterns.

Improve this answer
$\endgroup$
1
  • $\begingroup$ Thanks for this. I am only looking to provide a raw Shared Secret functionality; users can implement their own key derivation algorithm on top of this. And secret keys are always a multiple of 8, so that is taken care of too. Which leaves the question: should I hash the result? I am inclined to say yes, but if anybody can convince me that there is no need, I will happily leave it out. $\endgroup$
    – TonyK
    Commented Oct 11, 2020 at 10:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.