# Why is SHA2 used for file verification if it's susceptible to length extension attacks?

Am I misunderstanding length extension attacks, or is there some different reason, or is it really a bad idea to use SHA2 for file verification?

If the answer is that it's really a bad idea, would removing the last 4 bytes be advisable since now the chances of the attack succeeding will be around one in 4 million, and we will have remaining, in the case of SHA512, 480 bits of security?

• A plain hash function is something anyone can calculate. If you're talking about just hashing the contents of a file and nothing else then length extension does not really come into play. There are versions of SHA-2 which truncate output. 1 in 4 million is insufficient to prevent bruteforce. But truncating by 16 bytes or more prevents length extension. SHA-512/256, SHA-512/224, and SHA-384 truncate by enough bits to make brute force recovery of the hash function state ineffective. – Future Security Jul 29 '18 at 19:32
• @FutureSecurity Your point about 4 bytes not being enough is well taken. But your comment in general seems to contradict Thomas Pornin's answer, does it not? – ispiro Jul 29 '18 at 19:35
• I don't know what contradiction you're talking about – Future Security Jul 29 '18 at 19:37
• @FutureSecurity Maybe I misunderstood you (and obviously length extension attacks as well). It seemed like you were saying that a brute force attack finding a different m' that would have the same hash as m would be possible. If not, what did you mean about brute force being possible? – ispiro Jul 29 '18 at 19:40
• No, not a brute force attempt at collision, 1st preimage,or 2nd preimage. A brute force attempt at length extension. SHA-256 and SHA-512 are designed such that every bit of each algorithm's intermediate state become output bits when the last message block, including padding, is processed. If you drop 1 byte then you know every byte of state except for those 8 bits. Those 8 can be guessed by trial and error of $2^8$ possible unknown values. Drop 4 and it takes $2^{32}$ attempts. Drop 16 and it takes $2^{128}$ work. – Future Security Jul 29 '18 at 19:48

The use of a hash function for verifying integrity of a file is not impacted by length extension attacks. The setup is the following:

• You have a file $m$.
• There is a "guaranteed" source for $h(m)$, with $h$ being a hash function. (For instance, you can get $h(m)$ from an HTTPS Web site with verified provenance.)
• You recompute $h(m)$ and look for a match.

To make an undetected alteration of the file, the attacker would have to find a message $m'$ distinct from $m$, and such that $h(m) = h(m')$. This would constitute a second-preimage attack. No such attack is currently known on any of the SHA-* functions. The "length extension attack" does not seem to help for second-preimage attacks.

It is interesting to note that the "length extension attack" does not contradict any of the classical properties expected from secure hash functions (i.e. resistance to collisions, preimages and second-preimages).

• Are you saying that length extension attacks create a message m' with a different hash? If so, that means that a length extension attack is one signature that will be valid for multiple hashes, as opposed to multiple messages that will have the same hash. Is that correct? – ispiro Jul 29 '18 at 19:25
• It seems that this means that m', though not having the same hash as m, would have some relationship to m's hash, in the sense that a hash (of m') that would have the same signature as a different hash (of m) would be possible to find, while in the case of SHA3 that would be (practically) impossible. Did I understand correctly? – ispiro Jul 29 '18 at 19:48
• The "length extension attack" is about creating a different message $m'$ with a different hash value $h(m')$. It is an "attack" only in the following sense: $h(m')$ can be computed from $h(m)$, without knowing the original $m$, as long as $m'$ consists in $m$ followed by some bits (the attacker can choose most of the subsequent bits). – Thomas Pornin Jul 29 '18 at 20:04