search

kokke / tiny-ECDH-c

Small portable Elliptic-Curve Diffie-Hellman in C
The Unlicense
254 stars 65 forks source link

Shared secret byte size #9

Closed nguterresn closed 5 years ago

nguterresn commented 6 years ago

Hello, I'm using this library to create a shared secret using 'sect163k1' elliptic curve.

At the end of the ecdh_example.c I noticed the shared secret has ECC_PUB_KEY_SIZE byte size. Shouldn't it be ECC_PRV_KEY_SIZE? I'm not saying it's wrong, just trying to understand the code.

Thanks in advance!

kokke commented 6 years ago

Hi @nguterresn and thanks for checking out my library :)

From the top of my head:

The private key is a scalar (an integer number) whereas the public key is a point (two scalars for x- and y-coordinate).

The shared secret is a point, which is therefore the same size as the public key (twice the size of the private key).

nguterresn commented 6 years ago

By the name of the curve, I thought the number 163 was the size of the output key. What you said, makes sense, but I can't find anywhere where's justified. I'm just curious because I have seen others libraries using ECC_PRV_KEY_SIZE shared key and, at this point, I don't know which one is correct or not.

I'm really confused about this because I'm trying to establish a shared key with another device and the shared key, even tho it is the same curve, doesn't match. Plus, when I compute the public key and send it, it's not recognized as being from the same curve as the destination curve.

I hope you can help and thanks for your time. :)

kokke commented 6 years ago

163 here is the size of the Galois field used. GF(2^m) where m = 163. It is also the order of the highest-order factor in the reduction polynomial used.

There are several ways to store the keys. Using point-compression, the shared secret can be compressed to around half size, which could explain what you've seen.

If you are inter-operating with other libraries, please ensure the format of the exchanged parameters are compatible (endianness, is point-compression used etc.).

See more here: http://www.secg.org/sec2-v2.pdf

nguterresn commented 6 years ago

Thanks for the explaining, appreciate it.

The other device is returning a public key with 43 bytes, because of that 1 byte reserved for format info(In this case, 04, uncompressed). But, even if I ignore the reserved byte, the key is not valid. At the opposite side, if I send my key it is not valid because it is not from the same curve, but in the "theory" it is.

I already converted little endian to big endian public key, but it is still not recognized as being from the same curve.

EDIT: By saying;

it is not from the same curve

I mean, its what showed up when compiled.

kokke commented 6 years ago

Can I see the source code of the other ECDH library you're using?

kokke commented 6 years ago

I haven't been able to find another library that supported the same curves, so I haven't made any compliance testing against other libraries. I've only tested quickly against a few picks from http://point-at-infinity.org/ecc/nisttv

nguterresn commented 6 years ago

The library is: Node.js crypto

nguterresn commented 6 years ago

By the way, how can you test the vectors? k, x, and y replace which variable?

kokke commented 6 years ago

For a given curve and a given base point P the point Q = kP was calcaluted for several values k. The x and y coordinates of Q are given in the table below.

k is a constant, x and y are the coordinates for the base point P. For each curve, P can be found in the documents referenced above.

kokke commented 5 years ago

Closing the issue. Feel free to re-open if you feel you didn't get the answers you expected :)