# ECDSA, EdDSA and ed25519 relationship / compatibility

I'm trying to understand the relationship between those three signature schemes (ECDSA, EdDSA and ed25519) and mainly, to what degree are they mutually compatible in the sense of key pair derivation, signing and signature verification, but I was not able to find any conclusive information. I mean, for example, can you verify ed25519 signatures with EdDSA and/or viceversa?

The best info I found was: https://askubuntu.com/questions/363207/what-is-the-difference-between-the-rsa-dsa-and-ecdsa-keys-that-ssh-uses from which I got the suspicion that there might be some compatibility between those schemes but I could not find any source to prove or disprove it.

Could somebody shed some light on this?

Ed25519 is a specific instance of the EdDSA family of signature schemes. Ed25519 is specified in RFC 8032 and widely used. The only other instance of EdDSA that anyone cares about is Ed448, which is slower, not widely used, and also specified in RFC 8032. Keys and signatures in one instance of EdDSA are not meaningful in another instance of EdDSA: Ed25519 and Ed448 are different signature schemes.

The ECDSA family of signature schemes is not related to EdDSA, except in that the mathematics behind it also involves elliptic curves. Any particular instance of ECDSA, such as ECDSA over the curve secp256k1 with SHA-256 (as Bitcoin uses), is incompatible with any other instance of it, such as ECDSA over the curve nistp521 with SHA-512.

On a practical level, what a user might need to know is that Ed25519 keys are not compatible in any meaningful sense with keys in any instance of ECDSA. So, e.g., in the ssh protocol, an ssh-ed25519 key is not compatible with an ecdsa-sha2-nistp521 key, which is why they are marked with different types. Similarly, an ssh-ed448 key, for Ed448, is incompatible, which is why it is also marked with a different type.

On a technical level, what a protocol designer should know is that the ECDSA family of signature schemes is an archaic slow design that encourages security-destroying implementation errors, while the EdDSA family of signature schemes is a modern design that avoids those errors.

• Interesting. If ECDSA is so bad and terrible compared to EdDSA, why was it chosen for such popular and cryptographically-minded blockchain implementations such a Bitcoin and Ethereum? – David says Reinstate Monica Jul 15 '19 at 19:39
• Bitcoin predated Ed25519. – Macil Jul 22 '19 at 21:36
• @DavidsaysReinstateMonica It not only predated Ed25519, but ECDSA was made this way to work around patents. The more efficient and obvious Schnorr signatures (upon which EdDSA was based) were patented, so ECDSA had to be intentionally obtuse to avoid patent infringement. See Thomas Pornin's answer over at: crypto.stackexchange.com/a/64852/75224; because of that patent, there was no other real choice at the time. – xorhash Apr 1 at 14:07
• However, Ed25519 has its own issues regarding RFC compatibility and unforgeability as recently mentioned in ia.cr/2020/823 and ia.cr/2020/1244 – Kostas Chalkias Oct 9 at 22:45