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

Sign arbitrary data using a specified signature algorithm #1292

Open
2 of 4 tasks
yornaath opened this issue Nov 6, 2023 · 0 comments
Open
2 of 4 tasks

Sign arbitrary data using a specified signature algorithm #1292

yornaath opened this issue Nov 6, 2023 · 0 comments
Labels
Feature New functionality expanding SDK’s capabilities, adding tools or APIs for developers. P4 - Needs Investigation Requires analysis to determine cause or feasibility. Not fully understood, needs research first.

Comments

@yornaath
Copy link

yornaath commented Nov 6, 2023

  • I'm submitting a ...

    • Bug report
    • Feature request
    • Support request
    • Other
  • What is the current behavior and expected behavior?

When calling signRaw or signPayload on a Signer using the extension, the keyring pair type seems to be selected by the extension(what the user has configured or substrate default) and in cases where you want to use the users private-key/seed to generate a deterministic signature, accounts using the sr25519 type isn't a viable approach.

  • What is the motivation for changing the behavior?

We need to generate a deterministic signature using the users private key stored in the extension to generate a salt that is used to authenticate the users submission in a two step extrinsic submission process.

This is related to the new court implementation on zeitgeist where the user votes in secret and later reveals their vote.
For reference here is the kleros implementation outlined:

As currently implemented in the existing Kleros interface, the salt is generated by having the user use their Ethereum private key to sign a block of text that includes an identifier for the specific dispute. Then this salt is always recoverable from the main key by resigning the same text. Nonetheless, the signatures on this text with different keys will be different and are computationally infeasible to obtain without the user’s private key under the assumption of the security of the signature algorithm. Thus, a juror is prevented from copying the commitment of others. Nevertheless, if a user deletes her salt from her local memory, she can regenerate it as long as she retains access to her private key.

  • Wanted feature:

To be able to specify the type ethereum or other deterministic algorithm when signing arbitrary pieces of data using the wallet extension. In the assumption that the extension can use the same seed to generate the needed KeyringPair to sign the data.

@TarikGul TarikGul added P4 - Needs Investigation Requires analysis to determine cause or feasibility. Not fully understood, needs research first. Feature New functionality expanding SDK’s capabilities, adding tools or APIs for developers. labels Oct 30, 2024
@TarikGul TarikGul moved this to P4 - Needs Investigation in Polkadot-js general project board Oct 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature New functionality expanding SDK’s capabilities, adding tools or APIs for developers. P4 - Needs Investigation Requires analysis to determine cause or feasibility. Not fully understood, needs research first.
Projects
Status: P4 - Needs Investigation
Development

No branches or pull requests

2 participants