libitx / curvy Goto Github PK

First off, thanks for the library!

I'm trying out Curvy and realized that the hash produced was different from the hashes generated by libsecp256k1.

This sample for example generates totally different

private_key = Base.decode16!("8da4ef21b864d2cc526dbdb2a120bd2874c36c9d0a1fb7f8c63d7f7a8b41de8f", case: :lower)
message = <<0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 2>>

ExSecp256k1.sign(msg, private_key)
{:ok,
 {<<73, 102, 23, 43, 29, 88, 149, 68, 77, 65, 248, 57, 200, 155, 43, 249, 154,
    95, 100, 185, 121, 244, 84, 178, 159, 90, 254, 45, 27, 177, 221, 218>>,
  <<21, 214, 167, 20, 61, 86, 189, 86, 241, 39, 239, 70, 71, 66, 201, 140, 21,
    23, 206, 201, 129, 255, 24, 20, 160, 152, 36, 114, 115, 245, 33, 208>>, 1}}

Curvy.sign(msg, private_key)
<<48, 68, 2, 32, 112, 250, 91, 30, 30, 158, 220, 214, 106, 47, 254, 129, 4, 155,
  57, 80, 10, 104, 105, 84, 11, 30, 228, 232, 180, 55, 35, 240, 18, 139, 224,
  87, 2, 32, 80, 240, 185, 198, 24, 162, 98, 109, 119, 126, 246, 190, ...>>

Did I maybe miss out some options or any configuration? Any help would be very appreciated. Thanks.

I'm working with some code that uses the elliptic package to sign messages. I am unable to recover the same public keys from the message signatures with Curvy that I can with elliptic. I've confirmed that I can use something else like ex_secp256k1 to get the same key.

I have some sample code in a gist.

What I get over the wire is a message signature encoded in hex, in this format:

• one byte for the recovery parameter
• 32 bytes for r
• 32 bytes for s

In my case,

• recid: 1
• r: "5a86f1cfef1edd63aa7f1adaee39e5b4a5b8fc6046eab6def8892c5d46910b52"
• s: "4b3e0bedfd39e67abdca3fa9075231a809973fdf10a7568315803d2a9bebc148"

The message that is signed: "dc85768cf272d8245cce1ae289b3652e25bc415277898a5e4c93d66a881e180d"

I do

message = Base.decode16!("dc85768cf272d8245cce1ae289b3652e25bc415277898a5e4c93d66a881e180d", case: :lower)
r = Base.decode16!("5a86f1cfef1edd63aa7f1adaee39e5b4a5b8fc6046eab6def8892c5d46910b52", case: :lower)
s = Base.decode16!("4b3e0bedfd39e67abdca3fa9075231a809973fdf10a7568315803d2a9bebc148", case: :lower) 
sig = %Curvy.Signature{r: :binary.decode_unsigned(r), s: :binary.decode_unsigned(s), recid: 1}
pubkey = Curvy.recover_key(sig, message, recovery_id: 1)
Curvy.Key.to_pubkey(pubkey, compressed: true) |> Base.encode16(case: :lower)

I get "02393f94975f56dad52554004726804c70879de81417ce19426e78f750e47736e8"

This is different from the public key that I expect -- "0316b9dc66ec8b319b3d0a0ed0ec2ed433ab080f72c43fac6d51f48a0b8696e832"

I ran across this issue unfortunately in production and pin pointed it to this library. I am taking a long shot to see if I can get some help here to try and figure out since it might be a fly.io issue (where it is running).

The problem is when running this library specifically the function Curvy.Point.from_signature I get different result when I run it on fly.io performance 1x (1cpu 2g ram) vs performance 2x (2cpu 4gb ram). it sounds super weird and it does not make any sense at all. but you can test it yourself. if I use the 1cpu 2gb ram I get the correct output if I use the 2x I get something different and incorrect. I am currently using this data:

h = %Curvy.Signature{
  crv: :secp256k1,
  r: 27462290861368377106317665305475139729484250671029003276849655992901748136463,
  s: 49278084663456324900439980625699735952049995474473875901242523847508523962507,
  recid: 1
}
e = 85828530085761356590881009176730686927247139255163425800730509011698354124264754777696681518680540632563750302824114232813037563691036130495824434273410109125

Curvy.Point.from_signature(h, e, 1)
PERFORMANCE 1x => %Curvy.Point{
  x: 21026287953916813935315438036140378323142641038681797433477043486634401051487,
  y: 91960139165877582792591083730413972977291791332509437275899263858086688076374
}

PERFORMANCE 2x => %Curvy.Point{
  x: 66631749070421438235840519421079346432769668030421968951305889582288151693947,
  y: 105777883481625897350271701715057544644545525199853167459721647531376256886347
}

I know this MIGHT be a fly issue but I just dont even know what that could be I will try and reach out also but just taking a long shot seeing if by any chance anyone knows why this is what is causing the inconsistency. Thank you.

warning: use Bitwise is deprecated. import Bitwise instead
lib/curvy.ex:111: Curvy

Shouldn't be a big deal... I could make a quick PR to fix this.