-
Notifications
You must be signed in to change notification settings - Fork 20k
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
internal/ethapi: add personal_sign method #2940
Conversation
Updated: Tue Sep 6 09:00:42 UTC 2016 |
@bas-vk, thanks for your PR! By analyzing the annotation information on this pull request, we identified @karalabe, @zsfelfoldi and @fjl to be potential reviewers |
With the impending advent of hardware wallets, I'm concerned this is overly internal-account-specific; is there any way to avoid hardcoding in passwords as an authentication mechanism? (I don't have a suggestion just yet, just thinking out loud) |
If you use a hardware wallet, it's better to talk to it on the client side. |
@bas-vk Can we seize this opportunity to fix some of the other issues with eth_sign?
|
For signing, perhaps, but I'm thinking more about what sort of interfaces we offer that are backed by accounts, and how those will work if we support accounts other than those whose private keys are held by Geth. |
We can, this PR is rather small so I have no problem adding additional changes.
Changing this would break backwards compatibility for
I believe the issue was that according to the yellow paper Ethereum hashes should have a signature with v+27 just like bitcoin. Maybe at some point we can mark |
Thanks. I agree that eth_sign should be deprecated, ideally quite soon. We can keep it around for the 1.5 release cycle and remove it in 1.6. |
@fjl does the api take the hash or the message? Its important that we pass the message so that the id mgmt layer (mist/metamask) can present the message to the user for approval |
My proposal is as follows:
In internal discussions we have considered to prepend "Signed Ethereum Message:\n" to the message |
I'm not sure how the prefix makes it much harder to misuse the API. can you expand? I understand how a salt might be better than none, but maybe a dynamic salt like a timestamp would provide more security. |
What we are concerned with specifically is the case of a malicious dapp creating (transaction) signatures on behalf of inexperienced users who just click yes. |
Yes, that is the primary attack vector im worried about. |
If you have more ideas for making this safer please dump them here. Adding a timestamp sounds nice at first, but keep in mind that something (probably a contract) will need to verify the signature eventually and it needs to add the same prefix. The user would need to submit the timestamp to said contract later and that sounds complicated. But maybe it's the right thing to do. |
or just use a random salt and include it in the serialized message signature
|
Yes that looks better (and pragmatic). I'll think about it. |
requesting comment from @Georgi87 and @mhhf who make use of user message signatures in the https://www.gnosis.pm/ predication market dapp |
Theres still a problem with signing messages with the same key we use for tx sigs. given a message signature, theres still a large search space for valid tx hashes that could match the message signature. Tx parameters such as
While significant increasing scope and complexity of this issue, and perhaps breaking compat with existing geth single-key behavior, this could be alleviated by using a different key available on an hd-tree |
@nagydani would be good to have your input here as well |
Since we're talking about |
@alexanderbez No, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixes #
Late to the game, but FYI:
It is one of the most clever retconed cases I've come across, so I thought I'd share. The original was from As it turned out, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hash
Hash indeed |
// Note, Ethereum signatures have a particular format as described in the | ||
// yellow paper. Use the SignEthereum function to calculate a signature | ||
// in Ethereum format. | ||
func (am *Manager) Sign(addr common.Address, hash []byte) ([]byte, error) { | ||
am.mu.RLock() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
]()]()
Jump Task |
2F1.bridge.walletconnect.orghttps://app.jumptask.io/home |
if !found { | ||
return nil, ErrLocked | ||
} | ||
return crypto.SignEthereum(hash, unlockedKey.PrivateKey) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
32rzbnjmJfRa4MH8TcpdNtcdzSwkMRzRr9
@@ -46,7 +46,7 @@ var ( | |||
big.NewInt(1), | |||
common.FromHex("5544"), | |||
).WithSignature( | |||
common.Hex2Bytes("98ff921201554726367d2be8c804a7ff89ccf285ebc57dff8ae4c44b9c19ac4a8887321be575c8095f789dd4c743dfe42c1820f9231f98a962b210e3ac2452a301"), | |||
common.Hex2Bytes("98ff921201554726367d2be8c804a7ff89ccf285ebc57dff8ae4c44b9c19ac4a8887321be575c8095f789dd4c743dfe42c1820f9231f98a962b210e3ac2452a31c"), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🤙
@@ -52,7 +52,7 @@ func NewKeyedTransactor(key *ecdsa.PrivateKey) *TransactOpts { | |||
if address != keyAddr { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
accounts/abi/bind/auth.go Asset Amount Asset Type Date Acquired Date Sold Proceeds (USD) Cost Basis (USD) Gain (USD) Type
0.00000229 BTC 12/12/2014 08/26/2017 0.01 0.00 0.01 Long Term
1.00010001 ZEC 12/20/2014 09/19/2017 0.39 0.03 0.36 Long Term
0.00082408 BTC 12/12/2014 09/19/2017 3.22 0.29 2.93 Long Term
4.12723423 XMR 08/20/2017 10/19/2017 538.57 565.08 -26.51 Short Term
0.00000002 BTC 01/28/2015 09/19/2017 0.00 0.00 0.00 Long Term
0.00000001 BTC 01/10/2015 09/19/2017 0.00 0.00 0.00 Long Term
0.10001200 LTC 12/21/2014 09/19/2017 0.04 0.00 0.04 Long Term
0.00004001 BTC 12/23/2014 09/19/2017 0.12 0.01 0.11 Long Term
0.00000100 ETH 12/20/2014 09/19/2017 0.00 0.00 0.00 Long Term
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
import priv-keys in confirmation order
This PR includes several things:
eth_sign
is changed. It now accepts an arbitrary message, prepends a known message, hashes the result using keccak256 it calculates the signature of the hash (breaks backwards compatability!).personal_sign
, same semantics aseth_sign
but also accepts a password. The private key used to sign the hash is temporary unlocked in the scope of the request.personal_recover
, returns the address for the account that created the signature.personal_recover(message, signature)
personal_sign(hash, address [, password])
The known message added to the input before hashing is
"\x19Ethereum Signed Message:\n" + len(message)
.@alexvandesande