# Does the SHA hash function always generate a fixed length hash?

I'm using the SHA1/2 family of algorithms for a particular project. I was wondering if all the SHA algorithms return a fixed length hash regardless of the length of the data.

-

Essentially yes, they do.

Depending on the exact hash function you choose depends on the length of output you'd expect. For example, SHA256 produces 256 bits of output.

This does then beg the question "but the length of the hash is fixed and there are infinite possible inputs??!!". That's correct, except that $2^{256}$ is 115792089237316195423570985008687907853269984665640564039457584007913129639936. That's an awful lot of unique possible inputs which may be passed in.

You may be interested to know the same concept is used in file systems - they're called bitmaps and provide a block to bit mapping so the file system can quickly find free blocks. The numbers do scale :)

-
I don't see how bitfields are in any way related to hashes. There are some file systems where hashes are essential (e.g. git) but I see no indication of that in your link. Those bitmaps simply have 1 bit to 1 block mapping. –  CodesInChaos Mar 20 '12 at 10:22
@CodeInChaos perhaps I should add extra explanation, but, hash functions essentially eat blocks of data and give you a bit string output. Each bit string maps to a particular combination of input blocks (mapped so by the hash function). That's all there is to it. When you look at the size of the number of unique such combinations you can have ($2^256$ in this case) and the fact these unique combinations map to whole amounts of blocks, you realise there's a huge amount of potential inputs. –  user46 Mar 20 '12 at 10:47
Both map a large set into a smaller set. Secure hashes map in a way that is difficult to reverse. Allocation maps are supposed to be easy to reverse. You can also think of them as lossy compression functions, the loss is tuned to the applications needs. –  Grant BlahaErath Mar 22 '12 at 22:28

Yes, that's their idea. You can rely on it.

-

By the definition in FIPS 180-4, published March 2012, there are
160 bits in the output of SHA-1
224 bits in the output of SHA-224
256 bits in the output of SHA-256
384 bits in the output of SHA-384
512 bits in the output of SHA-512
224 bits in the output of SHA-512/224
256 bits in the output of SHA-512/256

-
SHA-256 is actually SHA-2 256, and the SHA-3 competition will produce the same size outputs as SHA-2, as this is a requirement from NIST, who organize the competition. Naming is still an issue, but SHA-3-256 (etc.) would be a probable candidate. SHA-512 is faster on 64 bit machines than SHA-256 because it is optimized for 64 bit machines - and it still provides a larger security margin. –  Maarten Bodewes Mar 20 '12 at 23:40
@owlstead: the names I use are right from the reference in the first line of the answer, which is both official and fresh (published March 2012). Do you have a reference for that SHA-2 256 naming? –  fgrieu Mar 21 '12 at 12:50
Nah, I meant that it is part of the SHA-2 suite of secure hash algorithms, sorry about that. You can imagine that naming SHA-3 candidates is a bit of an issue, as the SHA-256 etc. have already been taken. Will it be AHS or SHA-3-256, who can tell :) –  Maarten Bodewes Mar 21 '12 at 16:01

I'm was wondering if all the SHA algos return a fixed length hash regardless of the length of the data?

Others have noted that the output is indeed a constant, fixed size, so let me nit-pick one point just for completeness:

It is worth noting that these hash functions do have a limit to the input size of their data. So that input length itself has an upper bound.

From FIPS 180-4:

• SHA-1, SHA-224, SHA-256: Input length is bounded to $2^{64}$ bits.

• SHA-384, SHA-512, SHA-512/224, SHA-512/256: Input length is bounded to $2^{128}$ bits.

These are insanely large sizes (and it seems likely that only the ones for SHA-1, SHA-224, and SHA-256 could practically apply to electromagnetic storage). But in theory $2^{64}$ bit (approx. 1 exbibyte) restriction could prohibit calculating one hash from something like a very large database or distributed filesystem.

But for most developer concerns, these input size restrictions are practically nonexistent.

-
To put things in perspective, SHA-1 performance on modern CPUs is about 0.7 cycles/bit. Assuming a 5 GHz clock, it would take 80 years to hash $2^{64}$ bits. More CPUs do not help. –  fgrieu Mar 24 '12 at 8:35
Thanks for that perspective, I hadn't thought to crunch those numbers. Then the $2^{64}$ restriction also seems practically irrelevant. –  B-Con Mar 24 '12 at 18:55