There are, broadly, two kinds of collisions. In the first kind, you can pick an arbitrary prefix P shared between the collision pair; the algorithm spits out a

There are, broadly, two kinds of collisions. In the first kind, you can pick an arbitrary prefix P shared between the collision pair; the algorithm spits out a pair of (essentially random) blocks of data C1, C2 in the middle that are different but yield the same hash value (H(P+C1) = H(P+C2)). In the second kind, you can pick two arbitrary (equal-length) prefixes P1, P2, and the algorithm outputs collision blocks C1, C2 such that H(P1+C1) = H(P2+C2). Because of the Merkle–Damgård construction common to MD5 and SHA-1, you can add arbitrary (equal) suffixes without affecting the collision. With the first kind, you don't have much control over the collision blocks, and the prefixes and suffixes have to be the same. This can still be useful - file formats can be carefully rigged so that the differences in the collision blocks are noticed somehow (e.g. misaligning length fields, changing testable field values, introducing different code). With MD5, these collisions take just seconds to compute; with SHA-1, the one known example (Shattered) took 2^63 hash evaluations to compute. With the second kind, you can do a lot more evil, since you can pick two completely arbitrary prefixes. This was abused (for example) to create a rogue CA certificate from an ordinary signed website cert. With MD5, this takes several hours with a good GPU and CPU; with SHA-1, it was previously thought to take around 2^77 evaluations - more than 16,000 times harder than the first type of attack. This paper describes a method that would take only 2^69 evaluations for the second kind of attack on SHA-1, only 64x harder than the first type (in the worst case). This would be feasible for a big institution like Google or a government. All of which reminds us that, yet again, SHA-1 deserves to be laid to rest.