-
Notifications
You must be signed in to change notification settings - Fork 64
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
Representation of generated Public Key #8
Comments
Hi @sergio-domingues and thanks for your interest :) I am not sure I understand your question. From the comments in the top of ecdh_example.c.
The coordinates are represented as uncompressed raw points, which to my knowledge is a standard representation. Does that answer your question? |
According to the standards defined in that NIST specification, shouldn't the uncompressed format begin with 0x04? I know If it's better for my needs I can just add that initial byte, just wanted to clarify what standard is being used. Thanks again :) |
When exchanging points etc. using bit-strings, yes there is a convention to add 04 if uncompressed, 02 or 03 if compressed. From RFC 5480:
I am by no way an expert on this standard, but I interpreted that paragraph to only regard parameter exchanges in textual format (bit-string / octet string). I think I read some of the same in 2.3.3 in the SEC-document you linked to. EDIT: An aside: The reason I am not compressing the points, is that I think point-compression is still a patent-encumbered technology. |
Ok, it makes sense. Thank you for the clarification! |
I think it mostly means something if you exchange curve parameters using a standard format like X.509 or something similar (ASN.1?). I will close this issue, but feel free to continue the discussion if you have further questions or comments :) |
Hi again @kokke, I also noticed that a 3 byte (0x00) is being added after X and Y, is it supposed to work like a separator? |
Hi @sergio-domingues - I'm not sure what you are referring to, can you give me a link to some code or copy/paste the parts you are referring to ? :) |
That is just a coincidence. An artifact of how the numbers are placed in memory. For the case sect163k1, think of the key as two 163 bits numbers put next to each other (the x and y coordinate). We allocate in 8 bit chunks (8 bit pr byte), so that leaves at least 5 unused bits after the first coordinate. It is not unthinkable that there could be 20-25 clear bits between the numbers. |
Yeah I understand that the public key is represented by the concatenation of x and y. Following the logic on your reply the unused bytes will be in the 0-30 byte range (233 bits), as you can see in the image every time I generate a public key for that curve a 2 byte (0x00) is added between x and y in the [30,31] indexes, making it look like: [x-coord][0x0][0x0][y-coord] and the y-coord is missing the 2 bytes because of that spacing. Could you pelase execute the public key computation for that curve in your side in order to verify this issue? |
Hello, I'm using sect163k1 elliptic curve and in order to generate the public key I'm executing the following code:
Is the result following a standard specification (compressed / uncompressed / hybrid) format defined in SEC1v2?
Thanks in advance!
The text was updated successfully, but these errors were encountered: