If a length extension attack can occur because of $H(\text{K}\mathbin\|\text{Message})$, what changed in SHA-3 from SHA-2 that prevents this from occurring?
1 Answer
Everything was changed between SHA-2 and SHA-3.
In the specific case of the "length extension attack": the issue is that SHA-2 process data by splitting it into elementary blocks (64 or 128 bytes, depending on the SHA-2 variant), and produces for each block an output which has exactly the same size as the function output. Moreover, the output for a complete message is merely the current output after processing all blocks of the (padded) message. This means that anybody can take a hash output and "continue" processing of a longer message with additional blocks.
In SHA-3, a sponge construction is used. The crucial point is that, in a sponge, the internal state is much larger than the hash function output. Thus, you cannot simply "continue" processing of a message by using a hash output, because that output contains only a fraction of the internal state.
You can get the same kind of protection with a SHA-2 function by truncating the output. For instance, there is a (relatively new) member of the SHA-2 family called "SHA-512/256", which is SHA-512 (with a different conventional IV) with output truncated to 256 bits. This truncation makes it immune to the length extension attack.
-
3$\begingroup$ Note that in the SHA-2 family, SHA-224 and SHA-384 have limited protection against length extension attacks. But they are not very safe, unlike SHA-3 which is designed to be resistant to length extension from the start. $\endgroup$– NayukiSep 26, 2018 at 0:50
-
$\begingroup$ I believe the main reason for introducing SHA-512/256 is that on 64 bit CPUs it is faster than SHA-256. But I'd usually go with SHA384 which is a bit more widely supported than SHA-512/256. The only two differences between SHA384 and SHA-512/256 is a different IV and being truncated to different lengths. $\endgroup$– kasperdSep 26, 2018 at 10:02