# Is it possible to fake any file's SHA-256 checksum with a length extension attack?

Can a fake SHA-256 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

In other words, is SHA256 completely insecure when a file's file size is not also included in the verification?

• Good critical thinking. Be sure to digest the (best) answer(s) and accept the one that clarified the ideas. Dec 11, 2020 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. Dec 11, 2020 at 18:34
• An example of above is the Mint ISO Dec 11, 2020 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].". Dec 11, 2020 at 23:52
• Note for ISO even if you could undetectably append data it wouldn't be a useful attack because no ISO reader will look at it or be affected. This contrasts to some other file formats where appending malicious data can deceive and harm a recipient. But that part isn't crypto, thus offtopic. Sep 2, 2021 at 9:24

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, 2020 at 7:20

No. Length extension attacks are not attacks against hashes as hashes. They're attacks against hashes when used for purposes that require stronger security properties.

A length extension calculation on a Merkle-Damgård hash allows an someone to calculate $$H(A||S)$$ for a specific non-empty suffix $$S$$ given the knowledge of only $$\mathsf{length}(A)$$ and $$H(A)$$ (but not $$A$$ itself). The adversary does not get to choose $$S$$ or $$H(A||S)$$. This can only ever be an attack when part of the security protocol is that $$A$$ is secret, because if $$A$$ is public, then everyone can calculate $$H(A||S)$$ for any suffix $$S$$. The best known example of construction where length extension is if you try to build a simple MAC out of a hash function by defining $$F_K(A) = H(K||A)$$ where $$K$$ is a secret key. In order for this to be a MAC, it must be infeasible to calculate $$F_K(A')$$ for any $$A' \ne A$$ even knowing $$A$$ and $$F_K(A)$$. If $$H$$ is a Merkle-Damgård hash, the length extension calculation allows an adversary to calculate $$F_K(A||S)$$ for some non-empty $$S$$ from $$A$$ and $$F_K(A)$$ (and the length of $$K$$), without knowing $$K$$ itself. This doesn't affect the security of $$H$$ as a cryptographic hash, but it means that $$F$$ cannot possibly be a secure MAC.

The Merkle-Damgård length extension property does not contradict the preimage resistance of a hash function. A popular way to state preimage resistance is that it's impossible to find preimages except by brute force. When phrased this way, length extension looks like an attack, because it allows finding the preimage of $$H(A||S)$$ from $$H(A)$$. But this formulation is only an approximation. A more precise (but still not fully precise) definition of preimage resistance is that it's infeasible to find a preimage for almost all potential outputs, or in other word that almost no potential output has a preimage that can feasibly be calculated. The length extension calculation means that if you've calculated one image, you get one preimage for free. This at most doubles the number of preimages you can calculate (and in fact much less because there are many $$A_i$$'s such that the length-extension $$S_i$$ results in the same extended input $$A_i S_i = A_j S_j$$). Less than twice almost none is still almost none.

The Merkle-Damgård length extension property does not contradict the collision resistance of a hash function. Collision resistance means that it's infeasible to find $$A \ne B$$ such that $$H(A) = H(B)$$. Length extension makes it possible to find $$A \ne B$$ such that $$H(B)$$ can be calculated from $$H(A)$$, but that's not a collision since it's infeasible to find a case where $$H(B)$$ would be equal to $H(A). When hashes are used as file checksums, the property that matters is collision resistance, or the weaker property second preimage resistance. As we've just seen, length extension does not make it possible to find collisions. Because Bob's fake ISO checksum matches the official ISO checksum No, it doesn't. The fake ISO checksum can be calculated from the official ISO checksum, but it's a different value. is SHA256 completely insecure when a file's file size is not also included in the verification? No. SHA256 is secure even when the file size is not included. Including the file size doesn't help in any way. And for MD4, MD5 and SHA-1, which were formerly believed to be secure but now have known collisions, the methods to find collisions allow the colliding messages to have the same size, so including the file size doesn't help either. The chance that any other file of any length would have the same SHA256 hash is approximately 1 in 11579208923731619542357098500868790785326998466564056403945758400791 3129639936, which is 2 to the 256th power. In short, not very likely. • Hi Barry and welcome. Could you indicate what your answer adds to poncho's answer? Just performing the calculation$2^{256}\$ doesn't constitute an answer by itself. Sep 1, 2021 at 17:57
• The OP misunderstood what a length extension attack is, and thus assumed it'd allow constructing a second pre-image without brute-force. So simply stating that brute-force is difficult, is unhelpful. Sep 1, 2021 at 18:17