-
Notifications
You must be signed in to change notification settings - Fork 711
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add ED25519 and Secp256r1 #484
Conversation
Add additional signature recovery operations for the Edwards curve and P256.
Fixing links
src/vm/instruction_set.md
Outdated
|
||
If the signature cannot be verified, `MEM[$rA, 64]` is set to `0` and `$err` is set to `1`, otherwise `$err` is cleared. | ||
|
||
### ED19: Ed25519 signature recovery |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doing public key recovery with ed25519
is not possible, see this for instance.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should be verification
not signature recovery
. My bad.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not recovering the public key, it should just be verifying the signature against the public key and message.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The additions here are mainly for signature recovery over ECDSA for two curves (secp256k1 and secp256r1) and signature verification for edDSA over curve25519 (mostly known as Ed25519). We should be precise about that because it's not clear what exact signature scheme is used as it's currently specified in the draft spec.
Another thing is that you'd also want to make available operations over these curves as well. In other words, have opcodes for ECMUL, ECADD. I would recommend implementing EIP-1829 to easily support these elliptic curves and others that might be useful in the future, mainly as it pertains to the use of zero-knowledge proofs and other signature schemes.
@SilentCicero Any thoughs on the above? It might be a bit easier to add any other EC opcodes right now if we're going to need them. It might also make sense consider to whether a Sway-based implementation could be efficient enough. |
I think looking at it from a practical and behavioral perspective, the developer will be aiming at trying to do signature recovery in about 90% of cases. A sway based version will simply never be anywhere close to as efficient as a predefined opcode. I agree with Mikerah, we can add those additional EC opcodes after, perhaps with a host of others as well. |
# Conflicts: # src/protocol/cryptographic_primitives.md
Pushed some updates to the cryptography section, @Mikerah could you review this? |
…onal-signature-recovery # Conflicts: # src/fuel-vm/instruction-set.md
Abstract
Add additional signature recovery operations for Edwards 25519 and Secp256r1 (or P256) and renames
ERC
toECK1
for consistency.Opcodes
ECK1
for Secp256k1 signature recovery (non recoverable compressed signature)ECR1
for Secp256r1 signature recovery (non recoverable compressed signature)ED19
for ED25519 verification.