Extra byte at the start of a public key

Guilherme Andrade g@REDACTED
Sat Jul 11 02:56:27 CEST 2020


Hello Ludovic,

I was debugging the execution of your example code, from "crypto.erl" until
the OpenSSL API, but at some point I lost track - particularly because the
interfacing seems to have changed significantly between OTP 21.3 and OTP 23.

At any rate, along the way I encountered the ASN.1 concept of an "octet
string"[1] - binary data whose length is a multiple of eight. It seems to
fit the output of the code you've shown (the value of that extra byte, 4,
when multiplied by 8, yields 32, and so it does look like a length prefix
for the public key.) It also seems to be the return format of some of the
OpenSSL functions invoked by the code in question back in OTP 21.3, like
`EC_POINT_point2oct`[1].

But this is mostly guessing and intuition - I'm very possibly talking out
of my backside. Hopefully someone who knows what they're talking about will
answer your question.

[1]: https://www.obj-sys.com/asn1tutorial/node10.html
[2]: https://www.openssl.org/docs/man1.0.2/man3/EC_POINT_point2oct.html


On Fri, 10 Jul 2020 at 15: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
>
>

-- 
Guilherme
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20200711/a43912c7/attachment.htm>


More information about the erlang-questions mailing list