signing alogrithm in eosjs-ecc yields different signature from that in eos!

[arc0035]

Hi,

I'm working on signature related development and I find that signing alogrithm in eosjs-ecc yields different signature from that in eos!!!! Both tag is dawn-v4.0.0.

Reproduce steps:

Firstly let's generate a signature from eos networks.

1 ) Let's have a transaction, for example:

{"expiration":"2018-05-23T07:29:11","ref_block_num":1,"ref_block_prefix":2,"max_net_usage_words":3,"max_cpu_usage_ms":4,"delay_sec":5,"context_free_actions":[],"actions":[{"account":"eosio.token","name":"issue","authorization":[{"actor":"eosio.token","permission":"active"}],"data":"0000000000ea305580969800000000000455445400000000056973737565"}],"transaction_extensions":[],"signatures":[],"context_free_data":[]}

And we use the default private key 5KQwrPbwdL6PhXujxW37FSSQZ1JiwsST4cqQzDeyXtP79zkvFD3

2 ) I add some printing statements in private_key.cpp:

3 ) I send this transaction to v1/wallet/sign_transaction interface via rpc. Then in eos side, we know the digest of the transaction is 9d8815193d76ee236ef08e8b9fb675e6def3af8d8209d7665540ab9e17944e19 (in hex)

4 ) The sign_transaction yields result:

{"expiration":"2018-05-22T23:29:11.000+0000","refBlockNum":1,"refBlockPrefix":2,"maxNetUsageWords":3,"maxKcpuUsageMs":4,"delaySec":5,"contextFreeActions":[],"actions":[{"account":"eosio.token","name":"issue","authorization":[{"actor":"eosio.token","permission":"active"}],"data":"0000000000ea305580969800000000000455445400000000056973737565"}],"transactionExtensions":[],"signatures":["SIG_K1_K3dztmFctY8QPgD6BEnxaV4s1gxyfHPZYTqHx8gH9Hiq2MLvn8Uc4ki6w7C89GVXAQ5JFM37BERe5qJSVHAqSkD8AabtKR"],"contextFreeData":[]}

You can see the signature is :

SIG_K1_K3dztmFctY8QPgD6BEnxaV4s1gxyfHPZYTqHx8gH9Hiq2MLvn8Uc4ki6w7C89GVXAQ5JFM37BERe5qJSVHAqSkD8AabtKR

Now let's try it from eosjs-ecc. Steps:

1 ) I write some simple code. The input:

Digest: 9d8815193d76ee236ef08e8b9fb675e6def3af8d8209d7665540ab9e17944e19

private key: 5KQwrPbwdL6PhXujxW37FSSQZ1JiwsST4cqQzDeyXtP79zkvFD3

2 ) Execute the code, the signature is:

SIG_K1_KgMrn3yteiHtoUnqBjBcVhjuJRkeXAfwaYFQaCDmMC6sD7mGU5qQRaz3GHWe96Mfvq5Ei56EHBiwjh7sg6GYjBGzcRv81Y

Background:

I'm writing a java based eos library and I've finished the java version fc-library. For the same transaction the java version fc-library yields same digest with eos side, however the final signatures are different(although I use the same private key). The signature in eos code refers to secp256k1.c in bitcoin and it is too hard for me to investigate so I have to refer to the eosjs-ecc for the ecc signing algorithm however by which I found that even for same digest and same private key the eosjs-ecc yields different signatures with this eos repository!!!

Any solution or advice on this please?

Regards

[jcalfee]

Thanks for all the helpful commands .. I'll work up a unit test and review implementations as soon as possible ..

Related: EOSIO/eosjs#121

[arc0035]

Hi jcalfee,

Thanks for the reply:)

[jcalfee]

Related #17

[jcalfee]

How did you get v1/wallet/sign_transaction to work? My test key is in keosd but this API is directly on nodeosd..

[arc0035]

Before my program call this signing interface, it will call wallet related rpc on 8888 to make sure that the wallet is unlocked and already imported the keys to sign :)

And we can force cleos to operate wallet through 8888 by setting this option: --wallet-url

[arc0035]

Hi ,

Any good news? :)

[jcalfee]

I'm working on this today .. A few simple things to get out of the way first.. Fortunately DPoS affords us some protection. Deterministic is better though.

[XuNeal]

Hey @jcalfee And @masonhunk, I have read the eos code, and compared the different between the eos and eosjs-ecc carefully. Now I can modify the eosjs-ecc to produce the same result with eos.

follow the @masonhunk testcase:

And the result is：

Pls check the PR:
#22

[arc0035]

@XuNeal Thanks and it looks good for me.

感谢大神

[jcalfee]

An update..

The canonical1 unit test I just checked in is the example above and includes @XuNeal's PR #22. It passes if I use the original method of checking for a canonical signature:

// toDer
const canonical = lenR === 32 && lenS === 32

This happens to be the most efficient when compared to the one below.

I have some confusion though, the other related ticket EOSIO/eosjs#121 references a Go implementation using a different (is)canonical condition. When I looked at how EOSIO/eos is being built, I found it is not simply checking the length of R and S anymore. It is using EOSIO/eos public_key::is_canonical. I implemented this (commit above) and found it is much slower and even causing one of the unit test to timeout. This other check does causes the second unit test (canonical2) to pass but the first to fail (canonical1).

So, only one unit test with pass at a time depending on the (is)canonical test being used.

The question remains: double check which is_canonical test is being used and find out why the discrepancy. After this is resolved we can have a valid unit test. It may be necessary to test with an alternative library such as secp256k1 (at npmjs) or perhaps just replacing bigi with bn.js. The BN.js library is probably a 2x speed improvement in some operations.