Shared secret byte size

[nguterresn]

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]

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]

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]

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]

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]

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

[kokke]

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]

The library is: Node.js crypto

[nguterresn]

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

[kokke]

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]

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