Collisions are a problem if you want to corrupt data, not if you specifically want a human validate it in a single document.

E.g.:

I claim that I authored the string "foo bar" with hash "1f2ec52b7743687..".

Now you find a collision and go to court arguing:

>> Your honor, but "3HSSHog*8FF9 z!!!!ady94765&$^#" also has the same hash!

I think the court will still assume that "foo bar" is the correct original, not the garbled collision data you produce. And you still can't deny that the original produces the correct hash.

That's not why it would be a problem.

The problem is that I can author "foo bar" and "moo bar" constructed to hash the same, and then assert retroactively which one I meant. While collisions are likely to have random binary garbage in them, it may not matter - I am on phone now, but IIRC I have two PDFs on my desktop that have the same MD5, one of which viewed is an airbus pamphlet, the other being a Boeing one. (created by Dan Kaminski, IIRC)

Can we see them?

I guess they are on a backup or misremembered - but examples are really easy to find on the net if you want them:

http://th.informatik.uni-mannheim.de/people/lucks/HashCollis...

http://www.win.tue.nl/hashclash/ChosenPrefixCollisions/ has a multicollision: 12 PDF files with different content and the same MD5 hash.

an application of each once? Btw my crypto is weak, but do answer this. if i apply a hash algorithm on something, it outputs a relatively small number of bytes. Correct me if i am wrong but the strength of the hash lies in the fact that the input space is vastly huge so its difficult to create an input-output mapping for reversing the hash. Now if we use one hash over another, aren't we restricting the input space of the 2nd hash? Wouldn't that make it easier to crack the 2nd hash for this particular usage? And if my above statements are correct then the strength of sch a mechanism only lies in the strength of the first algorithm