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.
- 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.
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 ;)
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?