[closed]Bitcoin client "Sign Message" box issue

[Xenland]

I am referring to the following link (scroll down to the bottom) https://github.com/bitcoin/bitcoin/issues/2132

If you open up the "sign message" box dialogue you will see that the box advises users "Only sign fully detailed statements that you agree too" how ever a contributing developer has advised for users to sign sha256 digests, this is counter-intuitive it leads users open to sign just about anything. so...

How do we promote users "Not to sign anything vague" when we are promoting them to sign digests. Which to any users is just a string of random letters and numbers; It doesn’t mean a thing to a non-technical person. I realise that sha256 doesn’t have any (known or mathematically computed) collisions but to a non-technical person that doesn’t mean anything, so with this social engineering flaw in mind we can assume any joe-shmoe can invent his own "predictable digest" or even just provide a base64 encoding of the message the non-technical user wouldn't know a thing of the difference and could agree to things they are unaware of.

[gmaxwell]

Because you sign a digest that you created yourself, of course.  This was apparent to me, but I can see how it would be apparent to other people.  If you can suggest a clear way to explain that I'm all ears.   The risk of concern is that you should actually understand what you're signing and why.

I'd consider the risk of someone being talked into signing something with an insecure digest to be very small and if you think through a specific example you'll see why... For example. I trick you into signing something with an insecure digest. Then later I show up and demand specific performance based on a substituted contract. You would refuse and point out the weak digest (which you would discover after the fact). No real harm except the wasted time. So the only risk I'm aware of is from some service setting up and using a weak digest for automated authentication— but in that case the attacker doesn't select the digest.

— Also, why are we splitting this discussion into two places? it probably would have been better for you to comment on the issue.

[Xenland]

I had to cancel a project because at the time I could not think of a solution (So I'm saying In my experience this is a REAL issue) but in the past I have asked users to sign a contract that contained \n\r and other non-ascii characters so when they copy the proposed contract from a website they don't get the non-ascii characters making the signature invalid when the website verifies it. That's the real gravity of the issue.

The reason why I split the discussion is because I can't explain everything with out questions and with lack of questions my point wont be conveyed -- its the only way I can properly communicate this issue is with question asking but I think I just now got it all out.

[Xenland]

Digests aside the point is we are advising non-techinicals to sign "random letters and numbers" which could lead to legally binding contract. In a legally binding contract, You can't just say "I didn't know i signed a bad contract" when your signature is there. The law will say... welp prove that you didn't know.

[Xenland]

So to recap I see that there are a few problems with signing messages with the current advisory instructions for non-technical users.
(please remember I'm strictly speaking from my experiences when I attempted to make a contracting website a few months ago)

* (Social Engineering) Possibly signing of contract that isn't the actual contract
Non technical users WILL NOT make their own digests them selves nor will they know why they have to make their own or care too, they will ALWAYS make the company,website,etc provide the digest as they don't know the problems it could make for them and they don't have the time to care and find out.

* Its difficult to sign a contract with new lines with out displaying the whole contract on a one line input box through a website
Providing a user with a contract to sign is difficult through any interface as the problem of non-ascii characters such as \n or \r (newlines) or other formatting characters can NOT be copied and pasted they must be copied into the clipboard leading to vulnerabilities "injection" issues.

*Small issue: The sign message digest output isn't labelled I can't instruct my users to "Copy that one box at the bottom in the sign message dialogue" instead there should be a label saying "Digest" so I can instruct my users on my website to "Copy the box that is labled digest and paste it into the website here" Link for this small issue: https://github.com/bitcoin/bitcoin/issues/2144

[Xenland]

DeathAndTaxes gets it: https://bitcointalk.org/index.php?topic=134360.msg1431089#msg1431089

[Xenland]

So my proposal would have to be included into the "Sign Message" dialogue, as users will be required to copy the message into the Bitcoin client and select the appropriate encoding(or hash digest) and then sign that encoding/hash and then the user can copy the output as they can trust their Bitcoin client.

BUT the problem remains with the copy and pasting of non-ascii characters like newlines and returnlines and other formatting characters that are not ascii.

[gmaxwell]

DeathAndTaxes gets it: https://bitcointalk.org/index.php?topic=134360.msg1431089#msg1431089

He does, but for some reason I think you do not. What I was saying is entirely compatible with what deathandtaxes is saying and I don't know how I'm failing to express it in order to make it clear to you. Perhaps someone else can help?

"Sign a digest that you created" is not the same as "sign an opaque string that you have no comprehension of".

[Xenland]

DeathAndTaxes gets it: https://bitcointalk.org/index.php?topic=134360.msg1431089#msg1431089

He does, but for some reason I think you do not. What I was saying is entirely compatible with what deathandtaxes is saying and I don't know how I'm failing to express it in order to make it clear to you. Perhaps someone else can help?

"Sign a digest that you created" is not the same as "sign an opaque string that you have no comprehension of".

I'm strictly talking about non-technical users. Of course a technical user can know how to make his own digest and of course this is not an issue, there is a reason why I’ve OVER emphasised using the word non-technical users in all my posts. I choose my words carefully, BUT this new information may not change a thing so please respond to let me know that I should reread your posts further and I'll try to stay opened minded as possible.

[gmaxwell]

I'm strictly talking about non-technical users. Of course a technical user can know how to make his own digest and of course this is not an issue, there is a reason why I’ve OVER emphasised using the word non-technical users in all my posts. I choose my words carefully, BUT this new information may not change a thing so please respond to let me know that I should reread your posts further and I'll try to stay opened minded as possible.

Yes, I've read your many message.  Making the signing process more opaque and risky does not help non-technical users or technical ones. What exactly do you want to accomplish?

[Xenland]

I'm strictly talking about non-technical users. Of course a technical user can know how to make his own digest and of course this is not an issue, there is a reason why I’ve OVER emphasised using the word non-technical users in all my posts. I choose my words carefully, BUT this new information may not change a thing so please respond to let me know that I should reread your posts further and I'll try to stay opened minded as possible.

Yes, I've read your many message.  Making the signing process more opaque and risky does not help non-technical users or technical ones. What exactly do you want to accomplish?

Gmaxwell is advising for users to sign digests (reffering to the github issues page suggestion), while the Bitcoin client advises NOT to sign anything vague.

So the solution is for users to copy and paste the contract and create the required digest(lets just say sha256 to keep the example simple).
So the non-technical user is following a "how to sign messages" guide and is advised to Copy and pastes the contract into a sh256 digest. So the user copies the sha256 digest and pastes it into the website.

The website attempts to verify the signature with the contract and it doesn’t work? OH why not? it doesn’t work because the contract contained formatting, this formatting isn't non ascii

The Current solution?
*We provide a download link of the contract so the non-technical user can sha256 correctly that way( non-technical and technical users don't like downloading stuff from websites as it could contain viruses but this isn't a huge problem for technical users)

*OR we provide a one-line input box (The issue with this is a one liner contract that is 5000 characters long isn't easy on the eyes)

The current Problem?
The download link solution aside I will discuss the one-line input box dilemma, In order for anyone to read a 5000 character contract they will not scroll the one box line as they need to read, NOR will they copy the one line box and format it them selves in notepad just to make it easy on the eyes. So the website as a convince provides an easy to read format and a one box line but the issue with this is that the website could provide the easy to read format a "good looking on the eyes and the wallet contract" but the one liner could provide a "bad looking contract" the user is forced to sign the one liner because we can't sign the formatted nice looking contract. So the non-techincal user reads the how to guide and is instructed to copy the "bad contract" one liner and sha256 digest it and then sign the digest and then copy the digest and paste it into the website.

We need a way to encode the messages with in bitcoin if the great gmaxwell still doesn’t understand I will have to make a demonstration video because I know this is an issue as I'm dealing with right now as a social engineering flaw and I had to cancel a project (not blaming anyone as fault But this IS an issue if bitcoin wants to use contract signing as "feature)
Or perhaps my solution isn't a great solution but there IS a problem.....

[DannyHamilton]

. . .The website attempts to verify the signature with the contract and it doesn’t work? OH why not? it doesn’t work because the contract contained formatting, this formatting isn't non ascii. . .

I'm not sure, but it seems that you have a couple of opportunities for handling this.

You could create contracts for the website that don't include formatting that affects the digest.  This way the copy/paste will create the exact same digest as the digest that the website verifies against.

You could create multiple digests for the website with/without formattting.  Then as long as the user submits a signed digest that matches any one of the "recognized" digests, your website could accept the signature.

[grue]

is there a reason why signed messages can't contain newlines?

[Xenland]

is there a reason why signed messages can't contain newlines?

I believe it can just ONLY through the command line but the issue is non-techie users so its presumed they will use the GUI interface which doesn't recognize new lines and formatting correctly.

So essentially a website will check the signature as the message with newlines and formatting while the GUI on the client side signs differently and will not validate on the website end.

[Xenland]

Which hash do you think a Non-technical user will pick?
http://www.youtube.com/watch?v=TOP6gXidRLU&feature=youtu.be

If you think the formatted one -- its impossible for that to match as the formatting characters wont work
if you think the non-formatted one then yes becuase its the path of least resistance  the only one that would website would "accept" as valid, In my opinion you are correct.

I'll drop it after if this video doesn't explain it but if you want a realworld example for you to play with check out my WOTCoin project that will show you that there is a problem with multi-lines and formatted texts https://github.com/Xenland/WOTCoin

All i know is that if someone explains this differently in about a year or so when people start to heavily use the "sign message" box and someone else gets the credit I'll be very upset but w/e -- Aslong as Bitcoin improves what ever it takes for how ever long it takes to bash the issue it will succeed I just hope non-techies aren't hashing evil contracts and signing their lives away before it is realised. Just remember that "theory" ISN"T "Practicality" Good day mates

[gmaxwell]

Gmaxwell is advising for users to sign digests (reffering to the github issues page suggestion), while the Bitcoin client advises NOT to sign anything vague.

I believe the not vague thing was at my insistence too. These are not contradictory recommendations and I'm at a loss as to why we can't seem to communicate on that point.

[Xenland]

Gmaxwell is advising for users to sign digests (reffering to the github issues page suggestion), while the Bitcoin client advises NOT to sign anything vague.

I believe the not vague thing was at my insistence too. These are not contradictory recommendations and I'm at a loss as to why we can't seem to communicate on that point.

The issue was deffinatly mine due to me thinking I set my encoding correctly(referring to UTF8) this is what i thought was happening on my site

*User proposes contract text to other user by submitting contract to website
this proccess looks like this....

Textbox -> website php proccessing -> mysql database

I found out my database and the website were mismatching encodings one was UTF8 and the database was accidentally set to something other then UTF8 (i think it was some other unicode)

So when the other person agrees and wants to sign the contract they are presented with a textbox in UTF8 encoding but supplied from non utf8 encoding from the mysql database and I believe essentially that when clipboard copies the text to the Bitcoin client it isn't UTF8 as expected and thus the Bitcoin client signs a valid message and when the website goes to check the validity it isn't valid becuase of the encoding mismatches.

I think my end seems to be working now that I have consistent encoding, I hope (or its just a fluke)