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.
$\begingroup$
$\endgroup$
asked Mar 20, 2012 at 9:44
Add a comment
|
4 Answers
$\begingroup$
$\endgroup$
6
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 :)
-
2$\begingroup$ 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. $\endgroup$ Mar 20, 2012 at 10:22
-
$\begingroup$ @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. $\endgroup$– user46Mar 20, 2012 at 10:47
-
$\begingroup$ 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. $\endgroup$ Mar 22, 2012 at 22:28
-
1$\begingroup$ The possible inputs are not infinite! In your case, which is SHA-256, the maximum size of input is $2^{64}-1$ bits. The number of possible inputs is definitely huge, but not unlimited. $\endgroup$– saeednSep 14, 2016 at 17:57
-
$\begingroup$ @saeedn According to your comment I would not be able to calculate the hash for a file of 9 bytes. SHA-256 calculates the hash by mean of processing blocks right ? Do you mean that there is a maximum amount of blocks ? $\endgroup$– yucerApr 19, 2017 at 19:16
$\begingroup$
$\endgroup$
3
Yes. By the definition in FIPS 180-4, there are exactly
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
-
$\begingroup$ 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. $\endgroup$– Maarten Bodewes ♦Mar 20, 2012 at 23:40
-
$\begingroup$ @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 256naming? $\endgroup$– fgrieu ♦Mar 21, 2012 at 12:50 -
$\begingroup$ 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 :) $\endgroup$– Maarten Bodewes ♦Mar 21, 2012 at 16:01
$\begingroup$
$\endgroup$
Yes, that's their idea. You can rely on it.
$\begingroup$
$\endgroup$
2
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.
-
3$\begingroup$ 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. $\endgroup$– fgrieu ♦Mar 24, 2012 at 8:35
-
1$\begingroup$ Thanks for that perspective, I hadn't thought to crunch those numbers. Then the $2^{64}$ restriction also seems practically irrelevant. $\endgroup$– B-ConMar 24, 2012 at 18:55