SMan

@shmorri @yuriyz I've checked key generation, using ECDSA (using Elliptic Curves over the Prime Finite Field), using curve secp256r1 (P-256) and provided some investigate and as result I can assert,...

@shmorri @yuriyz About different length of x and y coordinates of Public Key. Private Key(s), generated by the KeyGenerator/Crypto Provider can have different length too. It could be reproduced as,...

@shmorri @yuriyz Analyzing length of keys, generated by KeyGenerator, you can find, that some keys (secp256r1) have length, that equals 33 bytes. for example: **jwks.2.txt** x.length = 32 y.length =...

@shmorri @yuriyz Also, some additional investige has bee provided - is it possible remove lead padding zeros byte (from byte[], that presents BigInteger) before converting (using Base64) and exporting it...

@iromli @yuriyz @shmorri EC keys are ok, just some of them presented with lead padding zeros byte, so, they length is 33 bytes. It could be a problem, if Go...

@iromli @yuriyz @shmorri I think, I can try to use second way (remove and then restore lead padding zeros byte).

@yuriyz @shmorri @iromli I.e. I think, that the problem is not that keys length are different, but that some of them have length == 33, but shouldn't be more then...

@shmorri @yuriyz @iromli One more file (it was lost) has been uploaded. This file shows, that keys (private and public), generated by the KeyGenerator and by the SmEcc tool (SmEcc.zip)...

@shmorri @yuriyz @iromli During testing on multiple generation Keys for Elliptic Curve secp256r1 I got periodically keys with length like that: s.length = 32 s (hex) = 67c1cbe41e7ee7acd350bf00893d0389192eac9e120923851cb028adf41f6aa1 keyX =...

@shmorri @yurem @iromli There is some important detail about ES512 (**secp521r1**). As defined by standard and taking into account **p** and **n** values, length of Private Key and coordinates of...