Closed kntajus closed 4 months ago
Hi @kntajus , thank you for reporting this issue and thank you for using Lowkey Vault! I will look into it and fix it.
Hi @kntajus , I think your investigation was spot on!
When I serialized the X and Y values, the BigInteger was returning an additional zero at the beginning of the byte array. As far as I understood, this was the case because the integer was supposed to be unsigned and the first real byte happened to be a "negative" value in the array. This would have made the whole integer negative when deserialized by Java. Of course in this use-case we are importing it as a positive number anyway, so it made no difference as long as one have read back the value from the same app, but it was nonetheless broken for all other clients.
I have made a change to cut off the additional zero byte from the beginning if the byte array is longer than expected. Please feel free to try v2.4.42 and let me know whether it is working as expected!
Thank you in advance!
Hi @nagyesta,
Everything seems to be working fine for me now. I have client code in both C# and Golang successfully reading a JWK and using it to verify a signature 🙌
Thank you so much for such a quick turnaround on the fix, and indeed for such a useful tool in the first place!
Hi @kntajus , thank you for your feedback! I am glad the fix worked! Best of luck!
Describe the bug
When using the REST API to create an Elliptic Curve key, either the X or the Y value returned can sometimes be too long, in that the base64url-encoded value is 44 characters long (instead of 43).
To reproduce
Steps to reproduce the behavior:
x
ory
value that is 44 characters long (it shouldn't take many attempts, I can get it to happen pretty consistently).Expected behavior
The x and y values should both be 43 characters long, representing a 32 byte array when decoded.
Actual behavior
Sometimes the x or the y (or both!) values come back as 44 characters long, representing a 33 byte array, which then causes client code trying to use the key to fail.
Additional context
From my own observations, every time it comes back "too long", the value starts with a capital A. Digging a little further, if I then decode the faulty value, it looks like the 33 byte array has an extra 0-byte at the start that shouldn't be there.