Closed shotexa closed 1 week ago
15 files +1 15 suites +1 2s :stopwatch: ±0s 33 tests +4 33 :white_check_mark: +4 0 :zzz: ±0 0 :x: ±0 46 runs +4 46 :white_check_mark: +4 0 :zzz: ±0 0 :x: ±0
Results for commit e2474e50. ± Comparison against base commit cb4d4792.
:recycle: This comment has been updated with latest results.
96 files ±0 96 suites ±0 22m 42s :stopwatch: -4s 826 tests ±0 818 :white_check_mark: +1 8 :zzz: ±0 0 :x: - 1 833 runs ±0 825 :white_check_mark: +1 8 :zzz: ±0 0 :x: - 1
Results for commit e2474e50. ± Comparison against base commit cb4d4792.
:recycle: This comment has been updated with latest results.
Description:
This PR fixes an issue with JWK coordinate generation for EcdsaSecp256k1Signature2019Proof.
JVM represents big integers in two's complement, which means that the leading byte is a sign (0 for pos and 1 for negative), because of this, the following line of code yields either a 32-byte array of a 33-byte array
Since
getAffineX
returnsBigInteger
, which is represented in two's complement, if the number is positive and it starts with one,toByteArray
function appends 0 at the beginning to signify that it is a positive number. Secp256k1 coordinates can't be negative anyway so seems like Apollo is expecting an unsigned integer in binary representation, and we ware generating a signed integer in two's complement representation, because of this, sometimes when X and Y are positive numbers that start with 1, we would get 33-byte arrays.Alternatives Considered (optional):
Link to existing ADR (Architecture Decision Record), if any. If relevant, describe other approaches explored and the selected approach. Documenting why the methods were not selected will create a knowledge base for future reference, helping prevent others from revisiting less optimal ideas.
Checklist: