US kicks off secure hash competition

I have got one that doesn't crash

Just encrypt the file and use that as the key!

Come on these crashes are just mathematically inevitable, if you read the link to these 'practical attacks' in the OP :) and you read to the bottom you will see the statement:

'If data can be added to a file (software update or email message) so that the modified message is intelligible and matches the hash of the original message then the impact would be devastating. Things are nowhere near as serious as that.'

The crash will happen by the sheer definition of hashing (it wasn't originally intended for security). So yeah whilst this is probably a good thing to draw out new ideas, it is not exactly needed.

Re: is it really much of a problem?

yes, perhaps a human readable document is a bad example but executables aren't:

http://www.mathstat.dal.ca/~selinger/md5collision/

@ Chris Richards

As understand that link it's saying that an attacker could produce two programs or postcript files with arbitrarily different behaviour but the same hash. But from my reading of it they couldn't produce an arbitrary file with the same hash as somebody else's program or file. So presumably they still couldn't forge an existing document or program.

@Christoph

If that was some distribution of a open source project in binary format than it's perfectly simple to carry out their scheme (obviously the smaller the project the easier!) and distribute an 'evilised' binary with the same hash.

But obviously now the republicans are (soon to be) out of the whitehouse there is no evil left in the world, so we needed worry :)

Ohhh come on

the md5 attack shown from the link, doesn't actually use a simple natural hello.exe.

Both the hello.exe and the erase.exe are engineered together.

If only the erase.exe was engineered there would be a problem, but that is not the case.

So yeah there is a vector, but it would be a lot of odd things that would have to happen to create it.

And as to encryption :) Well I didn't want to make it too obvious, but if the author signs via his private key, and you use his public key to check. That is a better position to be in, as you really trusting the author, not the code. Combining all these methods is a good idea, add in encryption via your public key, and a quick check of the source code, and your security is on the up again.

As to documents saying one thing, with a character change or three (not) that is part of a good hashing algorithm for security anyhow, it should make a huge change in the resulting hash if only one character is changed, and they all currently exhibit that.

Collisions of course occur because the hash is smaller than the data it is representing, much smaller :). So, it is about permutations and length of hash more often than not..

These competitions are a good thing, but they are more about bringing on the field of security as a whole, than creating the next hashing star.

There are four documents

A and B originally

A, B -> A`, B`

A` and B` after engineer.

The ` docs look engineered, that's the tell tale, you start to distribute A` people know you are up to no good.

Sure there is a vector of attack, but you cannot really rely on hashing alone anyhow, it is just one of many checks to ensure the validity. I would be kind of worried about hunky dory being no one looks at the source code or generates their own compiled code, at that point why bother with engineering the hash, just payload in unchecked code.

Now if you can do A, B -> A, B` there is a problem.