google / google/go-attestation
EC Nist P521 key size too short?
- Dominant language
- Go
- Stars
- 444
- Forks
- 109
- PR merge metrics
- No merged PRs in 30d
Description
Hi there, I was using your go-attestation package in our project to create EC keys with the TPM. I stumbled over these lines in file [attest/wrapped_tpm20.go](https://github.com/google/go-attestation/blob/5238453493/attest/wrapped_tpm20.go#L280) :
```go
[...]
tmpl.ECCParameters.Point = tpm2.ECPoint{
XRaw: make([]byte, 65),
YRaw: make([]byte, 65),
}
[...]
```
From my understanding, a key on the Nist P521 elliptic curve has - as the name suggests - 521 bits (see [here](https://cs.opensource.google/go/go/+/master:src/crypto/elliptic/nistec.go;l=80)), which translates to 65 bytes and one bit. I've heard of implementations omitting the 66th byte (which contains the remaining bit and 7 bits of padding) in case this bit turns out to be `0`, however, this is not the case in roughly 50% of the time. So I was wondering how this code is creating these keys, exactly, and how it works if the 521st bit is `1`? Is it simply omitted in all cases? Does the command even go through? I am unable to test it myself right now, unfortunately.
Contributor guide
Research direction
Start in attest/wrapped_tpm20.go around line 280 and trace how the P-521 ECC template is passed to the TPM. Check the expected byte representation for the XRaw and YRaw values and whether the command succeeds when the 521st bit is set. Done means resolving whether the template is correct and documenting or fixing the behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- cryptography, security
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 28/100