nRF9160 DK Ethereum Ecdsa "s problem"

[Gioele]

Hello!
We are trying to sign our data using ECDSA (https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/samples/crypto/ecdsa/README.html). 
We are comparing the results with signs of other projects and we see that our program computes the same sign but we ascertain that our "s" is wrong.
What should we do?
The ECDSA sample doesn't provide the Keccak256 algorithm so we implemented it ourselves. We think that there is a mistake with the procedure to obtain the "s value".
Please help us.

[dejans]

Hi,

We are comparing the results with signs of other projects and we see that our program computes the same sign but we ascertain that our "s" is wrong.

Could you elaborate on this?

We think that there is a mistake with the procedure to obtain the "s value".

Could you elaborate on this as well?

Best regards,
Dejan

[Gioele]

dejans said:

Could you elaborate on this?

When we talk about ECDSA we find out two important values that are r and s. These 2 values are appended to other characters to form the final output. 

This is the correct output that comes from another Python Project:

f86d0c850ba43b7400831e8480946fb6ba99b8a9f1330c1e83ec309c1dab81906e63880de0b6b3a7640000801ca0c4a47c3979ee3f169f2b1ad8b4754a0ea66297594af3b8d9e6f9a1dd01bd8152a0142e95021d0d979b1e49744421cbb0dbadcf48b3eba2b20957740f57a8e56d3b

This is the output that comes from the ECDSA provided by Nordic.

f86d0c850ba43b7400831e8480946fb6ba99b8a9f1330c1e83ec309c1dab81906e63880de0b6b3a7640000801ca0c4a47c3979ee3f169f2b1ad8b4754a0ea66297594af3b8d9e6f9a1dd01bd8152a0ebd16afde2f26864e1b68bbbde344f230cdf9432c3a5ee32685e4f352750d406

There is something that doesn't work, in detail we can see that the problem is related to the "s value" that is different, and that is wrong.

[dejans]

Hi,

Going back to my previous questions,

We are comparing the results with signs of other projects and we see that our program computes the same sign but we ascertain that our "s" is wrong.

What is our "s" that is wrong?

The ECDSA sample doesn't provide the Keccak256 algorithm so we implemented it ourselves. We think that there is a mistake with the procedure to obtain the "s value".

Where do you think is an error? What procedure do you refer to?

Gioele said:

This is the correct output that comes from another Python Project:

Gioele said:

This is the output that comes from the ECDSA provided by Nordic.

Could you explain in detail how you got both of these outputs?

Best regards,
Dejan

[Gioele]

dejans said:

What is our "s" that is wrong?

Correct

f86d0c850ba43b7400831e8480946fb6ba99b8a9f1330c1e83ec309c1dab81906e63880de0b6b3a7640000801ca0c4a47c3979ee3f169f2b1ad8b4754a0ea66297594af3b8d9e6f9a1dd01bd8152a0142e95021d0d979b1e49744421cbb0dbadcf48b3eba2b20957740f57a8e56d3b

Wrong

f86d0c850ba43b7400831e8480946fb6ba99b8a9f1330c1e83ec309c1dab81906e63880de0b6b3a7640000801ca0c4a47c3979ee3f169f2b1ad8b4754a0ea66297594af3b8d9e6f9a1dd01bd8152a0ebd16afde2f26864e1b68bbbde344f230cdf9432c3a5ee32685e4f352750d406

The first output comes from the Python program (web3 library), and the second output comes from the Nordic ECDSA example.

[dejans]

Hi,

Thank you for this information.

I would appreciate it if you could answer following 2 questions.

We think that there is a mistake with the procedure to obtain the "s value".

Could you provide more information about the procedure that you used in both cases?

dejans said:

Gioele said:

This is the correct output that comes from another Python Project:

Gioele said:

This is the output that comes from the ECDSA provided by Nordic.

Could you provide more information about the way in which you calculated the values you provided?

Best regards,
Dejan