The attack is to create an internal collision of m and m’ before k is appended. At that point, the chaining variables are identical so adding k and the padding will result in identical final hashes. You are right in that this attack does not allow different lengths for m and m’. However, this is not a serious limitation for the attack since you are choosing m, and thus can make it any length you want in order to match the eventual m’.

If m and m’ have the same length, then the length padding for m || k and m’ || k will be the same and a collision with m and m’ will yeild a collision for m || k and m’ || k. However, if m and m’ have a different length then the length padding, AFAIK, will cause problems. Here is my reasoning:

Since the attacker can choose m and m’, they can ensure that the hashes of m and m’, including padding, are equal. This external collision relies on both m and m’ and their padding. But k is concatenated before the padding which means that the new padding for both will be altered. If the padding for both messages is altered then the collision is no longer gaurenteed. (Unless adding a constant to the pre-image of a collision preserves the collision.)

The paper explicitly requires an internal collision in order to make this attack work. But if the messages have different padding, then the hashes will be equal right up until the padding is added.

The attacker can compensate by (assuming he knows the length of k) adjusting the padding he uses to reflect a length of length(m || k). He can then find a collision using the altered padding for m and m’. But still, adding the key to the end of the message, but before the padding, cause the internal state to be different before processing the padding, which should yield different hashes.

I’ve read the paper by Preneel that you linked to, and it seems as if the problem I mention is because MD5 and SHA1 are not “pure” Merkle–Damgård constructions. The paper defines the “iterative” hash functions to be (from pg. 4):

H_0 = IV; H_i = f(H_{i-1},m_i), 1 <= i <= t ; hash(m) = H_t

and in the case of a MAC:

hash(m) = g(H_t)

However, for a function that includes length padding, this seems to be more like:

hash(m) = g(H_t,l(m))

because the final transform is a function of both the last block and the entire message (which is the length of the entire message).

Am I missing something here? This second method of attack against hash(m || k) only seems to work for substituting m' of equal length to m when dealing with hashes like SHA or MD5.