# Curves intended for both signing and key agreement

I need some guidance on elliptic curves that support signing and key agreement.

I am trying to develop a protocol for sending encrypted, deniably authenticated messages. To do this I will sign the message with a 2-key ring signature using the sender's signing key and the recipient's encryption key.

Is there a sensible elliptic curve to use for this? Ideally it would meet the safe curves standards and provide the same level of security as Curve25519 (i.e. 256 bit length / 128 bit security).

Ed448-Goldilocks looks like it fits the bill as a curve intended to support both functions but is there anything more lightweight?

• What's wrong with Curve25519? – SEJPM Jan 15 '17 at 22:36
• I don't know. That's one reason I'm asking the question. I'm having a hard time tracking down any literature that gives a good account of why there are separate Bernstein curves for signing (Ed25519) and key agreement (Curve25519). – geoff_h Jan 15 '17 at 22:47
• @geoff_h Ed25519 refers to a signature system. The curve it uses to create those signatures is isomorphic to Curve25519, so they are abstractly the same curve — only the representation is different. In any case, ring signatures seem overkill for your purpose: Once you have a shared key, can't you just use public-key authenticators, as is for instance done in NaCl's crypto_box? – yyyyyyy Jan 15 '17 at 23:11
• Ok. But can you point me at a rationale for using different isomorphisms? I believe you and it's my understanding as well but I'd like to understand the split before taking that route. Thanks. – geoff_h Jan 15 '17 at 23:19
• Nitpick: the curves are birationally equivalent, not isomorphic. – CurveEnthusiast Jan 16 '17 at 8:11

Technically, any elliptic curve can support both signing and key agreement. However, Curve25519 as described in the original paper is meant for $x$-only arithmetic. This means that one never computes the $y$-coordinate. The issue is that you need the $y$-coordinate for signature verification in the standard algorithms (ECDSA, EdDSA).
Therefore, if you want to do signatures with the Curve25519 curve, you need to compute the $y$-coordinate. There are different ways to do this, one is to simply leave the curve as is (in "Montgomery form") and compute its $y$-coordinate. A different way, is to transform the curve into a new shape (the "twisted Edwards form") and do arithmetic there. This new curve is called Ed25519, and it is "(birationally) equivalent" to the old curve. There are even more flavours.
Again, the choice you make will be for efficiency and security. Not because one curve can be used for signatures while the other can't. I suppose the $y$-coordinate computation on Curve25519 is slow enough for people to prefer using Ed25519 instead.
• A minor detail: computing the $y$-cordinate on Montgomery curves costs only about 13 Multiplications. The issue is that in verification you need a full point addition which is not present in the Montgomery ladder, so you need to add code for that, and it has exceptions (when adding $P+P$, $P+\infty$, etc.). Furthermore for efficiency montgomery ladder is good for variable base but in signature you might use fixed based and in verification double base, and both favors Edwards. – Ruggero Jan 16 '17 at 10:41