-
Notifications
You must be signed in to change notification settings - Fork 150
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
Invalid length of EC key attributes #1595
Comments
@smansoft please make sure this gets propagated upstream to the auth-server as well in Janssen. |
I've checked key generation, using ECDSA (using Elliptic Curves over the Prime Finite Field), Follow steps have been provided:
Results of this execution (6 launches of the KeyGenerator) uploaded (attached files):
As conclusion - KeyGenerator(s) and the SmEcc tool generate same Keys. This conclusion is same as for oxAuth as for jans-auth-server. jwks.1.txt |
About different length of x and y coordinates of Public Key. Private Key(s), generated by It could be reproduced as, using KeyGenerators as in oxAuth as in jans-auth-server. It's necessary (at the first step) to get some info about Elliptic Curves, about secp256r1 Common form of Elliptic Curve on the Prime Field p is follow: where: Common view of Elliptic Curve - attached image EC.png. Also important parameters: Standard defines I.e. 1-st Conclusion: x (Private Key) can have various length (excluding lead padding zeros). Standard defines (for secp256r1) So, 1 byte <= length(x) <= 32 bytes. Obtained Point U(ux,uy) (Public Key) shouldn't me more then p (defines finite prime field (Galois field), I.e. 2-st Conclusion: U (Public Key) has two values (ux,uy), each shouldn't me more p and U Standard defines (for secp256r1) length == 256 bits, i.e. 32 bytes. So, 1 byte <= length(ux) <= 32 bytes and 1 byte <= length(uy) <= 32 bytes. 3-d conclusion: x (Private Key) is a random number, |
Analyzing length of keys, generated by KeyGenerator, you can find, that some keys (secp256r1) have length, that equals 33 bytes. But we found (before), that length (secp256r1) of a Private Key x and Public Key U.ux, U.uy The root of this issue can be found, analyzing how java type java.math.BigInteger saves Attached file contains some examples: Conclusion, that follow from analyzing examples from file: big_integer_positive_negative.txt This conclusion explains, why: x.length = 32 and y.length = 33 00 added, as 0xae contains oldest 1. So. This is not a problem for Java and BigInteger, if some byte[] contains lead padding zeros byte, All BigInteger have correct values (during calculations), after import these arrays: as |
Also, some additional investige has bee provided - is it possible remove lead padding zeros byte Project SmEcc (attached file SmEcc.zip) contains function SmEcc.checkTruncPorcessing(). This function privides follow activity: checkTruncPorcessing(new BigInteger("ffffffff00000001000000000000000000000000ffffffffffffffffffffffff", 16)); // length 33 bytes (zero lead padding) Results of execution - attached file big_integer_positive_negative.txt. Conclusion, that follow from examples from the file: big_integer_positive_negative.txt This call value(16) = 00000000000000000000000000000000ffffffff00000001000000000000000000000000ffffffffffffffffffffffff |
@smansoft @yuriyz there's report that even when
I'm not sure if this is related to this issue or not. |
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, I think, it's possible - remove lead padding zeros byte before export, and then in Java code, it can be restored (lead padding zeros byte). If it's important, it could be implemented.
|
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) are same. |
During testing on multiple generation Keys for Elliptic Curve secp256r1 I got periodically keys with length like that: s.length = 32 s.length = 32 I.e. x.length != y.length. These keys are ok, as SmEcc Tool (SmEcc.zip) generates same Public Keys (Points) with these Private Keys: --- BigInteger -------- --- BigInteger -------- Lead padding zeros byte haven't been removed in this output. I.e. Parts of Public Keys can be different. But they shouldn't have length bigger then 32 byte (for secp256r1). |
There is some important detail about ES512 (secp521r1). As defined by standard and taking into account p and n values, length of Private Key https://www.secg.org/sec2-v2.pdf I.e. max length of arrays - 66 bytes (for saving 521 bits). Examples (4 Key Pairs, Curve secp521r1): s.length = 66 s.length = 65 s.length = 65 s.length = 66 |
fixing the problem: invalid length of ec key attributes (length > 32): issue oxauth.#1595;
Describe the issue
The JWKS generated by oxauth-client-with-dependencies.jar for EC keys sometime has different length for
x
andy
attributes.Example:
Steps To Reproduce
Steps to reproduce the behavior:
java -jar oxauth-client-with-dependencies.jar -sig_keys ES256 ES384 ES512 -dnname CN=testing -expiration_hours 2 -keystore testing.jks -keypasswd secret
x
andy
attribute for each keyset.Expected behavior
The
x
andy
attributes has same length.Actual behavior
Sometime the
x
andy
attributes has different length.Desktop (please complete the following information):
Additional context
Support ticket: 10125
The text was updated successfully, but these errors were encountered: