crypto: Add r1 ecrecover and verify to Move #7773
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
joyqvq
force-pushed
the
updatefc
branch
4 times, most recently
from
e558a0f to
9b0956a
Compare
joyqvq
added a commit
that referenced
this pull request
Jan 30, 2023
) ## What Changed - For CLI and SDK, a ECDSA k1 and r1 signature is produced using the nonrecoverable form. This means the signature is 64 bytes instead of 65. - The signature verification in sui also uses the nonrecoverable option. A valid signature should have 64 bytes. - For wallet, since only Ed25519 is supported, the secp256k1 change should not affect. - Also exposes secp256k1_verify and secp256k1_verify_recoverable API in move. - Ser/de of public keys and signatures now uses the most compact serialization with ToFromBytes. ## What Do You Need To Do - If you are using SDK to produce a Secp256k1 signature, no change is needed as long as you are using the latest version. - If you are using something else to produce a signature, your old signature will not be considered valid. You should just need to remove the last byte (65->64 bytes) to make it a valid signature again. Next: - r1 verify and verify_recoverable added in #7773
joyqvq
force-pushed
the
r1-move
branch
2 times, most recently
from
bb9bcbb to
b10895f
Compare
kchalkias
reviewed
Feb 1, 2023
| Ok(NativeResult::ok(cost, smallvec![Value::bool(result)])) | ||
| } | ||
|
|
||
| pub fn secp256r1_verify_recoverable( |
There was a problem hiding this comment.
what's the difference between this and the above function?
There was a problem hiding this comment.
the above verifies a nonrecoverable sig (64 bytes) vs this one verifies a recoverable one (65 bytes). they are documented at the move caller function signature instead of here since that's where the doc is generated.
There was a problem hiding this comment.
The verify function will recover the public key and compare it with the given public key, so if we want it this function, it could also be done using Move.
williampsmith
pushed a commit
that referenced
this pull request
Feb 3, 2023
) ## What Changed - For CLI and SDK, a ECDSA k1 and r1 signature is produced using the nonrecoverable form. This means the signature is 64 bytes instead of 65. - The signature verification in sui also uses the nonrecoverable option. A valid signature should have 64 bytes. - For wallet, since only Ed25519 is supported, the secp256k1 change should not affect. - Also exposes secp256k1_verify and secp256k1_verify_recoverable API in move. - Ser/de of public keys and signatures now uses the most compact serialization with ToFromBytes. ## What Do You Need To Do - If you are using SDK to produce a Secp256k1 signature, no change is needed as long as you are using the latest version. - If you are using something else to produce a signature, your old signature will not be considered valid. You should just need to remove the last byte (65->64 bytes) to make it a valid signature again. Next: - r1 verify and verify_recoverable added in #7773
joyqvq
force-pushed
the
r1-move
branch
2 times, most recently
from
586bd00 to
cb815fd
Compare
joyqvq
force-pushed
the
r1-move
branch
2 times, most recently
from
79afa4c to
d1d5c4a
Compare
jonas-lj
approved these changes
Feb 9, 2023
| Err(_) => return Ok(NativeResult::ok(cost, smallvec![Value::bool(false)])), | ||
| }; | ||
|
|
||
| let result = public_key.verify(&hashed_msg_ref, &signature).is_ok(); |
There was a problem hiding this comment.
Note that when fastcrypto is updated to most recent version, this should be verify_hashed instead of verify.
joyqvq
changed the title
joyqvq
changed the title
benr-ml
approved these changes
Feb 19, 2023
|
|
||
| pub const FAIL_TO_RECOVER_PUBKEY: u64 = 0; | ||
| pub const INVALID_SIGNATURE: u64 = 1; | ||
| pub const INVALID_PUBKEY: u64 = 2; | ||
|
|
||
| pub const KECCAK256: u8 = 3; |
kchalkias
approved these changes
Feb 20, 2023
| const EInvalidSignature: u64 = 1; | ||
|
|
||
| /// Hash function name that are valid for ecrecover and secp256k1_verify. | ||
| const KECCAK256: u8 = 3; |
There was a problem hiding this comment.
We should have a common shared list somewhere and document why KECCAK256: u8 = 3; sha256 = 4 etc (btw it doesn't matter if they collide with error codes (ie starting from zero), these flags serve a different role). Can we share these flags between k1 and r1 (instead of rewriting them?)
There was a problem hiding this comment.
reason why I had them here is bc they are accessible for ppl using these contract to easily find the definition. i can put this in hash.move, and link them in ecdsa_k1 and ecdsa_r1 module?
edit: Constants are internal to their module, and cannot can be accessed outside of their module <- came across this move error. revised to 0/1 instead of 3/4, but i will leave them within the k1 vs r1 modules.
Closed
1 task
alexsporn
pushed a commit
to iotaledger/iota
that referenced
this pull request
Sep 6, 2024
…423) ## What Changed - For CLI and SDK, a ECDSA k1 and r1 signature is produced using the nonrecoverable form. This means the signature is 64 bytes instead of 65. - The signature verification in sui also uses the nonrecoverable option. A valid signature should have 64 bytes. - For wallet, since only Ed25519 is supported, the secp256k1 change should not affect. - Also exposes secp256k1_verify and secp256k1_verify_recoverable API in move. - Ser/de of public keys and signatures now uses the most compact serialization with ToFromBytes. ## What Do You Need To Do - If you are using SDK to produce a Secp256k1 signature, no change is needed as long as you are using the latest version. - If you are using something else to produce a signature, your old signature will not be considered valid. You should just need to remove the last byte (65->64 bytes) to make it a valid signature again. Next: - r1 verify and verify_recoverable added in MystenLabs/sui#7773
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What changed
ecdsa_k1::ecrecover(sig, hashed_msg, hash_function)->ecdsa_k1::secp256k1_ecrecover(sig, msg, hash_function)ecdsa_k1::secp256k1_verify(sig, pk, hashed_msg)->ecdsa_k1::secp256k1_verify(sig, pk, msg, hash_function)new:
ecdsa_r1::secp256k1_ecrecover(sig, msg, hash_function)new:
ecdsa_r1::secp256k1_verify(sig, pk, msg)See md file for detailed descriptiosn.
What to do
Caller of these APIs required to provide the raw message instead of the hashed message, and provide the hash_function name (represented by u8, move does not have a concept of enum)