Incompatibility (point encoding)

[trancee]

I am trying to do message signature authentication over different systems, e.g. JavaScript (http://kjur.github.io/jsrsasign/sample-ecdsa.html) with python-ecdsa. OpenSSL is the baseline for the tests and the JavaScript library is very close to produce the same results. I was expecting the same from python-ecdsa. Unless I am doing something wrong, the public key is always different in size and thus the signature validation fails.

Those are the steps I am doing:
1.) First I am deciding which curve to use, in this case it is prime256v1.
2.) Then I generate the private and public keys in Python by doing this:

privateKey = SigningKey.generate(curve=NIST256p)
publicKey = privateKey.get_verifying_key()

3.) That results in a key pair which the hex representation looks like this:

privateKey = d1d801d3166dc5b7acc2651fc1b901a6f5fc8542851a505e7b76af4c4302a85a
publicKey = 88d1b89b5e1f1a7eeb2007c31416ce743b4e3c23e261ca8b325e746938b218baec1c9d6120ffe91fe8a93d81cc55aa1cb4c995886dba91efd82ac4497cd9abf9

4.) Applying the key pair to the JavaScript testing environment, I can sign the message, but when verifying it, it says the signature is invalid.

When I generate the keys using the JavaScript implementation, I get the following as an example:

privateKey = 7e4cc8d77d6109ac01f47d530945d828673e0809ba3953b14f6fc7558ab6f670
publicKey = 0499dc501f2fe17cc8512a689498d7e1dd4c717d78db8d6a8b40c4bfeed50c01f6120ab2d09eccf741baf04f8f1451bcc99be8d48d0769837d18be934471dc1a1e

As you can see, the privateKey's are both of same size, but the publicKey's are different in size.

To determine if the problem is the JavaScript implementation, I followed the same steps using OpenSSL:

openssl ecparam -genkey -name prime256v1 -out k.pem
openssl ec -in k.pem -noout -text

Private-Key: (256 bit)
priv:
60:54:0c:84:8e:ec:de:b0:df:e6:2e:02:96:f3:d3:
3b:40:e3:fe:14:e8:f8:88:97:5c:bd:a3:2c:3e:5a:
cb:57
pub:
04:c4:9a:71:9d:93:fe:7a:24:c1:fd:ce:c2:28:6a:
a0:4d:2f:83:c1:3b:dd:9c:ab:5d:a6:56:b7:2e:ee:
c3:6b:a2:36:3d:51:2c:66:c3:34:6d:f8:4e:02:94:
8f:59:52:7b:64:30:fb:b8:be:f6:71:45:44:61:31:
32:19:81:93:d6

Once again, the publicKey is different in size from the one from python-ecdsa, but it is the same size as the JavaScript implementation. This leads me to believe that either I am doing something wrong, or there is a problem within the python-ecdsa implementation.

For compatibility and interoperability, it is required that all systems produce valid key pairs which are exchangeable.

Maybe someone can shed some light on this issue?

[tomato42]

you need to zero-left-pad the key yourself, some libraries (incorrectly) assume that all inputs are two-complement while in reality some are unsigned integers

[trancee]

@tomato42 Thanks for your hint. Could you give a practical example? And would it be better to add this directly into this library, or would that be too much to ask for?

[tomato42]

it's in the lib as number_to_string: https://github.com/warner/python-ecdsa/blob/master/ecdsa/util.py#L169

[trancee]

I don't quite get what to do with this information. when, where and how should I be using this number_to_string function?

[tomato42]

sorry, it's not a two-complement problem

it looks like the default output from the JavaScript library as well as the PEM format uses the uncompressed X9.62 encoding for point coordinates. That's where the 04 comes from. Python ecdsa uses raw uncompressed encoding for point coordinates.

The only difference between the two is the 04 starting byte.

[trancee]

I can confirm that this is in fact the issue. When adding the 04 starting byte, it works with the other implementations. Would it make sense to have python-ecdsa also support the X9.62 encoding, or at least give an option to have that use as a default?

[tomato42]

it's used in most places, so yes, native support for X9.62 encodings would be useful

changing the string output to X9.62 would change the API so I don't know if @warner would be ok with that

maybe an extra option that defaults to "raw uncompressed" but can be set to "x962 compressed", "x962 uncompressed", etc.

[mdxs]

I'm not sure, but isn't #34 implementing something like this already? I notice in the to_sec() function the adding of different prefix bytes depending on compressed/uncompressed...

And if so, does #34 also address #1 perhaps?

[tomato42]

on first look, yes, it does

[trancee]

When will that implementation be officially merged into the codebase?

[mdxs]

@trancee did you check/confirm that it works for your needs?

[trancee]

I am currently manually prepending the 04 starting byte but actually waiting for the official support in this library so I can remove my workaround. When will this be done?

[mg6maciej]

Thanks for posting this issue. It was hard to find you just need to remove 04 when passing public key to from_string.
Changing API would be a bad thing and to_string should continue to return the same value, but from_string could additionally accept a value with 04 and just strip it.