Secp256r1 and signing tool error

Technical Support
1

I have the following:

fastfrank@~ $ sui keytool list
                Sui Address                 |              Public Key (Base64)              | Scheme
----------------------------------------------------------------------------------------------------
 0x4cb2a458bcdea8593b261b2d90d0ec73053ca4de | AMapcI6o/KufoT+GZvKl+BT/lVsAq7Qe84fkI9e3Dnas  | ed25519
 0xcc9e52e70a2233fe80fea5458a24b94272a1b0e9 | AgNgevhsriSuu3jwL8TeY9g7rQJHOdCdVC9RbAgwi7NeeA== | secp256r1

fastfrank@~ $ sui client active-address
0xcc9e52e70a2233fe80fea5458a24b94272a1b0e9

fastfrank@~ $ sui client gas
                 Object ID                  |  Gas Value
----------------------------------------------------------------------
 0x5b93e69354fd073908031c80d8e4247c60662245 |   9999861
 0x72229b3ec58a5e92922093fc65750487ebf16c69 |   9999861

I then do:

fastfrank@~ $ sui client serialize-transfer-sui --sui-coin-object-id 0x5b93e69354fd073908031c80d8e4247c60662245 --to 0x4cb2a458bcdea8593b261b2d90d0ec73053ca4de --gas-budget 500
Data to sign: AAAAAANMsqRYvN6oWTsmGy2Q0OxzBTyk3gDMnlLnCiIz/oD+pUWKJLlCcqGw6VuT5pNU/Qc5CAMcgNjkJHxgZiJFjQAAAAAAAAAgYTgPH7LLHk4u7jN/SpNEnGfHdJLuuftXjuekE6E7OacBAAAAAAAAAPQBAAAAAAAA

However; when I use sui keytool sign I get:

fastfrank@~ $ sui keytool sign --address 0xcc9e52e70a2233fe80fea5458a24b94272a1b0e9 --data AAAAAANMsqRYvN6oWTsmGy2Q0OxzBTyk3gDMnlLnCiIz/oD+pUWKJLlCcqGw6VuT5pNU/Qc5CAMcgNjkJHxgZiJFjQAAAAAAAAAgYTgPH7LLHk4u7jN/SpNEnGfHdJLuuftXjuekE6E7OacBAAAAAAAAAPQBAAAAAAAA
2023-01-14T21:47:34.834967Z  INFO sui::keytool: Data to sign : AAAAAANMsqRYvN6oWTsmGy2Q0OxzBTyk3gDMnlLnCiIz/oD+pUWKJLlCcqGw6VuT5pNU/Qc5CAMcgNjkJHxgZiJFjQAAAAAAAAAgYTgPH7LLHk4u7jN/SpNEnGfHdJLuuftXjuekE6E7OacBAAAAAAAAAPQBAAAAAAAA
2023-01-14T21:47:34.834996Z  INFO sui::keytool: Address : 0xcc9e52e70a2233fe80fea5458a24b94272a1b0e9
unexpected end of input

Any idea?

23 Likes
4

I recently fixed an issue caused by intent signing in this PR: api: Use serialized signature for execute_transaction endpoint by joyqvq ¡ Pull Request #7185 ¡ MystenLabs/sui ¡ GitHub

based on what you posted, you may be using a sui before this fix is landed. can you make sure you use the latest sui build? and make sure what you pass in for the signing command is the one from “Intent Message to Sign: ${DATA_TO_SIGN}”?

See more example here sui/offline_signing.md at main ¡ MystenLabs/sui ¡ GitHub

6 Likes
5

Don’t know why our messages are being flagged in this channel.

Anyway, I had downloaded the binaries after 0.21.0 was deployed. I will re-fetch the binaries and try again, although the steps I took are the same in your documentation no?

I just did another binary install and there aren’t any changes that would have made a difference in the error. I guess I will wait for when your fix is deployed as I think the CLI usage I posted above shouldn’t need to change, correct?

Update: I was able to build sui from main in repo where keytool finished with good results!!

7 Likes
6

sui, I sincerely thank you…
You’re the best💋

1 Like
7

With respects to secp256r1 and the sentence in your document:

  1. The v represents the recovery ID, which must be normalized to 0, 1, 2 or 3. Note that unlike EIP-155 chain ID is not used to calculate the v value.

Is this ‘id’ a value on the txBytes I am signing? If not, how is the ‘v’ value determined?

1 Like
8

Chatting with Kostas, this has been resolved. I will test signature validation by rotating the v. A bit brute force at the moment but…

1 Like
9

:+1: yup thats how to get the recovery id by trying all values see more at ecdsa - How to determine first byte (recovery ID) for signatures (message signing)? - Bitcoin Stack Exchange

per this PR we are switching to nonrecoverable version for secp256k1/r1 crypto: ser/de update and use nonrecoverable sig for secp256k1/r1 by joyqvq ¡ Pull Request #7423 ¡ MystenLabs/sui ¡ GitHub should make it 0.25 and make sure you are submitting 64-byte signature by then

1 Like
10

Yes, the stack exchange accepted answer Method #2 would be the route if the PR you noted wasn’t going to happen. For now the ‘brute force’ approach is working but hitting RPC to fault to changing the ‘v’ is rather nasty.

Thanks for this follow up, I usually push a new pysui version within 24 hrs of a Sui release. All good!

1 Like
11

With 0.25.0 in devnet, I know and tested removing the recovery byte on the signature for secp256k1.

However; did it change for secp256r1 as well?

1 Like
12

yes they are both nonrecoverable i.e. 64 bytes for both r1 and k1.

13

Thank you, I have it working now!

14

sui, I sincerely thank you…
You’re the best :kissing_closed_eyes: