# Is it possible to fake any file's SHA256 checksum with Length extension attack? Is SHA256 completely insecure when file size is not also checked?

Can fake SHA256 checksum be created trivially for any file by attacker after padding some data after original file i.e. using length extension attack?

E.g:

1. Alice creates fake linux installation ISO file using length extension attack by padding extra data after ISO and calculates fake SHA256 checksum of the ISO

2. Bob downloads Alice's fake ISO file and calculates the SHA256 of the ISO

3. Bob compares the SHA256 checksum that he generated from fake ISO file to the checksum found on official linux distribution's home page. Because Bob's fake ISO checksum matches the official ISO checksum, Bob doesn't notice that he has downloaded fake ISO

4. If Bob had compared the fake ISO file size to the original ISO file size found on official linux distribution's home page in addition to calculating the checksum, he would have noticed that he has fake ISO not the original

Is this trivial to do?

In other words, is SHA256 completely insecure when a file's file size is not manually checked by computer user?

Does the file size always need to be checked when using SHA256?

• Good critical thinking. Be sure to digest the (best) answer(s) and accept the one that clarified the ideas. – DannyNiu Dec 11 '20 at 6:04
• Actually, the fake ISO is not working like that, you create a download site with the fake ISO including your on checksum. Most of the time it will work until one controls the checksum with the original site. I wonder how many people check it? Another way is attacking the original site and replace the ISO and its checksum with your fake ISO and checksum. – kelalaka Dec 11 '20 at 18:34
• An example of above is the Mint ISO – kelalaka Dec 11 '20 at 22:34
• Setting aside completely the question of whether the length extension attack works the way you think it does or not, the page you linked includes the quote "Truncated versions of SHA-2, including SHA-384 and SHA256/512 are not susceptible [to length extension attacks].". – Daniel Wagner Dec 11 '20 at 23:52

1. Bob compares the SHA256 checksum that he generated from fake ISO file to the checksum found on official linux distribution's home page. Because Bob's fake ISO checksum matches the official ISO checksum, Bob doesn't notice that he has downloaded fake ISO

I highlighted the incorrect assumption: the checksums wouldn't match.

What the length extension attack allows someone to do is, given the hash of an unknown message $$M$$, compute the hash of a message $$M | pad | X$$ (for a specific string $$pad$$ which depends on the length of $$M$$, and an arbitrary string $$X$$).

However, the hash of $$M | pad | X$$ will not (in general, that is, barring an extremely improbable coincidence) be the same as the hash of $$M$$.

If it were, that would count as a hash collision, hence disproving the collision resistance of SHA256.

Is this trivial to do?

It is believed to be infeasible to make the hashes match. Yes, the adversary could compute the hash of $$Y = M | pad | X$$, however because he knows what his image $$Y$$ is, he could compute its hash without any special properties of the hash function.

• Addition: thus, the file size needs not be checked when using SHA256, and the hash's value can be trusted. – fgrieu Dec 11 '20 at 7:20