Published on: 2017-02-27T09:15:29+00:00
The failure of crypto primitives in Bitcoin has been a topic of discussion, but a recent paper only highlighted the problems without providing any solutions. While contingency plans are available on the wiki, they lack detail and should be carefully evaluated. The length and algorithm of hash output play a crucial role in collision resistance. SHA-0 was found to be insecure in 2004, and extensive research has been done on SHA-1. It has been observed that SHA-2 is more resistant to collisions compared to SHA-1. RIPEMD160 also requires analysis and consideration of potential attacks.Currently, Bitcoin uses RIPEMD160(SHA256(msg)), which may make creating collisions more difficult than using RIPEMD160 alone. In an email conversation, Pieter Wuille explains that collision attacks are typical hash function breaks, while reducing single-key address security requires a preimage attack. There was a mistake made by a participant in calculating the unit operation, with the correct number of times being 2.9*10^42 instead of the original estimate of 2.4*10^18.Concerns have been raised about the 80-bit collision attack, which only applies to jointly constructed addresses like multisig P2SH. However, there is less certainty regarding the comparison between SHA1 and RIPEMD. Pieter Wuille is checking his own numbers and can see a vector. If RIPEMD is weakened in any way, single-key transactions could become vulnerable.In discussions between Steve Davis and Pieter Wuille, alternatives to RIPEMD160 are explored. Pieter emphasizes the need for any alternative to avoid using the 160-bit hash function. One suggestion is to use [, OP_CHECKSIG] as an alternative, but Pieter clarifies that this wouldn't address the issue with multisig P2SH addresses where the 80-bit collision attack applies. He states that for single-key addresses, preimage security is relied upon, and RIPEMD160 provides more security than ECDSA signatures.An unknown sender suggests an alternative to using RIPEMD160 in Bitcoin transactions by reverting to OP_CHECKSIG or later versions. However, they express concerns about introducing new issues while trying to solve the original problem. The use of RIPEMD160 is justified for its convenience and compactness.Splitting bitcoins into multiple addresses could reduce the computational cost of attacking Bitcoin. Google recently announced the first SHA1 collision attack, which involved nine quintillion SHA1 computations. In comparison, the richest Bitcoin address contains 124,178 BTC. It is important to expose potential attacks so that mitigations can be developed, even if the computational costs limit their real-world impact. Deploying segwit's 256-bit digests is suggested as a response, as it is already fully coded and ready to deploy.Pieter Wuille suggests moving from 80-bit collision resistance to 128-bit collision resistance in Bitcoin. He outlines the requirements for any alternative proposal and notes that most of these requirements have already been met by segwit. Any alternative would only apply to wallets that adopt it. Steve Davis expresses concerns about the time it would take for segwit to reach critical mass and suggests exploring alternative approaches. However, Pieter points out that any alternative approach would require significant work similar to what has already been done for segwit, making it the most viable option.In a discussion on the bitcoin-dev mailing list, the security level of RIPEMD160(SHA256(msg)) in relation to Bitcoin addresses is debated. While collisions are possible, it is argued that they do not cause harm to the Bitcoin network itself. However, more complex contracts like P2SH 2-of-2 multisig can be vulnerable to collision attacks. A commit-reveal mitigation is mentioned as a potential solution.Another discussion on the bitcoin-dev mailing list focuses on whether 160-bit security is sufficient for collision resistance in Bitcoin. Some argue that RIPEMD-160 is not adequate and suggest exploring alternatives. The potential vulnerability of tree objects is highlighted, as they can be constructed with garbage data at the end that many review tools may not detect. Implementing a technique similar to the one used in the Tor protocol, where progressive hash operations are performed on objects and the intermediary hash state is kept, is suggested as a possible mitigation.The recent SHA1 collision attack on Git has implications for maintainers and third-party submissions. It can be exploited in practice, especially with binary files where reviewers may not detect garbage data at the end of a file. If the attack can be expanded to constrained character sets like Unicode or ASCII, it could pose an even greater problem. The attack involves preparing a pair of files with the same SHA1 hash, submitting a pull request with the "clean" version of the file, and then replacing it with the malicious version after the merge. This method raises significant security concerns, as many review tools cannot detect the presence of garbage data at the end of tree objects.
Updated on: 2023-08-01T19:38:33.391073+00:00