Also wouldn't an n-tuple of multiple hash methods and the file size be even more impossible to replicate than a single hash, but not be that much harder to generate initially?
You publish the hash in advance, and after elections you only publish the right PDF file, thereby "proving" your clairvoyance.
More seriously: You can get a notary (e.g. Microsoft Authenticode) to sign one file, and then provide another with the same hash.
For now, it only helps you with planned fraud, not after-the-fact forgery.
> It takes about half an hour on average on a standard PC to find a collision.
That's not a whole lot of time.
Edit: it really does work, too:
$ md5 msg[12].txt
MD5 (msg1.txt) = bd1ba334fdd5bf3836b9b8c4bfebae16
MD5 (msg2.txt) = bd1ba334fdd5bf3836b9b8c4bfebae16
$ openssl sha1 msg[12].txt
SHA1(msg1.txt)= fd5bb8044dc51ab2deef608fabf3b7dcb7a84c17
SHA1(msg2.txt)= 7d490719b22f9a0e365e4fab4e3ab551b4a8898e
For example, PGP v4 Key IDs are a subset of PGP v4 Key Fingerprints. PGP v4 Key Fingerprints are SHA1 hashes of some protocol information and the key material (for more detailed information see RFC4880 section 12.2). So, a proper collision, with other properly constructed packets, could yield two seemingly "identical" keys. Therefor, they may be able to produce a fake PGP key that you think belongs to a person you trust and want to communicate privately with but actually does not.
Hash function collisions can be similarly exploited with digital certificate protocols (like SSL web certs). So, a crime syndicate may be able (depending upon how badly certain hash functions are broken) to produce a fake SSL certificate for your bank's website that your browser thinks in valid. Or even worse, they may be able to produce a fake root CA singing certificate that your browser thinks is valid.
It's more complex than just "can compute hash collisions = fake certs" because there's a very limited amount of information hashed in both certs and PGP keys. The more data that is hashed the easier it is to find a collision. With PGP much of the data has to be very specific like version and algorithm designation flags and valid cryptographic values for the algorithm designated. It's safe to say "very limited flexible data = very difficult to find a collision".
Therefor, these calculations are interesting and do suggest that everyone should move away from using SHA1. But, the calculations to determine when a criminal or an anti-sec use case would be possible are much more complex and involve many more variables.
Does the collision attacker get a hash of something used for security, and then look for another input that returns the same hash? Isn't it possible that they found the original input? Why is it important that its a collision?
There are a wide array of attacks. Using the method just described and the existence of a hash collision to fake a signature, rather than a key pair, in some cases can be much easier. Depending upon the protocol and procedures used, it may also be possible to use a different method such as providing the true authorized signer with any content that shares a collision with something you'd like the authorized signer to sign (but that they would not normally sign). This can be especially true when the signing procedure is fully automated (For example, some CA's SSL certificate acquisition process is fully automated).
The reason that the collision is important is because many cryptosystem implementations (and humans of course) use hashes as unique identifiers of key pair material (PGP Keys & PKI certs).
That's what I'm wonder at the value for.
Otherwise your're totally accurate.