How to Interchange Ed25519 Keys
Ed25519 isn&#x27;t quite as simple as people make it out to be, at least in the sense that it&#x27;s an answer to a problem that&#x27;s been entirely elided in these discussions, whilst the problems with older alternatives are more familiar.<p>Both RSA and NIST-defined elliptic curves support both signatures and key exchange using the same public key. Not so with Curve25519. Ed25519 is just for signatures and X25519 for key exchange, and the &quot;opaque&quot; 32-byte public keys are actually different. You can convert Ed25519 public keys to X25519 public keys, but for a reverse transformation there are two incompatible methods, and so any protocol where you would like to keep a single public key association for parties--particularly offline protocols where a sender can&#x27;t ask the recipient to generate an ephemeral key pair for confidential message reception--one is faced with a couple of choices. And the choices made by some existing protocols aren&#x27;t always obvious. Indeed, the very fact that these differences exist isn&#x27;t necessarily obvious until you&#x27;re already knee-deep in the weeds.<p>At this point the solution is more-or-less settled--just publish Ed25519 keys. But it wasn&#x27;t always that way considering that the Ed25519 signature scheme is much newer than Curve25519. And of course the legacy of this complexity will always be around to some extent.<p>Also left undiscussed is the different modes of Ed25519--regular and prehashed message digestion, a choice that is absent for older schemes. That&#x27;s a whole &#x27;nother can of worms.<p>Time and usage effect almost every new protocol and format--they don&#x27;t stay pristine forever. The sheen has already dulled on Curve25519. If you want the fewest possible interoperability headaches Curve448 is the new hotness, if only because Curve448 has been standardized more times than actually deployed. It&#x27;s also more secure--longer keys[1] and slightly better mathematical properties, AFAIU, of the type that originally made Curve25519 and DJB&#x27;s SafeCurves initiative appealing.<p>[1] Arguably useful if there&#x27;s an extended period of time between quantum computing scaling to threaten 128-bit classically equivalent but non-quantum-safe asymmetric schemes,  and scaling to threaten ~256-bit equivalent schemes. You&#x27;re probably better off with RSA in that case, though. Or just not worrying about it and sticking to Curve25519--one of the few times where &quot;but 32 is such a nice, round, convenient string length&quot; is perhaps a legitimate argument.