polkadot-js/extension

ECDSA signing capability

goastler opened this issue · 6 comments

goastler commented
  • I'm submitting a...
  • Bug report
  • Feature request
  • Support request
  • Other
  • What is the current behavior and expected behavior?

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.

  • What is the motivation for changing the behavior?
    I need to be able to sign a payload using the polkadot JS extension and have this payload verified in a smart contract using ink!. Unfortunately, the polkadot JS extension provides sr25519 signing and ink! provides ECDSA verification. The two are not compatible.
  • Please tell us about your environment:

  • Version:

  • Environment:

    • Node.js
    • Browser
    • Other (limited support for other environments)

  • Language:

    • JavaScript
    • TypeScript (include tsc --version) (4.9.5)
    • Other

Please see the corresponding issue in the ink repo: paritytech/substrate#13703

jacogr commented

It can be added -

  • for the account creation, the overhead/advanced selection of crypto type is not something we are going to be doing (it is really kept bare-bones and simple, trying to not bombard with options)
  • via JSON import, you can import any type of account (e.g something created via the apps UI, or any wallet with account export functionality), either sr15519, ed25519 or ecdsa
goastler commented

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

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

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

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