Trust in Smart Contracts

Both electronic and paper documents are subject to tampering. The discovery of collisions has demonstrated that the process of signing a hash signature is not without its own vulnerabilities. In fact, the collision allows two versions of the document to be created with the same hash and thus same electronic signature. For now, SHA256 is considered secure, but, not all hash functions are.

It was said in a response to an earlier post that “Electronic contracts do not have to be re-read when they are returned because there’s generally no mechanism (unless it’s built into the electronic process) to alter the contract terms, scratch out a line, insert text, etc. What you send is what is being signed.”

Unfortunately this is not true.

An attacker could generate two documents. One says:
Sell at $500,000.00 (Order 1)

The second document says:
Sell at $1,000,000.00 (Order 2)

Our attacker wants to have the second document as the one that is signed. By doing this they have increased the sale contract by $500,000.

Confoo is a tool that has been used to demonstrate two web pages that look different, but have the same MD5 hash (and there are also issues with other hash algorithms too).

Digital signatures typically work using public key crypto. The document is signed using the private key of the signer. The public key is used for verification of the signature. The issue is that public key crypto is slow. So rather then signing the entire document, a hash of the document is signed. As long as the hash is trusted, the document is trusted. The concern is that collisions exist.

So back to the issue. Our attacker takes order 1 and order 2, and uses the Confoo techniques (also have a look at Stripwire).

The client is sent a document that reads as “Order 1”, and they agree to buy a product for $500,000. As such, they sign the order using an MD5 hash that is encrypted with the buyer’s private key. Our attacker (using Confoo style techniques) has set up a document with a collision. Order 1 and Order 2 both have the same hash.

Our attacker can substitute the orders, and the signed document (that is a verified hash) will still verify as being signed.

The ability of Microsoft Word to run macros and code makes it a relatively simple attack to create a collision in this manner.

So, electronic documents do need to be re-read — but it is simpler in that there are tools to verify these. Ensure that the hash used is trusted, and even use multiple hashes together.

For most use cases in P2SH in Bitcoin today, there are no issues. But, always look at the time frames of contracts. For small or low-value transactions, P2SH poses low risk for the foreseeable future, but the nature and design of P2SH allow for a number of attacks that become easier every year.

Consider risk when thinking about security and value, and remember, long term contracts work best when completed natively in script. The most secure use of a Bitcoin transaction is to create a script and to send this. The reality is that anything that can be run in P2SH can be run without P2SH — more securely. The imposition of non-standard scripts has been used to (falsely) block many use cases from Bitcoin (as others seek to have side chains, altcoins, etc.)

SHA256(SHA256) vs RIPEMD160(SHA256)

If P2SH had used a 256 bit hash, it would have still been a bad addition for all the wrong reasons, but it would have many more years before it could be attacked. P2SH likely has a decade of security, but, seeing that some contracts need to last several, it is time to ask why it is used or needed.

The fact is, P2SH was never necessary, and though it is a part of Bitcoin now, it is one I recommend people to avoid. Native scripting is better than P2SH, and it is time to end the fallacy that it helps with scaling. Bitcoin scales now.

This is why SV Pool and CoinGeek (and Bitcoin SV) plan to start processing non-standard scripts. To us, your long-term security matters. Non-standard scripts are processed in P2SH. The myth was that this is bad for nodes, but, this is again the myth of the Raspberry Pi. Miners are competitive. They fight to be paid. They are paid more for larger scripts, so this is not an attack, it is the market at work.

The market is not the speculators and the traders flipping coins, it is the producers and consumers. This false myth that the market is the speculators is the myth that adds to the socialist idea of “dog-eat-dog” competition. In market-based capitalism, the company that delivers that best productivity gains wins. That company without the ability to keep up, it loses. These balancing forces are the market.

The market forces less productive members out. Those who cannot handle the level of increasing demand and competition are left behind. As they are, the level of profit increases, attracting others who can compete more effectively and with improved efficiencies. Rather than adding foolish changes, we should be allowing businesses to compete.

This is why locking the protocol matters.

Further Reading:
http://www.doxpara.com/slides/Black%20Ops%20of%20TCP2005_Japan.ppt

Tech aside.
This attack works due to the nature of hashing algorithms (in this case, a flaw in the now depreciated algorithm MD5). If you have 2 documents, x and y, that have the same hash (i.e. a collision), then appending an additional block of information q to the documents will also result in a collision. This is (x+q) will have the same hash as (y+q).