search

polkadot-js / extension

Simple browser extension for managing Polkadot and Substrate network accounts in a browser. Allows the signing of extrinsics using these accounts. Also provides a simple interface for compliant extensions for dapps.
Apache License 2.0
972 stars 417 forks source link

ECDSA signing capability #1237

Open goastler opened 1 year ago

goastler commented 1 year ago

I want to sign a payload using ECDSA. Currently, the polkadot JS extension only signs payloads using sr25519. There is no option / capability to sign using other methods. Following the cookbook recipes a sr25519 signature is produced.

I would expect to be able to do signatures for ECDSA, especially considering ink! provides an ecdsa_recover() function.

Please see the corresponding issue in the ink repo: https://github.com/paritytech/substrate/issues/13703

goastler commented 1 year ago

@forgetso

jacogr commented 1 year ago

It can be added -

goastler commented 1 year ago

So account creation is fixed to sr25519, which is fair enough and does keep things simple. I'm not familiar with the overhead associated, but could the accounts be loaded in all formats (ecdsa, ed25519, sr25519) to provide a signing mechanism for any crypto type?

Importing the account is not an option for us as our users would have already loaded their account into the extension, defaulting to sr25519 format. I have managed to import a test account via JSON and set the account type to ecdsa, and this works. However not having control over the user's account, I cannot do the same with theirs

Thanks for your help :)

jacogr commented 1 year ago

Yes, it is a bit of an issue for this usecase.

We really don't want to triple-up on accounts created, for instance in my specific case that would mean going from 70 accounts managed to 210. (Even on light use, say 5 accounts, it would me 15 - which goes from "easy" to "unwieldly") Each account has an own address (publicKey) and own secret, so it is not really an option "hiding it somewhere", it needs to be exposed as an account to enable functionality on it.

TL;DR There is no solution for this specific requirement as it stands.

goastler commented 1 year ago

I completely appreciate that, it's definitely a tricky problem.

Given the overhead of loading accounts in all formats as you've described, could we do that on-demand per account? E.g. say I have account A, B and C all in sr25519 format. Could we add a function to reload an account in a different format? Perhaps accountB.reload('edcsa')? This would replace the current sr25519 version with an ecdsa version. This way there is only ever 3 accounts, minimising overhead

drhanlondon commented 1 year ago

I agree with @goastler 's request of ECDSA signing capability in Polkadot.js extension. Your question and comments on Stackexchange (https://substrate.stackexchange.com/questions/7625/how-to-sign-a-payload-using-ecdsa-in-polkadotjs/7801#7801) was very helpful.

I have researched "signing a transaction payload offline with aws KMS (ECDSA secp256k1 curve)" on Polkadot blockchain as we were motivated from AWS blockchain research (https://aws.amazon.com/blogs/database/part1-use-aws-kms-to-securely-manage-ethereum-accounts/) where an Ethereum transaction payload is signed offline in HSM (Hardware Security Module) managed by aws KMS.

I am exploring an alternative way for ECDSA signing in Polkadot. I have raised a question on Stackexchange (https://substrate.stackexchange.com/questions/8135/what-informations-consist-of-a-signature-which-is-generated-when-siging-a-transa)

I would be grateful if @jacogr and @goastler could visit it and leave some advice. Thanks