3 ms·

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 ov

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.

tptacek 8y ago
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.
- arghwhat 8y ago
  > 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.

tptacek 8y ago

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.

arghwhat 8y ago
> 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.