6 ms·

Your post is a good example for why cascades are so dangerous. hash1(hash2(...)) is not as secure as the stronger of the hash functions, it may only be as secu

Your post is a good example for why cascades are so dangerous. hash1(hash2(...)) is not as secure as the stronger of the hash functions, it may only be as secure as the weaker of the hash functions. Your example is sha1(md5(...)). Well, md5 is no longer considered collision-resistant, which means that sha1(md5(...)) also isn't collision-resistant. If you're able to obtain two different inputs that are mapped to the same hash by md5, computing the sha1 of that hash is still going to lead to the same value, i.e. a collision overall. So your assumption that an attacker must defeat both is clearly wrong and dangerous. In the case of hash functions, I believe it would be safe two concatenate the hashes (instead of composing the functions), but now you have a bigger hash size in addition to a slower running time.

richardwhiuk 11y ago
I'm not convinced that concatenating hashes is safer than a single hash function either. Let's say you have an entirely broken hash function for which hash(A) = A. Clearly if you cocatenate hash(A) + sha256(A), you still end up with something is broken. I think if you concatenate the hash function, you may well end up with something which is strictly worse than using either hash function (as breaking one will break both). Also, if you have the result of both hash functions, then you may have provided data which warps the probability chart, as you now have much more information on the output state of the data, which isn't combined in a clearly useful way. Their might be a way to combine two hashes in a way which does preserve the properties of a hash function, but I think it would be significantly tricky that you would have essentially created a new hash function using other hash functions as building blocks. (That might be good grounds for generating a hash function resistant to attack - combine multiple different styles of hashing, but it doesn't seem to be common when hash functions are designed which suggest to me there are fundamental problems. (e.g. most hash functions repeat the same functional blocks, rather than having a large selection of different blocks).)
- leni536 11y ago
  > Clearly if you cocatenate hash(A) + sha256(A), you still end up with something is broken. Now it could depend on your treat model. You want to hash passwords (A is secret)? If yes, then this is broken. You want an integrity check / tamper resistance on A, but A is public (see git)? Then this could be fine. Correct me if I'm wrong.
Estragon 11y ago
f(X)=sha1(concat(md5(X), X)), then.
- woodman 11y ago
  What you have in that case is a 128-bit prefix with, last I heard, less than 60 bits of security - due to md5 being so broken. Now the attacker can start the first round of sha1 with a massively reduced number of potential permutations. That isn't a problem for sha1 today, but if it is tomorrow - then you are much worse off then you would have been just feeding sha1 your plaintext. The benefit of the additional computational complexity is pretty small, and not worth the additional potential point of failure.

richardwhiuk 11y ago

I'm not convinced that concatenating hashes is safer than a single hash function either. Let's say you have an entirely broken hash function for which hash(A) = A. Clearly if you cocatenate hash(A) + sha256(A), you still end up with something is broken. I think if you concatenate the hash function, you may well end up with something which is strictly worse than using either hash function (as breaking one will break both). Also, if you have the result of both hash functions, then you may have provided data which warps the probability chart, as you now have much more information on the output state of the data, which isn't combined in a clearly useful way. Their might be a way to combine two hashes in a way which does preserve the properties of a hash function, but I think it would be significantly tricky that you would have essentially created a new hash function using other hash functions as building blocks. (That might be good grounds for generating a hash function resistant to attack - combine multiple different styles of hashing, but it doesn't seem to be common when hash functions are designed which suggest to me there are fundamental problems. (e.g. most hash functions repeat the same functional blocks, rather than having a large selection of different blocks).)

leni536 11y ago
> Clearly if you cocatenate hash(A) + sha256(A), you still end up with something is broken. Now it could depend on your treat model. You want to hash passwords (A is secret)? If yes, then this is broken. You want an integrity check / tamper resistance on A, but A is public (see git)? Then this could be fine. Correct me if I'm wrong.

Estragon 11y ago

f(X)=sha1(concat(md5(X), X)), then.

woodman 11y ago
What you have in that case is a 128-bit prefix with, last I heard, less than 60 bits of security - due to md5 being so broken. Now the attacker can start the first round of sha1 with a massively reduced number of potential permutations. That isn't a problem for sha1 today, but if it is tomorrow - then you are much worse off then you would have been just feeding sha1 your plaintext. The benefit of the additional computational complexity is pretty small, and not worth the additional potential point of failure.