What would be the usefulness of a pure collision attack where you have no control over $m$ or $m'$?
One example is when $m$ and $m'$ are or contain randomly selected material. If they're using cryptography correctly, the honest parties generally choose keys, random IVs or similar material randomly, and thus have no control over what their values are either. This affords many opportunities for attacks that require finding some collision but don't care about what the colliding values are.
One example is secure coin tossing. If Alice is calling the toss and Bob is throwing it, they execute this protocol:
- Alice secretly picks her
Tails) for the toss, and a sufficiently large random
- Alice computes
commitment = hash(salt || call);
- Alice sends
commitment to Bob.
- Bob tosses a coin, gets
- Bob sends
outcome to Alice;
- Alice sends
salt to Bob;
- Bob verifies that
commitment = hash(salt || call). If it checks out, Bob knows Alice didn't cheat.
outcome = call then Alice won the coin toss, otherwise she lost.
If Alice can find any pair of salts such that
hash(salt1 || Heads) = hash(salt2 || Tails), then she can break the protocol. It doesn't matter what the values of
salt2 are as long as they lead to a collision in this context.
So collision resistance implies Alice can't cheat this protocol.
To address Ross Snider's answer you linked from another SE site. I'll boldface one really important bit:
Bob can use a collision attack to his advantage in many ways. Here is one of the simpliest: Bob finds a collision between two binaries $b$ and $b′$ ($H(b)=H(b′)$) such that $b$ is a valid Microsoft Windows security patch and $b′$ is malware. (Bob works for Windows). Bob sends his security patch up the chain of command, where behind a vault they sign the code and ship the binary to Windows users around the world to fix a flaw. Bob can now contact and infect all Windows computers around the world with $b′$ and the signature that Microsoft computed for $b$.
But to me that seems to be a 2nd pre-image attack, not a pure collision attack, because the attacker needs to ensure that the hash of the malware matches a particular hash, i.e. that of the Windows update.
It is a collision attack indeed, not a second preimage attack, and it hinges on these points:
- "Bob works for Windows." This may be a parenthetical in the quote, but it is a critical assumption. The scenario assumes (perhaps less than explicitly) that Bob is the author of both the legitimate patch and the malware, and gets to craft them together as a colliding pair. That's the assumption that you're missing; if instead Bob was trying to construct a malware patch that matched a legitimate one that somebody else constructed, then you would be right and it would indeed be a second preimage attack.
- Executable file formats allow for arbitrary data to be embedded into a file without affecting the program's runtime behavior. This means that Bob gets a lot of latitude to embed random data into both the legitimate patch and the malware.
Those two factors taken together are what allows Bob the opportunity to try a much cheaper collision attack instead of a second preimage attack.