You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is attempting to verify a (somewhat unusual, but valid) ECDSA signature. However, it appears there is some bug in the x86-64 specific P-256 code. The code tries to verify twice, once with the standard ecdsa.Verify and then with a hacked version of the same function MyVerify (in the source), which is just ecdsa.Verify with the specialized codepaths for inverse and combinedMult removed. On my machine the hacked version verifies the signature while the library version (that, for P-256 on x86-64, calls combinedMult) rejects it.
However on the playground, the signature does verify using the stock ecdsa.Verify. This suggests to me that the playground version of Go doesn't use the x86-64 codepath, and is additional validation for there being a bug somewhere. (Either the signature is valid, or it is not - and the versions of ecdsa.Verify in playground and my machine disagree on this point).
A similarly generated signature using P-384 also verified without problems, again suggesting a problem that is P-256 specific.
I have not done further investigation as to the nature of the bug. It's possible it may effect other ECC code using these optimized codepaths.
What did you expect to see?
The signature would verify with ecdsa.Verify
What did you see instead?
It does not verify, if the x86-64 P-256 code is enabled.
The text was updated successfully, but these errors were encountered:
ianlancetaylor
changed the title
Bug in x86-64 P-256 implementation
crypto/ecdsa: bug in x86-64 P-256 implementation
Aug 7, 2017
ianlancetaylor
changed the title
crypto/ecdsa: bug in x86-64 P-256 implementation
crypto/elliptic: bug in x86-64 P-256 implementation
Aug 7, 2017
Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (
go version
)?go version go1.8.3 linux/amd64
What operating system and processor architecture are you using (
go env
)?Arch Linux on x86-64
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/jack/opt/go"
GORACE=""
GOROOT="/usr/lib/go"
GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/home/jack/var/tmp/go-build612722418=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"
PKG_CONFIG="pkg-config"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
What did you do?
Run the code in https://play.golang.org/p/26l_zIOjBf
This is attempting to verify a (somewhat unusual, but valid) ECDSA signature. However, it appears there is some bug in the x86-64 specific P-256 code. The code tries to verify twice, once with the standard
ecdsa.Verify
and then with a hacked version of the same functionMyVerify
(in the source), which is justecdsa.Verify
with the specialized codepaths forinverse
andcombinedMult
removed. On my machine the hacked version verifies the signature while the library version (that, for P-256 on x86-64, callscombinedMult
) rejects it.However on the playground, the signature does verify using the stock
ecdsa.Verify
. This suggests to me that the playground version of Go doesn't use the x86-64 codepath, and is additional validation for there being a bug somewhere. (Either the signature is valid, or it is not - and the versions ofecdsa.Verify
in playground and my machine disagree on this point).A similarly generated signature using P-384 also verified without problems, again suggesting a problem that is P-256 specific.
I have not done further investigation as to the nature of the bug. It's possible it may effect other ECC code using these optimized codepaths.
What did you expect to see?
The signature would verify with
ecdsa.Verify
What did you see instead?
It does not verify, if the x86-64 P-256 code is enabled.
The text was updated successfully, but these errors were encountered: