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