I'm studying Cryptography & Network Security.

It has the following example for collision resistance:

"Suppose Bob writes an IOU message, sends it to Alice, and she signs it. Bob finds two messages with the same hash, one of which requires Alice to pay a small amount and one that requires a large payment. Alice signs the first message, and Bob is then able to claim that the second message is authentic." - (the 7th edition, page 349)

By definition of strong collision resistance, the hash function does not enable finding $y$ given arbitrary $x$ such that $H(x)=H(y)$,
there might not be a way to find $x$, the small amount, and $y$, the large amount, that holds $H(x)=H(y)$.

But the example said it refers to collision resistance.
I am not sure whether it is a right example of strong collision resistance.

Where am I misjudging?

Thank you for your help.


The colliding messages $x$ and $y$ are found by Bob at the beginning of the attack he mounts, before he obtains the IOU signed by Alice. He thus has the choice to make Alice sign the one with the small amount, then present the one with the high amount to an arbitrator.

There's also the problem of how Bob achieves that messages $x$ and $y$ look like an IOU, with a sensible amount. With any single-pass hash (including MD5, SHA-1, SHA-2, SHA-3), the habit of using documents formatted as PDF (or other forms of documents with flexible enough format) makes that relatively easy. It is enough that two syntactically valid headers collide, in a way such that two documents differing by that header will always have the same hash; and that the rest of the document can somewhat detect which header there is, and decide what to display from that. There's then practically absolute freedom about what's shown by two colliding documents. That's been done in the first published attack of SHA-1, as illustrated there.

In practice the attack works only if the attacker gets to choose the octets at the beginning of the file with the IOU; otherwise, a second-preimage attack on the hash is required, which is harder than a collision. In the case of an IOU as PDF, an expert could detect that the PDF's unusual internal syntax shows that the document was prepared with malicious intention; however that's not enough to settle a dispute between Alice and Bob both claiming the other originated the document Alice ended up signing. It could well be that Bob prepares with no malicious intend a document to be signed having a high amount, Alice prepares and signs one having similar appearance but doctored so that Alice can produce another document with the same hash/signature but a low amount, and claim later that she only signed that one.

If there is some fear about the hash's collision resistance, Alice can protect herself by unpredictably choosing something at the beginning of what she signs that was supplied by Bob (an early PDF comment with a large random string will do). Bob can protect himself by preparing the document to be signed from a trusted framework and verifying that it is octet-for-octet (rather than visually) what Alice signs.


In some views, the standard security properties for a ‘cryptographic hash function’ $H$ are:

  • Collision resistance: It is hard to find two messages $x \ne y$ such that $H(x) = H(y)$. Some authors call this strong collision resistance’, but this terminology is not widespread.
  • Preimage resistance: Given a hash $h$, it is hard to find a message $x$ such that $H(x) = h$, i.e. such that $x$ is a preimage under $H$ of $h$.
  • Second-preimage resistance: Given a message $x$, it is hard to find a second message $y \ne x$ such that $H(x) = H(y)$, i.e. that $x$ is a second preimage under $H$ of $H(y)$ distinct from $y$. Some authors call this weak collision resistance’, but this terminology is not widespread.

MD5 is an example of a hash function without (strong) collision resistance: the strings




share the common MD5 hash cee9a457e790cf20d4bdaa6d69f01e41. But MD5 is conjectured to have second-preimage resistance, i.e. weak collision resistance, because nobody has found a technique to find second preimages that costs less than generic brute force attacks which work the same on any function.

Collision resistance is in general a stronger property than second-preimage resistance—hence the alternative names ‘strong collision resistance’ and ‘weak collision resistance’—because if I have a method of computing second preimages, then I can trivially compute collisions, but not vice versa.

In authentication systems like digital signature schemes, the impact of a second-preimage attack is qualitatively worse than the impact of a collision attack. Suppose Alice signs messages using a signature scheme where a signature $s$ depends on a message $m$ only through $H(m)$. (This includes naive (or maliciously designed) digital signature schemes like RSASSA-PSS, but not sensible digital signature schemes like ordinary Ed25519.)

  • Suppose I know a collision attack on $H$. I can use this to find a pair of messages $m \ne m'$, and ask Alice to sign $m$, yielding a signature $s$. Then I can furnish $s$ as a forged signature on the message $m'$, a message which Alice never signed. This requires interaction with Alice.
  • Suppose I know a second-preimage attack on $H$. If I ever get my hands on a signature $s$ on a message $m$ from Alice, I can find another message $m' \ne m$, and furnish $s$ as a forged signature on the message $m'$, a message which Alice never signed. This can happen even retroactively without interaction with Alice.

However, this qualitative difference didn't stop researchers from demonstrating HTTPS CA certificate forgery using MD5 collisions in practice. So don't rely too heavily on it!

Of course, there are many other things called hash functions in cryptography—it is a very broad term, and many applications require properties not listed here like pseudorandomness, target collision resistance, or low collision probabilities—and in fact none of the three usual properties at the top even has a formal definition.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.