[kevincox]

> especially considering that almost every value in the system is sha2(sha2())

Why does this give a meaningful improvement? Is this just security through obscurity? Presumably if this had significant benifits sha2 would have been defined this way to start with right? Or is it just that other users will be broken before this "double strong" version so that you have more warning? But isn't shaw defined as a number of rounds anyways?

[RL_Quine]

It’s a historical thing people used to do for length extension attacks, but it’s irrelevant where it exists in bitcoin, for example as branches in a merkle tree where every input is of a fixed length (another hash). For Bitcoin a good portion of all the CPU time involved in verifying is just doing hashes of hashes, so it just is what it is.

It has the side effect of making some attacks where you need control of certain bytes of the input (see the md5 commission tool) harder because you’ve now got to find an exploit which makes it through both hashes.

[athrowaway3z]

'breaking' a hash can mean many different things. Among many others, two types of attacks are:

- a specific prefix/suffix data can be created to force a collision.

- A message of exactly N bytes can quickly create a collision.

Both attacks would be reported as a hash being broken. But its assumed to be unlikely that a well designed hash would have a flaw that breaks the hash in both ways. Keyword being assumed. But with good reason.

AFAIK sha has only been broken by a variable length suffix attack.

With sha2(sha2()) it would have to be broken both ways.

[copperx]

I'd love a mathematical explanation because my intuition also says it cannot be more secure.

[jabbany]

My guess is the grandparent refers to this kind of attack: https://en.wikipedia.org/wiki/Length_extension_attack

Basically, many cryptographic hashes support fixed-length hashes of variable message lengths by breaking the message into blocks, chaining their hashes* and taking the final hash.

The weakness here is if you know the length of a prefix and its hash, you can generate more valid hashes of messages that contain the unknown prefix but with custom suffixes. This is relevant if you use the hash for authentication (i.e. MAC) as it allows producing certain types of custom messages that would also validate.

However, this has largely been a non-issue for a long time now as it takes very little tweaking of the protocol (stuff being authenticated) to make adding suffixes useless. Double hashing is one such mitigation, because the outer hash is now working over a fixed size input, meaning to attack it you'd need to the signed message instead of just appending to it.

*: This approach of chaining hashes of blocks is also used in other contexts that you may be familiar with ;)