The article itself talks about X25519, which is Curve25519, not Ed25519.
Ed25519 is not in fact the de facto standard for signing on curves; that's clearly P-256 ECDSA. You're saying that Ed25519 is better, and I agree, but P-256 is much more prevalent.
Again, people don't use Ed25519 because they distrust NIST (although many people do distrust NIST). They use it because:
1. It's easier to implement in constant time.
2. It's derived (if that's the word) from a curve that was selected to avoid invalid curve attacks.
3. They want a more modern, Schnorr-based signature construction, and Ed25519 gives you that and a better curve at the same time.
For signatures, as opposed to key exchange, I think the tradeoffs are pretty much the same: by using a goofy JS library, you're giving up the implementation and side-channel advantage. You're left with the superior signing construction, but you can just use Pornin's deterministic DSA and neutralize most of that problem as well.
Seems like they made a mistake. They're referring to your private key (which is used for signing) as "X25519", but X25519 is meant for key exchanges.
Nothing but Ed25519 makes sense in this particular context, unless they've gone out of their way to do something very non-standard.
> Ed25519 is not in fact the de facto standard for signing on curves; that's clearly P-256 ECDSA.
Having never been confronted with anyone having chosen P-256 ECDSA, I question the validity of this statement.
It is important to remember that this also requires use. I have a few times stumbled upon things where only NIST curves where supported, but in those cases, RSA remained the choice of the users.
> Again, people don't use Ed25519 because they distrust NIST (although many people do distrust NIST).
None of these arguments make sense to those not implementing the cryptographic libraries on their own (which, while fun, is not recommended).
For the integrator and the user, it's simply a case of reading the docs and picking.
Ed25519 is not in fact the de facto standard for signing on curves; that's clearly P-256 ECDSA. You're saying that Ed25519 is better, and I agree, but P-256 is much more prevalent.
Again, people don't use Ed25519 because they distrust NIST (although many people do distrust NIST). They use it because:
1. It's easier to implement in constant time.
2. It's derived (if that's the word) from a curve that was selected to avoid invalid curve attacks.
3. They want a more modern, Schnorr-based signature construction, and Ed25519 gives you that and a better curve at the same time.
For signatures, as opposed to key exchange, I think the tradeoffs are pretty much the same: by using a goofy JS library, you're giving up the implementation and side-channel advantage. You're left with the superior signing construction, but you can just use Pornin's deterministic DSA and neutralize most of that problem as well.