This is definitely a cool idea, but there could be potential issues if it is to be relied upon for long periods of time. If at any point in the future the hash algorithm used (SHA256 right now it seems) is found to be vulnerable then it could invalidate all past certifications. You don't really even need a full collision attack, a chosen prefix collision attack is enough to completely destroy the system's validity. MD5 is already vulnerable to chosen prefix attacks, maybe in 5 or 10 years SHA256 will be too...
Perhaps using a combination of different hash algorithms that we know are secure today to certify a file together would be a potential solution to the problem. It's not perfect, but at least this way all the algorithms used need to be compromised for the certification to break.
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.
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)
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
Comments
This is definitely a cool idea, but there could be potential issues if it is to be relied upon for long periods of time. If at any point in the future the hash algorithm used (SHA256 right now it seems) is found to be vulnerable then it could invalidate all past certifications. You don't really even need a full collision attack, a chosen prefix collision attack is enough to completely destroy the system's validity. MD5 is already vulnerable to chosen prefix attacks, maybe in 5 or 10 years SHA256 will be too...
Perhaps using a combination of different hash algorithms that we know are secure today to certify a file together would be a potential solution to the problem. It's not perfect, but at least this way all the algorithms used need to be compromised for the certification to break.
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:
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