New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
x/crypto/openpgp: generated then serialized Keys have incorrect bitLength #23460
Labels
Milestone
Comments
Change https://golang.org/cl/87995 mentions this issue: |
odeke-em
changed the title
Keys generated and serialized in x/crypto/openpgp have incorrect bitlength
x/crypto/openpgp: generated then serialized Keys have incorrect bitLength
Jan 17, 2018
chintanparikh
pushed a commit
to opendoor-labs/openpgp
that referenced
this issue
Dec 11, 2019
Rather than rounding the `type || X || Y` byte sequence to the next 8-bit boundary, packet.NewECDSAPublicKey() now rounds the X and Y coordinates individually, then adds the bitlength 3 of type 4 (compressed). For NIST P-256, this leads to a bit length of 515, rather than 520. GnuPG calculates 515 as well, and https://tools.ietf.org/html/rfc6637#section-6 explicitly states that "the exact size of the MPI payload is 515 bits for 'Curve P-256,'" so the new formula is consistent. Fixes golang/go#23460 Change-Id: I64b340d1c761bfd795a1a64dc2f7a831c8b2ff32 Reviewed-on: https://go-review.googlesource.com/87995 Reviewed-by: Adam Langley <agl@golang.org> Reviewed-by: Filippo Valsorda <filippo@golang.org> Run-TryBot: Adam Langley <agl@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
c-expert-zigbee
pushed a commit
to c-expert-zigbee/crypto_go
that referenced
this issue
Mar 28, 2022
Rather than rounding the `type || X || Y` byte sequence to the next 8-bit boundary, packet.NewECDSAPublicKey() now rounds the X and Y coordinates individually, then adds the bitlength 3 of type 4 (compressed). For NIST P-256, this leads to a bit length of 515, rather than 520. GnuPG calculates 515 as well, and https://tools.ietf.org/html/rfc6637#section-6 explicitly states that "the exact size of the MPI payload is 515 bits for 'Curve P-256,'" so the new formula is consistent. Fixes golang/go#23460 Change-Id: I64b340d1c761bfd795a1a64dc2f7a831c8b2ff32 Reviewed-on: https://go-review.googlesource.com/87995 Reviewed-by: Adam Langley <agl@golang.org> Reviewed-by: Filippo Valsorda <filippo@golang.org> Run-TryBot: Adam Langley <agl@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
c-expert-zigbee
pushed a commit
to c-expert-zigbee/crypto_go
that referenced
this issue
Mar 29, 2022
Rather than rounding the `type || X || Y` byte sequence to the next 8-bit boundary, packet.NewECDSAPublicKey() now rounds the X and Y coordinates individually, then adds the bitlength 3 of type 4 (compressed). For NIST P-256, this leads to a bit length of 515, rather than 520. GnuPG calculates 515 as well, and https://tools.ietf.org/html/rfc6637#section-6 explicitly states that "the exact size of the MPI payload is 515 bits for 'Curve P-256,'" so the new formula is consistent. Fixes golang/go#23460 Change-Id: I64b340d1c761bfd795a1a64dc2f7a831c8b2ff32 Reviewed-on: https://go-review.googlesource.com/87995 Reviewed-by: Adam Langley <agl@golang.org> Reviewed-by: Filippo Valsorda <filippo@golang.org> Run-TryBot: Adam Langley <agl@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
c-expert-zigbee
pushed a commit
to c-expert-zigbee/crypto_go
that referenced
this issue
Mar 29, 2022
Rather than rounding the `type || X || Y` byte sequence to the next 8-bit boundary, packet.NewECDSAPublicKey() now rounds the X and Y coordinates individually, then adds the bitlength 3 of type 4 (compressed). For NIST P-256, this leads to a bit length of 515, rather than 520. GnuPG calculates 515 as well, and https://tools.ietf.org/html/rfc6637#section-6 explicitly states that "the exact size of the MPI payload is 515 bits for 'Curve P-256,'" so the new formula is consistent. Fixes golang/go#23460 Change-Id: I64b340d1c761bfd795a1a64dc2f7a831c8b2ff32 Reviewed-on: https://go-review.googlesource.com/87995 Reviewed-by: Adam Langley <agl@golang.org> Reviewed-by: Filippo Valsorda <filippo@golang.org> Run-TryBot: Adam Langley <agl@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
LewiGoddard
pushed a commit
to LewiGoddard/crypto
that referenced
this issue
Feb 16, 2023
Rather than rounding the `type || X || Y` byte sequence to the next 8-bit boundary, packet.NewECDSAPublicKey() now rounds the X and Y coordinates individually, then adds the bitlength 3 of type 4 (compressed). For NIST P-256, this leads to a bit length of 515, rather than 520. GnuPG calculates 515 as well, and https://tools.ietf.org/html/rfc6637#section-6 explicitly states that "the exact size of the MPI payload is 515 bits for 'Curve P-256,'" so the new formula is consistent. Fixes golang/go#23460 Change-Id: I64b340d1c761bfd795a1a64dc2f7a831c8b2ff32 Reviewed-on: https://go-review.googlesource.com/87995 Reviewed-by: Adam Langley <agl@golang.org> Reviewed-by: Filippo Valsorda <filippo@golang.org> Run-TryBot: Adam Langley <agl@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
BiiChris
pushed a commit
to BiiChris/crypto
that referenced
this issue
Sep 15, 2023
Rather than rounding the `type || X || Y` byte sequence to the next 8-bit boundary, packet.NewECDSAPublicKey() now rounds the X and Y coordinates individually, then adds the bitlength 3 of type 4 (compressed). For NIST P-256, this leads to a bit length of 515, rather than 520. GnuPG calculates 515 as well, and https://tools.ietf.org/html/rfc6637#section-6 explicitly states that "the exact size of the MPI payload is 515 bits for 'Curve P-256,'" so the new formula is consistent. Fixes golang/go#23460 Change-Id: I64b340d1c761bfd795a1a64dc2f7a831c8b2ff32 Reviewed-on: https://go-review.googlesource.com/87995 Reviewed-by: Adam Langley <agl@golang.org> Reviewed-by: Filippo Valsorda <filippo@golang.org> Run-TryBot: Adam Langley <agl@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
What version of Go are you using (
go version
)?go version go1.6.2 linux/amd64
Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env
)?GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/miket/go"
GORACE=""
GOROOT="/usr/lib/go-1.6"
GOTOOLDIR="/usr/lib/go-1.6/pkg/tool/linux_amd64"
GO15VENDOREXPERIMENT="1"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0"
CXX="g++"
CGO_ENABLED="1"
What did you do?
Create GnuPG ECDSA key using ecdsa.GenerateKey(). Wrap it in an Entity, add a subkey, self-sign everything with the PrimaryKey, then entity.Serialize(). Pipe the output into
gpg -v
and note that the signatures reference a key ID that doesn't match the primary key's key ID:Pipe the same output into
gpg --list-packets --verbose
and confirm that yes, something's not right:This is a code snippet that produces the error: https://gist.github.com/sowbug/5c1a950ea21b169975375d470b52fbfb
What did you expect to see?
I eventually figured out that the bitlength of the public key for a P256 key should be declared as 515 bits (see RFC 6637 -- 256 + 256 + 3 = 515), but https://github.com/golang/crypto/blob/master/openpgp/packet/public_key.go#L247 calculates it as round8(256 + 256 + 3) = 520. Since the stated bitlength is part of the OpenPGP fingerprint calculation, this throws off the key ID.
What did you see instead?
bit length should have been 515, but it was 520.
The text was updated successfully, but these errors were encountered: