-
Notifications
You must be signed in to change notification settings - Fork 58
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
[crypto]: Host function for verifying secp256r1 signatures #113
base: main
Are you sure you want to change the base?
[crypto]: Host function for verifying secp256r1 signatures #113
Conversation
…tion as an host function
As a rule, all new elliptic curves should use our new versatile crypto framework:
We'd ideally audit that framework too before deploying it, because I've made one or two "unique" choices there, like host calls return points in projective coordinates. It'd be nice if the auditor could discuss more generic framework ideas too, like providing the curve parameters. In theorey, it'd be cool if we supported the rust crypto traits and provided a drop in for p256, but rust crypto traits are a bloody complex mess, so maybe arkworks provides a cleaner trait framework. As for doing a simple hostcall like this, we'd ideally want strong evidence the curve would never be used other than via the simple hostcall, but obviously P256 should apear in zk glue protocols, hence its existance in https://github.com/arkworks-rs/algebra/tree/master/curves/secp256r1 Anyways we should definitely att P256 to https://github.com/paritytech/arkworks-extensions and the curve hostcalls, and update everything to more recent arkwroks. |
Thank you for the comments. Substrate already uses k256 for the The initial idea was to add a new function If |
Not really. In principle any elliptic curve crate like k256 or p256 could be forked to use the scalar multiplications provided by the host call, with any other crate that implements the same curve living behind the host call. Arkworks does not have optimal implementations of anything, so ideally most arkworks curve crates should've forks that call better crates too.
Not yet, but they're part of sassafras & jam. We can push them through faster too, but.. We make the hostcalls using uncompressed affine coordinates. I'd like to have some second opinions on how I've designed this. It's not absolutely critical, since you can always convert to/from cordinates, but someone who knows how all the different SW curve implementations work could be informative, and if osme conversion uses a division then best avoided. About your applications: Apple's Secure Enclave could likely use the hostcall you suggest here, and ECDSA lacks nice batch verification, so that's a clear fit for exactly this hostcall, provided it does not break anonymity. Webauthn and Passkeys would likely add anonymity like keyless accounts, so then ideally you'd have some plonk with folking using P256 directly in places. This really need like all of arkworks. Android Keystore could go either way I guess. Or wait, does each enclave have a different secret key? If so, then you might need the keyless accounts snark tricks for everything. |
Anyways someone should do a PR to paritytech/arkworks-extensions and substrate that uses the arkworks secp256r1. We'll deploy secp256r1 when we deploy all the others, which must happen anyways. |
I maybe misunderstanding you but if this is true, can't we open a PR to
Just to confirm, are you suggesting that we can open PRs to |
I agree with @burdges on this point. I believe that we should work on an RFC to promote the inclusion of the host functions for arkworks (def here) on kusama/polkadot. These will not only be necessary if some parachain adopts Sassafras in the future, but they will also unlock a whole new class of arbitrary zk applications for the Polkadot ecosystem. Currently, the secp256r1 hooks are still missing, by the way. |
At a high level, we want rust cryptographic code from the wider rust ecosystem to work cleanly inside runtimes. This is far nicer for developers than blockchains like ETH which require reimplementing everything. It's also defends our ecosystem from compeating ones like cosmos who lack on-chain upgrades and thus benefit from native code directly. In elliptic curve, our big performance hits come from scalar multiplications and multi-scalar multiplication, and also miller loops and final exponentiations for pairing curves. We propose stable host calls for only those operations, along with facade crates that provide drop in replacements for elliptic curve crates.
We ideally want one set of sec256r1/p256 host calls: one multi scalar multiplication, one projective scalar multiplication, and optionally one affine->projective scalar multiplication if performacne differs much from the projective one. Ideally, this one set of host calls should permit both a Step 0. Descide if affine->projective scalar multiplication is much faster than regular projective scalar multiplication, aka read the Step 1. Write an Step 2. Write a Step 3. Write a We'd push for tressury funding for external people of course.
We could skip steps 1 and 3 above if we cared little about the speed difference between rustcrypto and arkworks, but we do afaik care about this speed difference for secp256k1, so may as well do both exactly the same, no? I'd like someone to attempt step 1 for at least secp256k1, or else show benchmarks that arkworks is faster than I think. |
Before JAM obviously. They're probably worth pushing forward faster though. We're obviously seeing more community interest now, so maybe worth push forward soon. They improve many other priorities too, like keyless accounts, identity, and games. |
Hello, I am Piotr - head of Product at Moonbeam Foundation. This feature would significantly speed up the adoption of Smart Wallets. Do you have any estimates of when this could be incorporated and shipped? |
I've an outline for the work at https://hackmd.io/@rgbPIkIdTwSICPuAq67Jbw/r1dRCb86C but so far I've not pushed anyone towards doing it, just mentioned it exists. We should figure out who wants to do this work. Audits are cool, but actually my "audit" questions can be handled in simpler ways, so I'll do that this week. |
No description provided.