2 ms·

Aren't both of those attacks all-but-negated by djb's Curve25519?

• lvh 8y ago
  Effectively, yes. Curve25519 has a few tricks that make this hard to do: it defines a curve compression format that mandates using 32-byte public keys and uses a single-coordinate ladder. It has the same property that points not on the curve are on the twist, but the twist is also secure. Curve25519's main innovation was to make the secure thing the default and the obvious thing to do: it was not the first twist-secure curve, it was not the first curve to have point compression that forces a point to be on the curve or the twist, plain old NIST P-256 had both of thsose. We also had a 1-coordinate ladder for Weierstrass prior to Curve25519, but it was far less used than effective point compression. But it is true that it is not incorrect to use P-256 without point compression which makes it easy to have these sorts of problems, and it is incorrect to do so in Curve25519, because the spec encompasses more than just the mathematical object of the curve. Curve25519 and its sister curve Ed25519 are really good at what they were designed for. Unfortunately people also use them for things that they're not good at, and then you get bugs like the Monero double spend. Montgomery curves necessarily don't have cofactor 1 -- so that's an example of a bug that could only have occurred on X25519.