crypto/elliptic: automatically upgrade CurveParams for known curves and deprecate custom ones

[FiloSottile]

The generic implementation of elliptic.Curve provided by CurveParams is slow and insecure. No one would want to use it for a standard curve for which a constant-time, optimized implementation is available, like P256().

However, it's an easy mistake to replace a P256() value with P256().CurveParams() as they have exactly the same type. I say we just take away this footgun and redirect methods of CurveParams to the optimized curve implementation whenever the parameters match a known curve. That won't be extremely fast, but still faster than actually using the generic implementation.

Moreover, I think CurveParams in general was a mistake, and no one should be using it for custom curves either. For example, it's not constant time, and will never be, and we are not going to spend resources making it faster. Given it should be used for neither custom nor standard curves, I say we deprecate the CurveParams methods outright.

[ericlagergren]

To clarify: this is just deprecating the use of elliptic.CurveParam's methods, right?

The actual parameters (BitSize and Name, in particular) are useful.

[FiloSottile]

To clarify: this is just deprecating the use of elliptic.CurveParam's methods, right?

The actual parameters (BitSize and Name, in particular) are useful.

Yeah, definitely. It's about the implementation. (Although I wish we also didn't have the big.Int fields.)

[FiloSottile]

Flagging as a proposal to discuss deprecating the generic, not constant time methods Add, Double, IsOnCurve, ScalarBaseMult and ScalarMult of CurveParams. Everyone should be instead using the methods on a named curve like P256().

[rsc]

Adding to proposal minutes, more discussion welcome.