ECC also used to have patents which restricted adoption back in the day.
There also used to be a lot of conspiracy theories that NSA backdoored nist curved ( e.g. https://m.slashdot.org/story/191445 ). Probably fud, but it slowed down adoption of eliptic curves.
Irrespective of the curve issue, ed25519/x25519 is superior and has other nice properties like not catastrophically breaking if you can't generate a unique random "k" for ECDSA as PlayStation discovered the hard way[1].
How does that work? I thought that this vulnerability was independent of the curve that is used. Ed25519 has a bunch of other nice properties related to resistance to programming errors, but I never heard of this one.
The trick is that this value in Ed25519 is a deterministic hash of the private key and the message, which means that for the same message, the same value will always be chosen, and since the private key is part of the hash, for different messages the value is basically random unless you already know the private key.
Yes, the same trick can be used with any curve, and it will avoid the vulnerability; but for Ed25519, it's always been part of the specification so everyone does it that way, while for ECDSA it's a later addition (RFC 6979) and many implementations still do it the old way.
Not FUD at all. NIST revoked their recommendation to use those curves because of it. The facts are that a "backdoor" exists whether anyone knows what it is or not, and NSA could not explain how those particular numbers were chosen so out of caution we must assume they know the backdoor and not use those curves.
The P-series curves are still a NIST recommendation and widely deployed in TLS. The B-series fell out of fashion due to practical reasons.