Extra byte at the start of a public key

[Bram Verburg]

A public key on an elliptic curve is formally defined by an X and a Y
coordinate. However, given only the X coordinate and the curve parameters,
the value of Y squared can be calculated, which leaves only two candidates
for the actual value of Y. So many systems support 'compressions' of EC
points to save space: they express a public key as an X coordinate plus a
flag to indicate which of the two possible Y values to use.

The Erlang crypto library returns the public key in uncompressed format,
which is indicated by the 0x04 byte. If point compression were applied, the
value would be 0x02 or 0x03 (the flag to indicate which Y coordinate to
select) plus a 256 bit X coordinate.

TL;DR: yes, for interoperability with tools that use raw uncompressed EC
points, the leading 0x04 can be dropped.

On Fri, 10 Jul 2020 at 17:38, ludovic@REDACTED <ludovic@REDACTED>
wrote:

> Hello,
>
> I am trying some crypto code, mostly for fun. I want to generate an
> Ethereum public key from a know private key.
>
> This is a sample private key :
> <<22,99,59,58,153,154,229,99,217,142,170,105,82,105,204,11,55,249,101,152,109,41,109,195,18,134,228,189,83,139,28,92>>
>
> I run this code:
>
>     -module(t).
>     -export([run/0]).
>
>     run() ->
>         PrivateKey =
> <<22,99,59,58,153,154,229,99,217,142,170,105,82,105,204,11,55,249,101,152,109,41,109,195,18,134,228,189,83,139,28,92>>,
>         {PublicKey, NewPrivateKey} = crypto:generate_key(ecdh, secp256k1,
> PrivateKey),
>         dump_hex("Private key", PrivateKey),
>         dump_hex("Public key", PublicKey).
>
>     dump_hex(Label, Bin) ->
>         io:format("~s: ~s~n", [Label, [io_lib:format("~2.16.0B",[X]) ||
> <<X:8>> <= Bin]]).
>
> And I get this result:
>
>     Private key:
> 16633B3A999AE563D98EAA695269CC0B37F965986D296DC31286E4BD538B1C5C
>     Public key:
> 047D5ED8E5B1843FF0EF0F443419E3DC589D900F3C683D2D7268AC1D9FE47F7E7350A1...(cut)
>
> But I am expected to find this:
> 7D5ED8E5B1843FF0EF0F443419E3DC589D900F3C683D2D7268AC1D9FE47F7E7350A...(cut)
>
> At first I was quite discouraged because crypto is hard to learn, but
> after giving a closer look I found that I have the correct key actually. I
> just have an extra leading byte. The expected length is 512 bits and I have
> 520.
>
> Expected   7D5ED8E5B1843FF0EF0F443419E3DC589D900F3C683D...(cut)
> Mine     047D5ED8E5B1843FF0EF0F443419E3DC589D900F3C683D...(cut)
>
> Do you know why the crypto library behaves like this ? Can I just cut the
> extra leading byte ?
>
> Thank you
>
> - lud
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20200711/c0dfdac3/attachment.htm>