Skip to content
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

Support SECP256K signature verification #4233

Closed
Benjmhart opened this issue Nov 23, 2021 · 15 comments · Fixed by #4368
Closed

Support SECP256K signature verification #4233

Benjmhart opened this issue Nov 23, 2021 · 15 comments · Fixed by #4368

Comments

@Benjmhart
Copy link

Describe the feature you'd like

In order to support decentralized bridge technologies for the ERC20 token converter project and other bridging projects, it is clear that the SECP256k signature scheme is needed - likely as a low-level call from the plutus interpreter directly

Describe alternatives you've considered

We've done some initial research on this at MLabs, and one of our researchers pointed to this existing implementation:
https://github.com/Chia-Network/bls-signatures

which has FFI bindings in Haskell:
https://github.com/hexresearch/hschain/tree/master/bls-signatures

@michaelpj
Copy link
Contributor

The main thing we need is a high-quality, trustworthy implementation that we're comfortable linking into the Cardano node stack.

The linked implementation doesn't fill me with confidence:

NOTE: THIS LIBRARY IS NOT YET FORMALLY REVIEWED FOR SECURITY

Are there any others?

@Benjmhart
Copy link
Author

https://github.com/bitcoin-core/secp256k1 - Bitcoin's implementation

https://hackage.haskell.org/package/secp256k1 - another Haskell binding i quickly found

@Benjmhart
Copy link
Author

If you can enumerate your standards, happy to dig deeper on this.

@michaelpj
Copy link
Contributor

It would also be helpful to explain some of the usecases a bit more clearly, also so we know we're actually providing the right primitives.

@michaelpj
Copy link
Contributor

From a brief internal consultation the bitcoin library is probably fine. I don't know whether the Haskell binding is good quality, that would need to be reviewed too.

I suspect the best next step would be a PR of an implementation of the relevant bits in cardano-crypto-class, probably it should fit into DSIGN if you're looking for the signature verification part: https://github.com/input-output-hk/cardano-base/tree/master/cardano-crypto-class/src/Cardano/Crypto/DSIGN

@L-as
Copy link
Contributor

L-as commented Nov 23, 2021

https://github.com/haskoin/secp256k1-haskell seems to be of OK quality.

@Benjmhart
Copy link
Author

@michaelpj - this actually comes from the ERC20 token converter team, who hopes to use the technology of Wanchain or similar to bridge tokens onto cardano in a decentralized fashion.

These technologies break up the private key among multiple validators, so that only by working in concert, can they properly sign a transaction.

Since the default transaction-level signature is incompatible, they wish to provide the signature in Datum to be validated at the smart contract level.

@kozross
Copy link
Contributor

kozross commented Jan 24, 2022

@michaelpj Now that the PR to cardano-base is done (and nearly merged), what should be the next step? There's already a VerifySignature builtin, but it's hardcoded to a specific algorithm. Should I add another builtin, or generalize the existing one?

@michaelpj
Copy link
Contributor

New builtin. It's unfortunate that we gave verifySignature such a generic name, it should really have been verifyEd25519Signature. The challenge will be costing it, but for now I think just leave the costing function as mempty.

@L-as
Copy link
Contributor

L-as commented Jan 25, 2022

Can't you rename it to that, and make the old name in PlutusTx.Builtins a deprecated alias of that?

@michaelpj
Copy link
Contributor

That won't change the name in Plutus Core. We can potentially do something like that at the library level.

@michaelpj
Copy link
Contributor

BTW: I'm not going to insist that we follow cardano-foundation/CIPs#215 before getting this merged (unless you want to!), but I would be keen to collaborate on a retroactive CIP. Partly to enshrine the motivation etc., and partly just to put more examples through the process.

@kozross
Copy link
Contributor

kozross commented Feb 15, 2022

@michaelpj I'd be happy to collaborate on a retroactive CIP. How would you like to do this?

@michaelpj
Copy link
Contributor

I'll share a google doc with you. It's not the best editor for this, but it's good for collaboration and we can port it to markdown later.

@KowsarAtz
Copy link

@michaelpj There is a related issue (#4575) that I would appreciate it if you take a look at it. We need to recover a public key from a signature (produced with an ethereum address) and a message hash. What we need is basically the exact implementation of ethereum ecrecover function which can be implemented using functions provided by libsecp256k1.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants