# Why do cryptographic hashes need to be fixed length?

Why do cryptographic hashes need to have a fixed length output?

I know that the shallow answer is that an output that varies by key size or file size can leak information somehow, leading to cryptanalysis, but I would like some more intuition as to why this is the case.

In the case of using an HMAC, like HMAC-SHA256 or HMAC-SHA1, is it still the hash (SHA256 or SHA1) which is ensuring that the output is of a fixed length? Or does the HMAC algorithm come into play as well?

• You can always chain a hash with a stream cipher to get variable length output. – CodesInChaos Nov 6 '15 at 21:35
• – Richie Frame Nov 7 '15 at 2:04
• Fixed length is no special property from the cryptographically secure part. It comes from the more general specification of hash functions. In fact, it is the defining property of hash functions: "A hash function is any function that can be used to map data of arbitrary size to data of fixed size" (Wikipedia) – tylo Nov 9 '15 at 14:24

Q: Why do cryptographic hashes need to have a fixed length output?

I know that the shallow answer is that an output that varies by key size or file size can leak information somehow, leading to cryptanalysis, but I would like some more intuition as to why this is the case.

It depends on what you mean with that. If you mean that they need to have a certain configured length then that is not the case. SHA-384 is basically SHA-512 with different vectors and you could view it as a parameterization of the same hash function.

If you mean that the length of the hash is dependent on the input then you've already answered your own question. The idea is that the hash value itself doesn't leak information about the input.

Or as it is currently written in Wikipedia:

Ideally, one may wish for even stronger conditions. It should be impossible for an adversary to find two messages with substantially similar digests; or to infer any useful information about the data, given only its digest. Therefore, a cryptographic hash function should behave as much as possible like a random function while still being deterministic and efficiently computable.

Of course this property is violated if the size of the hash function depends on the size of input.

A keyed hash such as HMAC should have the same properties as a unkeyed hash in this regard.

Regarding key size: Key size should not be considered a parameter of a keyed hash function, so usually it is not a problem for the output size to depend on it, as long as the key size doesn't fluctuate once in use.

Regarding file size: If you don't mind that an attacker can distinguish between various input sizes then nothing will stop you from using different hash sizes or even different hash functions for specific ranges in size.

Q: In the case of using an HMAC, like HMAC-SHA256 or HMAC-SHA1, is it still the hash (SHA256 or SHA1) which is ensuring that the output is of a fixed length? Or does the HMAC algorithm come into play as well?

Well, the HMAC algorithm ends with

return hash(o_key_pad ∥ hash(i_key_pad ∥ message))


so in the end the output is exactly the size of the hash. The HMAC algorithm of course describes that this is the case. But the output length is not a parameter of HMAC. That said, it is possible (but in general not recommended) to use only part of the output of HMAC as the authentication tag. That would however be outside of the definition of HMAC itself.

They don't, and in fact the sponge construction used in Keccak (SHA-3) allows for variable length output.

In other hashes the Merkle-Damgård construction was used which has a fixed output length due to the nature of its design. But there is no reason to not allow for variable output length other than ease of development or use.

• Technically the variable length SHAKEs aren't hash functions. They call them eXtendable Output Functions, XOF. – otus Nov 7 '15 at 7:05
• @otus you are right. – Keelan Nov 7 '15 at 7:24