One of the new features of Java 8 is the SHA-224 message digest.
What is the use case for having a 224-bit-length hash?
$\begingroup$
$\endgroup$
Add a comment
|
3 Answers
$\begingroup$
$\endgroup$
3
SHA-224, part of FIPS 180 since FIPS 180-3 FIPS 180-2 change notice 1 of 2004, was introduced to match the second of the security strengths {80, 112, 128, 192, 256} defined in the document that became NIST Special Publication 800-57 – Recommendation for Key Management – Part 1: General (Revision 3). That security strength itself was kept because it matches the assessed security strength of 3DES (see NIST Special Publication 800-131A – Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths). That motivation is reported in RFC 3874.
SHA-224 was defined by slightly modifying SHA-256 of FIPS 180-2, in two ways:
- truncation of the output from 256 bits to 224 bits, so that the expected cost of finding a collision by brute force is about 2112 evaluations of the compression function, see the birthday problem;
- a different initialization value, so that knowledge of the SHA-224 hash of a message does not reveal information on the SHA-256 hash of that (or vice versa).
As a side benefit, SHA-224's output is 28 bytes instead of 32 for SHA-256, which is useful on some occasions, including a huge number of hashes (as rightly pointed in this other answer) or mapping to an Elliptic Curve Group of some particular size. But if that's put to use in any FIPS-endorsed usage, I missed it, and welcome the info.
Update: to clarify why 224 bit is the right size to match the assessed security strength of 3DES: SP 800-131A says " three-key Triple DES is assessed at a security strength of 112 bits ", I think referring to the attack of Stefan Lucks: Attacking Triple Encryption (in proceedings of FSE 1998), or perhaps to the ealier meet-in-the-middle attack of Ralph C. Merkle and Martin E. Hellman: On the Security of Multiple Encryption (1981, Communications of the ACM, Volume 24 Number 7). We need to double that 112 to obtain the required bit width of a hash of equivalent strength, including against very practical attacks, see Paul C. van Oorschot and Michael J. Wiener: Parallel collision search with cryptanalytic applications (1999, Journal of Cryptology 12 (1), 1-28).
-
$\begingroup$ So, in short, it's not an arbitrary number; it is precisely half the length of a 3DES key. Thanks! $\endgroup$– user9070Mar 21, 2014 at 15:25
-
4$\begingroup$ @TruthSerum: No! Half the length of a 3DES key would be 96 or 84 bit, depending on if you count parity or not. It is more like 224 is twice the the base-two logarithm of an estimation of the number of operations in the best known attack for 3DES, assuming unlimited memory. $\endgroup$– fgrieu ♦Mar 21, 2014 at 15:33
-
1$\begingroup$ FIPS 180's SHA-224 is somewhat endorsed for specific FIPS 186 ECDSA curve (P-224) and DSA domain param sizes (L=2048, N=224). However, NIST P-224 curve predates the FIPS 180-2 change notice 1, and for that reason, several systems have already taken it into use with other SHA family hashes. $\endgroup$– user4982Mar 21, 2014 at 19:55
$\begingroup$
$\endgroup$
2
It meets the security requirement for 112-bit collision and preimage resistance, while being 32 bits shorter than SHA-256.
This may not seem like a lot, but when you have thousands or even millions of hashes or signatures to worry about in a system, those extra 4 bytes add up.
Think of a webmail service, where a hash of each email is used for deduplication and stored, you need enough collision resistance for the system, but don't want to needlessly waste space if you have billions of emails coming in every day. Those 4 bytes add up to several terabytes per year, per server
answered Mar 21, 2014 at 10:44
-
1$\begingroup$ Additionally, (though not sure if specifically designed for this), SHA-224 is not vulnerable to the length extension attack otherwise inherent to the Merkle–Damgård construction. $\endgroup$– ntoskrnlMar 21, 2014 at 11:58
-
6$\begingroup$ @ntkskml: I frown at not vulnerable: the adversary trying an obvious modification of a length extension attack has odds of success $n/2^{32}$ with $n$ attempts. $\endgroup$– fgrieu ♦Mar 21, 2014 at 18:52
$\begingroup$
$\endgroup$
1
Honestly, in practice, there are very few if any reasons to use SHA-224.
As fgrieu notes, SHA-224 is simply SHA-256 with a different IV and with 32 of the output bits thrown away. For most purposes, if you want a hash with more than 128 but less than 256 bits, simply using SHA-256 and truncating the output yourself to the desired bit length is simpler and just as efficient as using SHA-224. As you observe, SHA-256 is also more likely to be available on different platforms than SHA-224, making it the better choice for portability.
Why would you ever want to use SHA-224, then?
The obvious use case is if you need to implement an existing protocol that specifies the use of SHA-224 hashes. While, for the reasons described above, it's not a very common choice, I'm sure such protocols do exist.
Also, a minor advantage of SHA-224 over truncated SHA-256 is that, due to the different IV, knowing the SHA-224 hash of a given message does not reveal anything useful about its SHA-256 hash, or vice versa. This is really more of an "idiot-proofing" feature; since the two hashes have different names, careless users might assume that their outputs have nothing in common, so NIST changed the IV to ensure that this is indeed the case.
However, this isn't really something you should generally rely on. If you really need to compute multiple unrelated hashes of the same input string, what you probably want instead is a keyed PRF like HMAC, which can be instantiated using any common hash function (such as SHA-256).
answered Mar 21, 2014 at 22:33
-
2$\begingroup$ I find your answer most insightful this far. The SHA-224 was apparently primarily specified for DSS (ECDSA, DSA, RSA). But for all these uses SHA-256 is at least as good. SHA-224 serves more to create confusion and one more option. $\endgroup$– user4982Mar 22, 2014 at 7:29