Compact ROM with space only for EdDSA. How to fit a key exchange algorithm inside? 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?
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.