NIST curves like P-256 is generally not considered trustworthy, which is why the... (2024)

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.

I'm sorry, I misworded myself:

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 p*rnin's deterministic DSA and neutralize most of that problem as well.

> The article itself talks about X25519

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.)

> 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.

I tweeted "They would have been better off with P-256, since that uses WebCrypto" after I inspected OpenPGP.js code because it's already implemented there (since it needs to support decryption from senders that use different curves) and uses WebCrypto API implementation. To me, it's a safer choice than the `elliptic` npm package that they use for X25519.

If WebCrypto supported X25519, their choice would be a no-brainer, as 25519 is a safer curve (https://safecurves.cr.yp.to/). But P-256 is definitely not considered untrustworthy — see tptacek's reply — and at least Chrome implementation (BoringSSL) is good. (Browsers use the same implementation for TLS and P-256 is the most popular curve for TLS right now. In fact, delivery of their JavaScript code to browsers already depends on P-256 due to TLS.)

Regardless of the choice, my main concern is that they advertise X25519 as timing safe, while not having a timing safe implementation. This is a red flag.

Disclaimer: I ported TweetNaCl (which uses 25519) to JavaScript. The port intends to be "algorithmically" constant-time, but doesn't guarantee real-life timing safety due to JS.

I unfortunately implemented and maintained several cryptographic algorithms (block ciphers, UMACs, key exchanges, whatnot, a bunch of it proprietary for extra awfulness) and compression algorithms in JavaScript as part of a previous job. It was awful, and I broke the JIT more times than I could count. JS is not well-suited for this.

I still find the argument to be wrong, in the sense that picking Ed25519 is an entirely correct decision to make. Picking that library is not a correct decision, and that might lead to needing a different algo (I'd argue that WebCrypto needs to pick up its pace for common algorithms, rather than picking picking up whatever dropped fruit is available).

We shouldn't slander them for Ed25519 (although you are right that such claim about timing safety is borked—maybe that got lost in marketing). We should only target the library choice.

Plus, with WASM widely available, we should be able to port a constant-time of Ed25519 with good performance without much work. WebCrypto is just a cherry on top.

I have found no evidence that the author has changed their stance on this issue. You can find other issues that have also been closed with a brief explanation.

If the author wants to show up and say otherwise, I'm happy to take correction.

But, I'd rather have a robust implementation of a speculatively less secure scheme then have the undelivered promise of a more secure scheme papering over an insecure implementation.