# MD5 pre-fixing with an unkown postfix

Is the MD5 prefixing attack still valuable to an attacker if he doesn't know the postfix of the string?

For instance, what if the following sanity check was being used:

if attacker_controlled_sanity_code == md5(attacker_controlled + secret_key)


Clearly not an RFC compliant HMAC. Despite the fact that the attacker doesn't know the entire md5'ed message mean that the prefix attack in md5 is useless? Is there another problem with using a broken hash function in this way?

-
What's the objective of the construct; message integrity, like HMAC? If so, the usual setup is not a cryptographic_nonce, suggesting non-reuse by legitimate parties, but not secrecy. Rather, usual setup is a secret_key, assumed reused and shared. –  fgrieu Aug 13 '12 at 11:09
@fgrieu yes, you are correct. –  Rook Aug 13 '12 at 14:45
add comment

## 1 Answer

If the attacker does not know the value of $secretkey$, he cannot predict in advance the value of $MD5( attackercontrolled + secretkey)$. However, what he can to is create two different messages $M$, $M'$ such that:

$MD5( M + secretkey) = MD5( M' + secretkey)$

He cannot predict this common value in advance; however, if he is able to submit $M$ and observe the generated tag, he immediately knows the tag for $M'$

This is a violation of the security properties that message authentication codes are supposed to provide.

-
Is this a product of the prefixing attack, or is this due to the fact that this isn't an RFC'ed hmac? –  Rook Aug 13 '12 at 18:51
@Rook: This is a direct application of the collision attack. In MD5 (and any other Merkle-Damgaard hash), a prefix set of blocks influences only the internal state (the output of the compression function after processing that prefix). The MD5 collision attack allows us to find distinct prefixes that collide in that internal state. Hence, we can postpend any set of blocks to both colliding vectors (even if we don't know the value of that block), and it will preserve the collision. –  poncho Aug 13 '12 at 19:08
add comment