crypto/elliptic: automatically upgrade CurveParams for known curves and deprecate custom ones #34648
Comments
FiloSottile
added
the
NeedsFix
|
To clarify: this is just deprecating the use of The actual parameters ( |
Yeah, definitely. It's about the implementation. (Although I wish we also didn't have the big.Int fields.) |
FiloSottile
changed the title
FiloSottile
removed
the
NeedsFix
FiloSottile
added
the
Proposal-Crypto
|
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 |
|
Adding to proposal minutes, more discussion welcome. |
|
@agl added this API, we should probably ask him his thoughts before deprecating it. |
|
Ping @agl? |
|
Burn it with fire (if you wish). I.e. I agree with Filippo that it would be nice and that the decision should come down to whether we can do it within the constraints of the Go standard library. |
|
Alrighty then! Based on the discussion above, this seems like a likely accept. |
|
No change in consensus, so accepted. |
FiloSottile
changed the title
FiloSottile
added
the
NeedsFix
|
Change https://golang.org/cl/233939 mentions this issue: |
…able This change alters the CurveParam methods to upgrade from the generic curve implementation to the specific P224 or P256 implementations when called on the embedded CurveParams. This removes the trap of using elliptic.P224().Params() instead of elliptic.P224(), for example, which results in using the generic implementation instead of the optimized constant time one. For P224 this is done for all of the CurveParams methods, except Params, as the optimized implementation covers all these methods. For P256 this is only done for ScalarMult and ScalarBaseMult, as despite having implementations of addition and doubling they aren't exposed and instead the generic implementation is used. For P256 an additional check that there actually is a specific implementation is added, as unlike the P224 implementation the P256 one is only available on certain platforms. This change takes the simple, fast approach to checking this, it simply compares pointers. This removes the most obvious class of mistakes people make, but still allows edge cases where the embedded CurveParams pointer has been dereferenced (as seen in the unit tests) or when someone has manually constructed their own CurveParams that matches one of the standard curves. A more complex approach could be taken to also address these cases, but it would require directly comparing all of the CurveParam fields which would, in the worst case, require comparing against two standard CurveParam sets in the ScalarMult and ScalarBaseMult paths, which are likely to be the hottest already. Updates #34648 Change-Id: I82d752f979260394632905c15ffe4f65f4ffa376 Reviewed-on: https://go-review.googlesource.com/c/go/+/233939 Trust: Roland Shoemaker <roland@golang.org> Trust: Katie Hockman <katie@golang.org> Run-TryBot: Roland Shoemaker <roland@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Filippo Valsorda <filippo@golang.org> Reviewed-by: Katie Hockman <katie@golang.org>
|
@FiloSottile Is this likely to happen for 1.18? Thanks. |
|
This does not seem to have happened for 1.18. Moving milestone to 1.19. |
|
Most of the work is done, only thing left is the deprecation. |
|
Change https://go.dev/cl/398914 mentions this issue: |
|
Change https://go.dev/cl/459977 mentions this issue: |
Per the updated go.dev/wiki/Deprecated, those APIs replaced by crypto/ecdh (added in Go 1.20) can now be marked as deprecated in Go 1.21. Updates #52221 Updates #34648 Change-Id: Id0e11d7faa3a58a1716ce1ec6e2fff97bab96259 Reviewed-on: https://go-review.googlesource.com/c/go/+/459977 Run-TryBot: Filippo Valsorda <filippo@golang.org> Auto-Submit: Filippo Valsorda <filippo@golang.org> Reviewed-by: Roland Shoemaker <roland@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
The generic implementation of
elliptic.Curveprovided byCurveParamsis slow and insecure. No one would want to use it for a standard curve for which a constant-time, optimized implementation is available, likeP256().However, it's an easy mistake to replace a
P256()value withP256().CurveParams()as they have exactly the same type. I say we just take away this footgun and redirect methods ofCurveParamsto 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.
The text was updated successfully, but these errors were encountered: