Skip to content
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

[Bug]: Invalid JWK thumbprint when leading zeros in JWK coordinate #21

Closed
1 task done
trew opened this issue Oct 23, 2024 · 0 comments · Fixed by #22
Closed
1 task done

[Bug]: Invalid JWK thumbprint when leading zeros in JWK coordinate #21

trew opened this issue Oct 23, 2024 · 0 comments · Fixed by #22
Assignees
Labels
bug Something isn't working

Comments

@trew
Copy link

trew commented Oct 23, 2024

Contact Details

No response

Describe the bug

Given the following JWK:

{
    "kty": "EC",
    "x":   "APgYG5BNQBWVT-w7yW51bi9M5hVluuqPOGXXl5if_NM",
    "y":   "QmnCr5fkc5hvPAHJlus28hFl9fvENm3BAHbt7YcDakQ",
    "crv": "P-256",
}

The JWK has an "x" coordinate. The byte array representation of this field is:

[0 248 24 27 144 77 64 21 149 79 236 59 201 110 117 110 47 76 230 21 101 186 234 143 56 101 215 151 152 159 252 211] 

This array is passed to a big int: (https://github.com/AxisCommunications/go-dpop/blob/a885cee9d8111680bc1aa09e95d2452eb87cc6c1/parse.go#L208)

big.NewInt(0).SetBytes(xCoordinate)

It's then converted back into a byte array in order to be encoded as base64: (https://github.com/AxisCommunications/go-dpop/blob/a885cee9d8111680bc1aa09e95d2452eb87cc6c1/parse.go#L279)

"x":   base64.RawURLEncoding.EncodeToString(key.X.Bytes()), 

The result of key.X.Bytes() is the following byte array:

[248 24 27 144 77 64 21 149 79 236 59 201 110 117 110 47 76 230 21 101 186 234 143 56 101 215 151 152 159 252 211] 

The leading zero is missing, meaning the resulting base64 becomes j7evyaXiB7W7Xcw1VcDrAbuLbU4OttJphHacZBuAzMo instead of the expected blYhrm9qF1QjcvW-PCH4EI6gqOq6p1fcH8eCuxaT0WU.

It can be solved by using key.X.FillBytes(...) instead of Bytes() in order to ensure that the byte array is of the correct size. The expected size varies based on the curve:

P-256: 32 bytes
P-384: 48 bytes
P-521: 66 bytes

I have only checked elliptic curve JWKs. The same error might apply to RSA JWKs as well.

Steps to reproduce the behavior

Create a thumbprint from the following JWK:

{
    "kty": "EC",
    "x":   "APgYG5BNQBWVT-w7yW51bi9M5hVluuqPOGXXl5if_NM",
    "y":   "QmnCr5fkc5hvPAHJlus28hFl9fvENm3BAHbt7YcDakQ",
    "crv": "P-256",
}

The thumbprint should be blYhrm9qF1QjcvW-PCH4EI6gqOq6p1fcH8eCuxaT0WU.

OS

No response

Relevant log output

No response

Additional Notes

No response

Code of Conduct

  • I agree to follow this project's Code of Conduct
@trew trew added the bug Something isn't working label Oct 23, 2024
@SalladinBalwer SalladinBalwer self-assigned this Nov 20, 2024
@SalladinBalwer SalladinBalwer linked a pull request Nov 20, 2024 that will close this issue
6 tasks
SalladinBalwer added a commit that referenced this issue Nov 21, 2024
)

When creating and using JWK representations the byte array is padded at
the start with 0x00 to ensure that all hashes of the JWK will be
correct.

When calculating the hashed token in `parse.go` and when creating proofs
in `create.go` the `FillBytes(buf []byte)` function is used on the
big.Int to get the byte array representation with added zeros at the
start.

- Fixes #21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants