How does the Flickr length extension attack work?

Question

I am currently reading about the length extension attack on Flickr (pdf) but not understanding what's going on there.

m = SECRET || data || padding` and `api_signature = md5(m)

The server sends data and api_signature to the attacker. The attacker now knows:

• h = md5(m) = api_signature
• data
• length of data (Why does he know and why does he have to know?)

Goal of the attacker: append some extra data

How can he do that? He could take api_signature = h = md5(m) and use it as the Initialization Vector of the hash function and hash the extra data and another padding. This is the idea behind the hash length_extension attack, isn't it?

My question: The api_signature will change then because it is calculated like: md5(extra || padding) with the old api_signature as an initialization vector. How is this valid?

And overall: What does the server expect from a "normal" client when he sends this?

Answer 1

How can he do that? He could take api_signature = h = md5(m) and use it as the Initialization Vector of the hash function and hash the extra data and another padding. This is the idea behind the hash length_extension attack, isn't it?

Correct.

My question: The api_signature will change then because it is calculated like: md5(extra || padding) with the old api_signature as an initialization vector. How is this valid?

That is why knowing the length of the data is important. The attacker can use the length extension attack to calculate the MD5 hash of data||original_padding||arbitrary_data by using the original hash value as an IV to calculate the hash h'(arbitrary_data||new_padding), where the new padding uses the total length of the original padded data and the appended data.

And overall: What does the server expect from a "normal" client when he sends this?

The server expects a request that is "authenticated" with a hash of secret||request. By adding data to the end of the request and massaging the URL sufficiently, the attacker can compute the hash without knowing the secret value, for sufficiently modified URLs as to allow arbitrary requests. (Due in part to another weakness in how URL parameters were encoded for hashing.)