That is not at all the case. P-256 is widely used and no cryptographer seriously believes there's anything "untrustworthy" about it. Rather, the problem with P-256 is that it's easy to misuse, like most curves. It's hard to implement in constant time and the NIST P-curves generally lend themselves to invalid curve attacks, which need to be guarded against.
Curve25519 avoids these problems. But then, if you're using a naive Javascript library, you've thrown out one of the main benefits of Curve25519 already, and are left essentially with invalid curve attacks, which are not especially hard to defend against and not always even relevant to a given protocol (who could be bothered to go look at what OpenPGP.js is doing with them, I don't know).
Ed25519 is the signing curve equivalent to Curve25519/X25519. It's what you'd use to generate and verify signature, but not what you'd use for ECDH.
There is general distrust in NIST, not any known issues with those curves. However, it is general consensus to prefer Ed25519 over NIST curves, specifically preferring it over P-256. The benefits of its implementation are a cherry on top. I have yet to see any suggestion or reason to pick P-256 when Ed25519 is available.
And yes, Ed25519 is the defacto standard. Hell, I don't even recall the last time I heard P-256 mentioned. It surprises me every time I stumble upon it. Picking anything other than Ed25519 means deviating from the norm, which would normally cause worry. Granted, P-256 is fine, but there is absolutely no argument for claiming Ed25519 was the wrong choice of algorithm.
And yes, I specifically refer to Ed25519 because it is the one relevant here. We're talking about signing, not key exchanges.
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.
Actually, Ed25519 is the Edwards curve isomorphic to Curve25519 (which IIRC is a Montgomery curve).
Edwards is faster than Montgomery for signature, but not significantly slower for key agreement.
You can use it for ECDH, and unless I've missed some non-obvious attack (which is of course, entirely possible) you probably should, since that allows you to use (mostly) the same elliptic curve math primitives for key agreement as for signature.
(That is, you should use Edwards form points as shared-secret output. It's possible to implement Curve25519 using Ed25519 internally, but probably not a good idea.)
My understanding is that Ed25519 is birational to Curve25519, not actually isomorphic, but also that the difference between the two ("almost" vs "perfectly" isomorphic) is not really all that interesting. I thought Ed25519 was better for multiple-base operations used in signing, but slower for variable-base operations in ECDH.
> that Ed25519 is birational to Curve25519, not actually isomorphic
That might be the case, I only meant isomorphic in the programming sense of f(x) = h⁻¹(g(h(x))) for relatively trivial h.
> I thought Ed25519 was [...] slower for variable-base operations in ECDH.
My understanding is that Ed25519 requires replacing several of Curve25519's field squarings with general multiplications, but isn't actually any slower if you use a general multiply for everything. I'm not sure how much optimization you can get out of squaring though, so it might be a easy 10% bonus you're passing up there.
Curve25519 avoids these problems. But then, if you're using a naive Javascript library, you've thrown out one of the main benefits of Curve25519 already, and are left essentially with invalid curve attacks, which are not especially hard to defend against and not always even relevant to a given protocol (who could be bothered to go look at what OpenPGP.js is doing with them, I don't know).
Ed25519 is the signing curve equivalent to Curve25519/X25519. It's what you'd use to generate and verify signature, but not what you'd use for ECDH.