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

Feature: sign random string message #4655

Open
hairtail opened this issue Feb 1, 2024 · 4 comments
Open

Feature: sign random string message #4655

hairtail opened this issue Feb 1, 2024 · 4 comments
Labels
feature request New functionality added to Iron Fish

Comments

@hairtail
Copy link
Contributor

hairtail commented Feb 1, 2024

Description

To enable dapp provider to verify the address user is owner of this address, we need signMessage functionality. How does it work? To enable this feature, there should be 2 new methods added to ironfish-sdk.

  1. signMessage(message: string, secretKey: string): string
  2. verifyMessage(signed: string, publicKey: string): boolean
@hairtail hairtail added the feature request New functionality added to Iron Fish label Feb 1, 2024
@andiflabs
Copy link
Contributor

The process of signing a spend in an Iron Fish transaction involves the following (using terminology from the whitepaper):

  1. retrieving the Spend Authorization Key (ask) from the account
  2. randomizing the Spend Authorization Key (ask), which results in the Randomized Public Key (rk)
  3. using the Randomized Public Key (rk) to sign the spend contents

Is a scheme similar to the above what is being requested here? If that's the case, then the methods could potentially be used to sign/verify arbitrary descriptions within a transaction.

If the goal however is to prove that somebody owns a public address, then the above won't work. The public address is a JubJub public key that is used for key agreement, and for encrypting transactions. For one to prove that they own a public address through a digital signature, then we would need to use the public address to produce signatures. Using the same key for both signing and key agreement would go against key hygiene, but that's something we could accept. Given that the address is a JubJub key, I would recommend using RedDSA as the signature scheme to be in line with the ecosystem.

Given that, could you please clarify:

  • What key(s) would you like to use for creating and verifying signatures? The Spend Authorization Key (optionally randomized), or the Public Address directly?
  • What signature schemes would you like to be supported? Is RedDSA acceptable?

@hairtail
Copy link
Contributor Author

The process of signing a spend in an Iron Fish transaction involves the following (using terminology from the whitepaper):

  1. retrieving the Spend Authorization Key (ask) from the account
  2. randomizing the Spend Authorization Key (ask), which results in the Randomized Public Key (rk)
  3. using the Randomized Public Key (rk) to sign the spend contents

Is a scheme similar to the above what is being requested here? If that's the case, then the methods could potentially be used to sign/verify arbitrary descriptions within a transaction.

If the goal however is to prove that somebody owns a public address, then the above won't work. The public address is a JubJub public key that is used for key agreement, and for encrypting transactions. For one to prove that they own a public address through a digital signature, then we would need to use the public address to produce signatures. Using the same key for both signing and key agreement would go against key hygiene, but that's something we could accept. Given that the address is a JubJub key, I would recommend using RedDSA as the signature scheme to be in line with the ecosystem.

Given that, could you please clarify:

  • What key(s) would you like to use for creating and verifying signatures? The Spend Authorization Key (optionally randomized), or the Public Address directly?
  • What signature schemes would you like to be supported? Is RedDSA acceptable?

I'm not a cryptography focused developer, so I have no idea about which key or signature scheme to use. What I know and I recommend to learn is ethereum https://docs.ethers.org/v4/cookbook-signing.html#signing-a-string-message. The basic idea is,

  • sign a string with a key
  • verify with another public key
    And I'm thinking about whether we need this feature since address is private and only owner of this address knows in IronFish. We can discuss further.

@andiflabs
Copy link
Contributor

The main difference between Ethereum and Iron Fish is that Iron Fish is a privacy blockchain, and as such Iron Fish has a lot more complexity with regards to the keys and the signatures it uses. In fact, an Ethereum account is essentially just 1 key pair, and thus there is no ambiguity on how signing a message works.

I also looked into Zcash signmessage (https://zcash.github.io/rpc/signmessage.html), and found that it only supports t-addrs, i.e. the non-private addresses. Iron Fish only has private addresses (the equivalent of Zcash z-addrs). So I'm not aware of any prior work that we can use as our basis.

The problem that I'm trying to prevent here is breaking the privacy of Iron Fish accounts by introducing a signing method that reveals too much information. For that, I need to properly understand the goal of this feature request. So, let me ask, without going too deep into the cryptographic details: if I gave you a signed message, how would you verify it? Using my public address? Or using a more complex process that can preserve some privacy of my address? I assume you'd like something that uses the public address alone, but I want to make sure that's the case.

@hairtail
Copy link
Contributor Author

https://github.com/AleoHQ/sdk/blob/testnet3/wasm/src/account/signature.rs
How sign/verify works in Aleo, another privacy chain.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request New functionality added to Iron Fish
Projects
None yet
Development

No branches or pull requests

2 participants