[PULL] Sign and verify message with bitcoin address and public key - page 3.

khal

hero member

Activity: 540

Merit: 500

Quote

How about you prepend "This signed message is not intended to form a contract:" to the message before you hash it on both generation and verification sides?
I know it's English-centric but it's a lot better than nothing.

I think we don't need to display this message to users, so we can put what we want. It will belong to the internal mechanism of the signing/verifying functions.
The signmessage and verifymessage would still do their job.

Quote

You imply that a JSON error should be generated if the message does not have a valid signature. I don't know much about JSON but I imagine that JSON errors should only be generated when something goes wrong with the JSON side of things. In this case, the JSON is working just fine, it's higher level misbehaviour which needs to be reported.

I've searched through rpc.cpp and i don't see another way of doing it, so i'll follow the "standard". However, i don't know which code number to use is the json error. What do they correspond to ?

Quote

I suggest that you return a message which reports that the signature verification failed and possibly return some data from the failed ECDSA verification so that users can check the maths when debugging.

There is no more data except:

Code:

// -1 = error, 0 = bad sig, 1 = good

If you know how to retreive more info, feel free to modify the code :p

ByteCoin

sr. member

Activity: 416

Merit: 277

Quote from: khal on April 26, 2011, 04:20:00 AM

By "idiosyncratic but standardized padding", do you mean just adding some chars in a predefined way ?

Yes.

How about you prepend "This signed message is not intended to form a contract:" to the message before you hash it on both generation and verification sides?
I know it's English-centric but it's a lot better than nothing.

You imply that a JSON error should be generated if the message does not have a valid signature. I don't know much about JSON but I imagine that JSON errors should only be generated when something goes wrong with the JSON side of things. In this case, the JSON is working just fine, it's higher level misbehaviour which needs to be reported.

I suggest that you return a message which reports that the signature verification failed and possibly return some data from the failed ECDSA verification so that users can check the maths when debugging.

ByteCoin

khal

hero member

Activity: 540

Merit: 500

Quote from: Gavin Andresen on April 25, 2011, 07:28:33 PM

This might just be a documentation issue, although if signmessage was changed to sign a hash of the passed-in message instead of the message itself then it would be completely safe.

signmessage already hash the message before signing it.

Quote from: ByteCoin on April 25, 2011, 08:01:50 PM

Yes you could paper over the problem by making signmessage use a different hash function or prepend some idiosyncratic but standardized padding to the message before hashing or use >2 rounds of SHA256.

By "idiosyncratic but standardized padding", do you mean just adding some chars in a predefined way ?

If 2 lines of code could avoid potential problems, we should add them :p

theymos

administrator

Activity: 5166

Merit: 12850

Quote from: ByteCoin on April 25, 2011, 08:01:50 PM

When you spend coins by signing transactions, don't you sign a double SHA256 hash of the transaction?

You sign some other stuff, too, which prevents that attack.

casascius

vip

Activity: 1386

Merit: 1136

The Casascius 1oz 10BTC Silver Round (w/ Gold B)

It would be great if this paved the way for a self-audit mechanism that allowed organizations (such as MyBitcoin, MtGox) holding BTC on behalf of others to provide proof they still possess the BTC to each account holder, especially if it could be done in a way that also avoided publication of the set of coins in the organization's wallet for the benefit of people trying to decipher the block chain.

ByteCoin

sr. member

Activity: 416

Merit: 277

Quote from: Gavin Andresen on April 25, 2011, 07:28:33 PM

if signmessage was changed to sign a hash of the passed-in message instead of the message itself then it would be completely safe.

(Assuming that signmessage were to use a single SHA256 pass)

When you spend coins by signing transactions, don't you sign a double SHA256 hash of the transaction? I'm looking at SignatureHash in script.cpp and Hash in util.h. So if an attacker passes to signmessage a single SHA256 hash of a valid transaction payload then the attacker can spend the signer's coins. The signer couldn't possibly work out what the effect of signing the attacker's message might be, without reversing SHA256. This is possibly the first cryptographic disadvantage of the double hashing scheme employed in bitcoin.

Also, in other applications it's common to form a contract by signing a hash of a message rather than a (short) message.

To avoid all these possible problems, you have to approve of the content you sign.

ByteCoin

PS Yes you could paper over the problem by making signmessage use a different hash function or prepend some idiosyncratic but standardized padding to the message before hashing or use >2 rounds of SHA256.

Gavin Andresen

legendary

Activity: 1652

Merit: 2216

Chief Scientist

Quote from: ByteCoin on April 25, 2011, 07:12:35 PM

If an attacker can force you to sign arbitrary messages, that's certainly a security flaw. The solution is to take good care that you approve of whatever content you are thinking of signing whether it be cheques, loan agreements, wills or numbers.

So: the danger isn't revealing private keys (I mis-remembered), the danger is a naive developer will see the signmessage RPC command, not realize that signing arbitrary data can be dangerous, and put up a web page that lets somebody enter arbitrary data to be signed with one of the developer's public keys.

This might just be a documentation issue, although if signmessage was changed to sign a hash of the passed-in message instead of the message itself then it would be completely safe.

ByteCoin

sr. member

Activity: 416

Merit: 277

Quote from: gavinandresen

Can you start a forum thread about this? There was some concern about possible attacks revealing private keys if the attacker can send arbitrary data to be signed.

It's reasonable to expect that for a specially crafted message to somehow reveal the private key upon signing, one would have to be able to find messages that hash to particular values. This would constitute the worst possible failure of the relevant hash function.
Even if the hash function were completely broken as above, there is no method currently known that allows the recovery of the private key from a signed message faster than solving the discrete logarithm problem on the relevant elliptic curve. If one were to be found, it would constitute a very severe weakness in DSA and ECDSA.

If an attacker can force you to sign arbitrary messages, that's certainly a security flaw. The solution is to take good care that you approve of whatever content you are thinking of signing whether it be cheques, loan agreements, wills or numbers.

ByteCoin

kokjo

legendary

Activity: 1050

Merit: 1000

You are WRONG!

Quote from: khal on April 25, 2011, 06:59:51 AM

From https://github.com/bitcoin/bitcoin/pull/183 :

Quote from: gavinandresen

Can you start a forum thread about this? There was some concern about possible attacks revealing private keys if the attacker can send arbitrary data to be signed.

im not sure about ECDSA, but rsa have a blind signing flaw: http://en.wikipedia.org/wiki/Blind_signature#Dangers_of_blind_signing
also if an attaker is able to sign just something, he/she could sign a transaction that send him/her all your coins... Sad

i think it's a dangerous but useful feature, but i would not use it.

khal

hero member

Activity: 540

Merit: 500

From https://github.com/bitcoin/bitcoin/pull/183 :

Quote from: gavinandresen

Can you start a forum thread about this? There was some concern about possible attacks revealing private keys if the attacker can send arbitrary data to be signed.

khal

hero member

Activity: 540

Merit: 500

Pull request : https://github.com/bitcoin/bitcoin/pull/183

Adds two rpc commands :
- signmessage
- verifymessage

It allows to sign a message with the public key of a bitcoin address you own, to be sure of the identity of the sender.

Sign :

Code:

./bitcoind signmessage 1L5zqFahc8Ahu9wtgJqCeJMendvD174xsG "Hi github users :p"
{
   "address" : "1L5zqFahc8Ahu9wtgJqCeJMendvD174xsG",
   "pubkey" : "04ef6e366cd6b0b8fbf02c0c25ad39fe892b90c597875899fdc9db16941cf43fb8c429e0534cb8b972f5cc9f1a50f36dc3352ffad427f073e1c64a145828a3be6e",
   "sign" : "3046022100a80b6e0c7c54c54ba943f4e3cde12f5a7dc5313e3f0a15ce868f01683ced64fa0221008b4ad7d3800a11c241dcef7aaf44c8224a7d9f1e54d3e669bf4887036b6d10af"
}

Verify :

Code:

./bitcoind verifymessage "Hi github users :p"
{
"address" : "1L5zqFahc8Ahu9wtgJqCeJMendvD174xsG",
"pubkey" : "04ef6e366cd6b0b8fbf02c0c25ad39fe892b90c597875899fdc9db16941cf43fb8c429e0534cb8b972f5cc9f1a50f36dc3352ffad427f073e1c64a145828a3be6e"
}

An json error will be displayed if there was a problem, otherwise, it displays the bitcoin address associated with the public key used to sign the message.

This patch allows you, for example, to send message to your customer and to prove it really comes from you, by using the public and private keys associated with your bitcoin address.

Reviews and comments are welcomed, I don't know if all is used as it should.

Topic: [PULL] Sign and verify message with bitcoin address and public key - page 3. (Read 19744 times)