I'm trying to understand how the hash length extension might work on real web applications using a hash for MAC. Especially what I don't get is, how the application considers the evil forged hash valid.

Let's say we have an app which sends this and I want to tamper with data

POST /stuff?mac=d147c7b4a79f920a1efefddc30da181f036073cd


We can agree that the app behind the scene does something like this

if($_GET['mac'] == $_SESSION['previouslyCalculatedHash/Viewstate']) {
    echo 'OK'

Except if I do that, length extension does not allow to tamper data, as shown below it does not give me the same hash, which makes sense and so I don't see what we can do with this attack on real applications which might check for string equality with a previously calculated hash saved in application state.

❯ echo -n 'SECRETdata' | sha1sum                                                   
d147c7b4a79f920a1efefddc30da181f036073cd  -

❯ hashpump -s d147c7b4a79f920a1efefddc30da181f036073cd --data 'data' -a 'evil' -k 6

❯ echo -n 'SECRETdataevil' | sha1sum                                            
482ac2a591135150b444bd18e4e045f5fd3881a6 -

So, I would like to know a real example where the length extension might allow a bypass on a web application.


1 Answer 1


A length extension attack can be performed on the Merkle–Damgård construction (MD) based hash functions (MD5,SHA1,SHA2,...). The trimmed versions of SHA2 series like SHA512-256 or HAIFA ( extension to MD) based hash functions like Blake(2(b)), or the SHA3 are immune to length extension attack.

To be useful the attack needs the data (known_data). The first real attack was on the Flicker API over MD5 on Sep. 28, 2009. Actually, It is more than that, it is signature forge.

Given a hash value h with the secret_key the signature is calculated as;

   `h = MD5(IV,secret_key || known_data || pad1)`

one can form a new message without knowing the secret_key. If there is no secret_key, then there is no problem, just compute the hash of any data you want and the server will accept.

Now, the attacker takes the message and the signature to forge this

h' = MD5(IV,secret_key || known_data || pad1 || appended_data || pad2)

here the new message is m' = known_data || pad1 || appended_data

The pad1 and pad2 are the MD5 function padding.

They can execute the extension as;


In other words, one just needs the change the initial values of the MD5 with the h. Now, one can send this to the server with the message by the server's protocol, and the server will accept it. As shown, the attacker doesn't need the secret_key at all to execute this attack.

The attack worked since the secret_key is in the beginning. Today we have better constructions like HMAC which is immune to the length extension attacks. HMAC is expensive since two calls of the hash function. With SHA3 we have a new one KMAC that has a more simple design and easier proof of security.

update per comment:

I don't get how applications validate hash signature, as hash are only one way and can't be decoded

To validate the signature it will use the canonical verification, the application, take the received new message m and hash it with the secret_key and check the equality with the received h. They are fooled since they considered that the secret_key is enough for this signature scheme.

  • Thanks for answer. I do get that part. What I don't get is how the application verify the signature for a vulnerable hash, and can be fooled. I get that you can build a hash without shared key with the vulnerability, but I don't see how the application can be fooled by it, because I don't get how applications validate hash signature, as hash are only one way and can't be decoded. Commented Nov 16, 2020 at 7:40
  • @user4809674 I've added a part for your problem.
    – kelalaka
    Commented Nov 16, 2020 at 8:41
  • Alright starts to understand, Yet one last thing bothers me. When generating the extended hash, this one is different from manually computed with the secret key (check my example with hash 21e42c16b9cd8b06763d4383efa2175e8abc93f2 and 482ac2a591135150b444bd18e4e045f5fd3881a6 for instance). And then when the application will compute h = (secret | message | evil_value), it will be different and wrong then. Or am I missing something or doing something wrong when computing my examples hashes ? Commented Nov 17, 2020 at 7:52
  • Of course, it will be different, we are not looking for a hash secondary image we are looking for forgeries. It is still valid since the server can accept it. As I said, without the key, there is no problem at, all. It was assumed that the key will prevent it!
    – kelalaka
    Commented Nov 17, 2020 at 10:20
  • All clear now?.
    – kelalaka
    Commented Nov 21, 2020 at 20:28

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .