40
$\begingroup$

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?

Improve this question
$\endgroup$

1 Answer 1

Reset to default
45
$\begingroup$

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.

Improve this answer
$\endgroup$
4
  • 1
    $\begingroup$ 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? $\endgroup$
    – David says Reinstate Monica
    Commented Jul 15, 2019 at 19:39
  • 5
    $\begingroup$ Bitcoin predated Ed25519. $\endgroup$
    – Macil
    Commented Jul 22, 2019 at 21:36
  • 4
    $\begingroup$ @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. $\endgroup$
    – xorhash
    Commented Apr 1, 2020 at 14:07
  • 1
    $\begingroup$ However, Ed25519 has its own issues regarding RFC compatibility and unforgeability as recently mentioned in ia.cr/2020/823 and ia.cr/2020/1244 $\endgroup$
    – Kostas Kryptos
    Commented Oct 9, 2020 at 22:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.