crypto/elliptic: normalize behavior of invalid curve points #50975
Labels
Milestone
Comments
FiloSottile
added
Security
NeedsFix
|
Change https://go.dev/cl/382995 mentions this issue: |
4 tasks
fritterhoff
pushed a commit
to hm-edu/pki-acme-service
that referenced
this issue
Jun 16, 2022
The next Go release call panic on elliptic.Marshal [1][2], which affect the test case fail_ec_marshal on createPublicKey. This changes fix this by initializing the P and B in test case PublicKey CurveParams to prevent panic. [1] golang/go#50975 [2] golang/go@a218b35
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
See #50974 for background. tl;dr is that
Marshal,Add,Double, andScalarMulttake a pair ofbig.Ints as inputs, which might not represent a valid point on the curve, and don't return an error value. The behavior is documented to be undefined.I am fond of the idea of returning random points, like P-224, P-384, and P-521 do in Go 1.18, but it feels like it would be a pain to debug, and doesn't feel like the right answer for
Marshal. Returning nil is definitely not the answer forMarshal, as that will get encoded as the empty string, which would be catastrophic for e.g. an ECDH shared secret, and anyway is likely to cause a panic. A panic is a DoS risk, but it would only occur where before there was a key leak risk.The @golang/security team consensus is to move to triggering an explicit panic in Go 1.19. (Hopefully, we'll soon provide a better and safer API, too.)
The text was updated successfully, but these errors were encountered: