# Why isn't outputting only a portion of the hash state a simple defense against length extension attacks?

As I understand length extension attacks, they depend on the coincidental property of most cryptographic hash functions that the hash value is exactly the hash function state after hashing the last block of data. This enables an attacker to initialize their own hash function with the state as it "left off".

This being the case, why are hash functions simply not defined as outputting the n-byte prefix of their state (i.e. for a 256-bit hash, maintain 512 bits of state)? I'm assuming there's a fundamental reason this isn't done, but I haven't been able to find any literature specifically addressing it.

• That approach is secure. Perhaps there are even some SHA-3 candidates which use this approach, though I can't think of one. – CodesInChaos Jul 14 '15 at 14:20

Contrary to your assumption, this is done, and it is secure: For instance, the hash functions SHA-224 and SHA-384 are basically the same algorithms as SHA-256 and SHA-512! The only differences are in the initial values for the Merkle-Damgård construction used internally and, of course, in that only the first $224$ or $384$ bits of the resulting hash are output. These hash functions are resistant against length-extension attacks since an attacker would have to guess the remaining (too many) bits of the internal state. (Note that the choice of different initial values is irrelevant to this issue, so just truncating SHA-256 or SHA-512 also yields length-extension-resistant hashes.)
As another almost-example: In some sense, Keccak/SHA3's first $r$ output bits are simply a prefix of the internal state after consumption of the last block, while the rest of the state is kept secret (and possibly used to compute more output bits, which are again prefixes of the internal state, through repeated application of a so-called "sponge function"). With this construction one can argue, and in fact this is advertised as a feature of Keccak, that the keyed hash $\operatorname{Keccak}(\mathit{key}\mathbin\Vert\mathit{data})$ yields a secure MAC, while the same construction for Merkle-Damgård hashes is vulnerable to length-extension attacks.