Feat/ed25519-verify#7196
Conversation
| args: &[SymbolicExpression], | ||
| context: &TypingContext, | ||
| ) -> Result<TypeSignature, StaticCheckError> { | ||
| check_argument_count(3, args)?; |
There was a problem hiding this comment.
Same comment from #7187: If #7179 merges before this, it could use the new functions described #7179 (comment).
| ) -> Result<Value, VmExecutionError> { | ||
| // (ed25519-verify message signature public-key) | ||
| // message: (buff MAX_VALUE_SIZE), signature: (buff 64), public-key: (buff 32) | ||
| check_argument_count(3, args)?; |
There was a problem hiding this comment.
If #7179 merges before this, it could use the new functions described #7179 (comment).
| // message: (buff MAX_VALUE_SIZE), signature: (buff 64), public-key: (buff 32) | ||
| check_argument_count(3, args)?; | ||
|
|
||
| runtime_cost(ClarityCostFunction::Ed25519verify, exec_state, 0)?; |
There was a problem hiding this comment.
I think this should pass in the message length.
| SpecialFunction("native_secp256r1-verify", &crypto::special_secp256r1_verify) | ||
| } | ||
| Ed25519Verify => { | ||
| SpecialFunction("native_ed25519-verify", &crypto::special_ed25519_verify) |
There was a problem hiding this comment.
To steal Aaron's comment from my PR, could this be implemented with a NativeFunction205 instead of a SpecialFunction?
|
|
|
I was updating the Clarity 6 SIP draft (stacksgov/sips#267) with this function, and noticed that example you use in the PR description and docs is invalid:
You can see for yourself here: https://cyphr.me/ed25519_tool/ed.html We should make sure this example fails in the unit tests, and we should use the official test vectors from RFC 8032 (link) in our docs instead, and make sure we have them as part of our unit tests |
|
@jbencin-stacks examples updated and added a test for all of the rfc-provided vectors (i added more tests for non-conforming cases too) |
| Secp256r1Verify => "(secp256r1-verify 0xc3abef6a775793dfbc8e0719e7a1de1fc2f90d37a7912b1ce8e300a5a03b06a8 0xf2b8c0645caa7250e3b96d633cf40a88456e4ffbddffb69200c4e019039dfd310eac59293c23e6d6aa8b0c5d9e4e48fa4c4fdf1ace2ba618dc0263b5e90a0903 0x031e18532fd4754c02f3041d9c75ceb33b83ffd81ac7ce4fe882ccb1c98bc5896e)", | ||
| VerifyMerkleProof => "(verify-merkle-proof 0x0000000000000000000000000000000000000000000000000000000000000000 0x0000000000000000000000000000000000000000000000000000000000000000 u0 u1 (list))", | ||
| GetBitcoinTxOutput => "(get-bitcoin-tx-output? 0x0100000001000000000000000000000000000000000000000000000000000000000000000000000000ffffffff01e80300000000000016001400000000000000000000000000000000000000000000000000 u0)", | ||
| Ed25519Verify => "(ed25519-verify 0x68656c6c6f20776f726c64 0x7e8346b0d9ef1151608df9d436c646b9df23758b292e0df400032f2603417724a25997d81a95a8997a55252813589b9409893df1ec75249a5b6f38753232810e 0xec172b93ad5e563bf49683c1397357b1af93d4e937abda610c10ccc6112217c0)", |
There was a problem hiding this comment.
We are still using the invalid signature here (and in the PR description). Is this intentional?
5 participants
Description
This patch adds the ed25519-verify clarity function as well as an infrastructure for ed25519 curves.
It expects "(buff 1024), (buff 64), (buff 32)" and returns bool (if the signature is verified)
The message buffer can be between 0 and 1024 bytes.
The signature is 64 bytes.
The public key is 32 bytes.
Cost has been profiled to 7880 units and veries very little based on the size of the message (can be between 0 and 1024) so probably it could be kept as fixed and not linear as soon as the clarity6 costs table is pushed.
Applicable issues
Additional info (benefits, drawbacks, caveats)
Checklist
docs/property-testing.md)changelog.d/README.md)rpc/openapi.yamlfor RPC endpoints,event-dispatcher.mdfor new events)clarity-benchmarkingrepo