8
$\begingroup$

So I was just curious.

I really look up to Blockchain technology and I have read that Bitcoin uses double SHA-256 for hashing.

( from what I understood, double sha256 is essentially $\operatorname{SHA-256}(\operatorname{SHA256}(value))$ ).

Is double SHA-256 better than SHA-512 or any other hashing algorithm that bitcoin could use? Or maybe there are other alternatives that could bring some benefits over the double SHA-256 for bitcoin?

$\endgroup$
15
$\begingroup$

Since the initial release of Bitcoin is 9 January 2009, the designer had these NIST hash functions (NIST-FIPS 180-4) as available options: SHA-1( 1995), SHA-256 (2001), SHA-512 (2001), and some more.

The main difference between SHA-256 and SHA-512 is the target CPU. SHA-256 is designed for 32-bit CPUs and SHA-512 is designed for 64-bit CPUs. That makes a huge difference in the target CPUs.

One can argue that the designer wanted protection against the length extension attacks. However, SHA-512/256, which has the same pre-image, secondary-preimage, and collision resistance as SHA256, is secure against length extension attacks. Though not officially available at that time, simply trimming the 256 bit from the output of SHA-512 is the countermeasure. The knowledge was there since SHA-384 (2001) was available and it is trimmed from SHA-512 with different initial values for domain seperation *.

The obvious choice can be considered as the speed. SHA512, according to the Blake2 site, is 50% faster than SHA-256. SHA-1 is 2-times faster than SHA-256. However, the output size of SHA-1 is 160 bit and can be considered small for security during 2009 and for the mining space.

Another parameter for the choice of 256-bit is that Bitcoin used ECDSA-SHA-256 signatures. The obvious choice for hashing the message is using SHA-256.

Therefore, we can conclude that the designer didn't want fast mining, compatible with the ECDSA-SHA-256 signature so choose the $\operatorname{SHA-256}$ and, to prevent length extension attacks, selected double hashing. The double hashing is invented by Ferguson and Schneier in their book Practical Cryptography to countermeasure against length extension attacks.


As a side note, double-hashing doesn't prevent collision attacks since any collision $\operatorname{SHA256}(x)=\operatorname{SHA256}(y)$ is also a collision for $$\operatorname{SHA256}(\operatorname{SHA256}(x))=\operatorname{SHA256}(\operatorname{SHA256}(y)).$$


*In academics, the first occurence the trimming as a countermeasure againt the length extension attack goes back to 1995

$\endgroup$
5
  • $\begingroup$ I wonder how collisions could be eliminated if that's what's missing from the puzzle.. $\endgroup$ – Pinkovai Krisztian Jan 8 at 23:17
  • 1
    $\begingroup$ Optimizing for speed in a proof-of-work setup is kind of silly. $\endgroup$ – Simon Richter Jan 9 at 12:44
  • $\begingroup$ @SimonRichter The proof is easy just double hash, however, it can increase the race-attackers cost by double. Also, Satoshi may want to use it for the signature, too, instead of using many hash functions around. $\endgroup$ – kelalaka Jan 9 at 13:07
  • 2
    $\begingroup$ "In March 2012, the standard was updated in FIPS PUB 180-4, adding the hash functions SHA-512/224 and SHA-512/256, and describing a method for generating initial values for truncated versions of SHA-512." -- en.wikipedia.org/wiki/SHA-2#Hash_standard $\endgroup$ – Nayuki Jan 9 at 16:47
  • $\begingroup$ @Nayuki yes, my mistake. I need an updated, thanks, $\endgroup$ – kelalaka Jan 9 at 17:04
7
$\begingroup$

Comparing double sha256 to sha512 is like comparing apples to oranges. For one, the result of sha512 is 512 bits in length. The result of double sha256 (or triple sha256, or quadruple sha256, for that matter) is 256 bits in length.

There has been a lot of conjecture over the years as to why the creator of bitcoin chose to use double sha256 in the protocol. One theory is that it was done to mitigate length-extension attacks. For more info, see https://bitcoin.stackexchange.com/questions/6037/why-are-hashes-in-the-bitcoin-protocol-typically-computed-twice-double-computed.

$\endgroup$
5
  • $\begingroup$ I understand. So if we look at the result length of 256bits, is sha256 a clear winner over let's say BLAKE, GOST or HAVAL, right? $\endgroup$ – Pinkovai Krisztian Jan 8 at 21:24
  • 1
    $\begingroup$ @PinkovaiKrisztian Please don't ask follow-up questions in the comments. Besides, your question might be better suited for Cryptography $\endgroup$ – MechMK1 Jan 8 at 21:42
  • 7
    $\begingroup$ Think of bitcoin as a massive bug bounty for sha256. sha256 is used extensively throughout the bitcoin protocol. If a bad actor were to find a vulnerability in sha256, they could use it to launch a 51% attack, double-spend coins, or steal other people's bitcoins. At $40,000 USD / bitocin, these would all be very lucrative. But, to date, nobody has found a bug and claimed the bounty. $\endgroup$ – mti2935 Jan 8 at 21:48
  • $\begingroup$ Thank you @MechMK1 for your observation. I didn't know about that. Glad you informed me. $\endgroup$ – Pinkovai Krisztian Jan 8 at 23:04
  • $\begingroup$ Thank you @mti2935 for your time and responses! Have a nice one! $\endgroup$ – Pinkovai Krisztian Jan 8 at 23:04
5
$\begingroup$

The typical reason one uses double hashing is to deal with length-extension attacks. That's because any Merkle-Dåmgard algorithm that outputs its entire state (e.g., SHA-1, SHA-256, and SHA-512) is vulnerable to a length extension attack, where users who know a hash can append additional data and also produce a valid hash.

There are other algorithms, such as SHA-3 and BLAKE2, which don't have this problem because they use a different construction. SHA-3 uses a large state and outputs only a portion, while BLAKE2 modifies the input data of the last block processed to distinguish it. A design lacking this problem is preferable these days.

However, those algorithms didn't exist at the time Bitcoin was created (2008), and SHA-256 was the standard hash algorithm to use for secure contexts, even though it has this weakness.

Whether an algorithm is "better" in a context depends on one's needs. Presently, if one needs security against length extension attacks, one chooses SHA-3 or BLAKE2. If one needs performance, one uses BLAKE2 or SHA-256 (if accelerated on the relevant hardware). If one needs compliance, one uses SHA-2 or SHA-3. There are many criteria to consider.

In the context of when the design was made, the choice was probably responsible and defensible and was the best that could be done under the circumstances, even if we would prefer a different algorithms today (because we have better ones available). Since SHA-256 is presently considered secure and robust, there's little reason to change right now. If in the future that changes, then using a different algorithm may be warranted.

$\endgroup$
6
  • 1
    $\begingroup$ The BLAKE2 hash function, based on BLAKE, was announced in 2012. and SHA3 in 2015. The designer had no such option in the initial release of Bitcoin in 2009! $\endgroup$ – kelalaka Jan 8 at 23:02
  • $\begingroup$ Exactly. That's why I put that in the third paragraph. $\endgroup$ – bk2204 Jan 8 at 23:08
  • $\begingroup$ @bk2204 maybe later quantum computing will force the developers / maintainers to switch to a better one. Nicely explained, thank you! $\endgroup$ – Pinkovai Krisztian Jan 8 at 23:11
  • $\begingroup$ @PinkovaiKrisztian Quantum computing is not a threat to hash algorithms like that. $\endgroup$ – forest Jan 9 at 23:11
  • 1
    $\begingroup$ @PinkovaiKrisztian Quantum computers can effectively run quantum algorithms. The main ones relevant to cryptography are Shor's algorithm and Grover's algorithm. Shor's algorithm can break ciphers like RSA extremely quickly, rendering it useless. Grover's algorithm, which works against symmetric ciphers and hashes, simply cuts the effective bit size in half, and furthermore can't be parallelized well, so it's not nearly as much of a risk. $\endgroup$ – forest Jan 10 at 22:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.