The primary use case is identity fraud in financial transactions, software distribution, or in private communications.
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?
Yes. But, they look for another input that has the same hash and for which they also have other secret information. For example, a PGP public key with the same hash (Fingerprint) for which they have a valid private key thereby affording them a working "collision" key pair. Obviously, very difficult.
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).
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.