I'm trying to understand the relationship between those three signature schemes (ECDSA, EdDSA, and ed25519) and mainly to what degree they are 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 vice versa?
I found the best info here 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.
External links referenced by this document: