# How does the Flickr length extension attack work?

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?

• Could you reference what you were reading just so we know we are talking about the same thing?
– otus
Jan 23, 2016 at 12:25
• Our professor explained it to us in the lecture but I didn't get what he intended to say. So I read up especially here: blog.skullsecurity.org/2012/… Jan 23, 2016 at 12:31
• Exactly, tis is it. Jan 23, 2016 at 12:39

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.)

• SO this means: he has to know the length of the message just to be able to create a valid $new\_padding$??? How does he get the length of the message? After that, the server will get a signature which is actually valid...but it is not the same as the original one? Jan 23, 2016 at 12:35
• Exactly. The attacker in this case knows the length because they know the original data, just not the SECRET key/token (but they know the length of it).
– otus
Jan 23, 2016 at 12:37
• How do they know the length of the original data? I guess they can figure out the length of SECRET by reading the API documentation? Jan 23, 2016 at 12:38
• @今天春天, in this case the data (other than the secret which would indeed be known from how the API works) is the URL that they observe a logged in user sending. They find it out at the same time they find out the original hash value.
– otus
Jan 23, 2016 at 12:40