9
$\begingroup$

NIST specified SHA-2 hash functions with truncated output. Those hashes use different initialization values than SHA-256 or SHA-512. SHA-224 is based on SHA-256. SHA-384, SHA-512/224 and SHA-512/256 are all based on SHA-512.

Although I have seen loose comments on why truncated SHA-2 functions use different initial values, I haven't seen any strong reasoning. The only thing that I can formally find is a quote from RFC 3874: "A 224-bit One-way Hash Function: SHA-224", section "1.1. Usage Considerations:

The use of a different initial value ensures that a truncated SHA-256 message digest value cannot be mistaken for a SHA-224 message digest value computed on the same data.

But that quote doesn't list any specific attacks nor is it part of a security review of SHA-2.

Can anybody explain which attacks are prevented by choosing different initial values for the SHA-2 variants?

I'm specifically looking for answers that indicate how the initial values help mitigate the attack. More importantly, I'm looking for authoritative answers, that is: answers that can point to a security evaluation or proof of SHA-2 on this subject.

$\endgroup$
  • $\begingroup$ If no authoritative answer exists then I might accept or at least vote up an answer with strong reasoning on the subject. $\endgroup$ – Maarten Bodewes Jul 20 '18 at 13:02
  • 4
    $\begingroup$ For starters it ensures that SHA-512 and SHA-512/256 outputs are actually "unrelated" for the same input which would obviously not be the case if they used the same IVs... $\endgroup$ – SEJPM Jul 20 '18 at 13:15
  • $\begingroup$ @SEJPM True, but that's exactly the loose comment I've seen from e.g. fgrieu and, funny enough, myself and SEJPM :) It kind of bugs me because I don't see any solid reasoning for a design choice of an algorithm, and maybe other attacks could exist. $\endgroup$ – Maarten Bodewes Jul 20 '18 at 13:19
  • 2
    $\begingroup$ In other words, "why is a trivial partial preimage bad?" $\endgroup$ – forest Jul 21 '18 at 0:37
8
$\begingroup$

The question's citation is likely the reason why it was chosen different initial starting values for SHA-2 variants of the same internal block size. It is a valid objective by itself that different hash functions yield independent results, linkable only knowing their common input. It is not necessary to have a specific attack in mind to make that conservative choice.

Otherwise stated: For an attacker knowing the SHA-1 of some secret, the best option to find the SHA-256 of that secret is to find the secret. Using different initial values makes it such that the same holds if the attacker knows the SHA-224 hash instead of the SHA-1 hash. That could be called (domain) separation of hash functions.

It is easy to construct artificial protocols where this precaution saves the day. For example: Alice draws a 80-byte random string $S$, reveals its SHA-224 (say, as a commitment or a Key Check Value), then uses $S$ as an HMAC key with SHA-256 as the underlying hash. HMAC will start by hashing $S$ with SHA-256, then use that as its internal key. With the different initialization values in SHA-224 and SHA-256, Alice is safe. Without, she's headed for disaster, as all but 32 bits of the HMAC key coincide with the leaked SHA-224.

$\endgroup$
7
$\begingroup$

Using different initial values means that finding collisions must be done independently for both algorithms.

This is admittedly not an authoritative source, but I found the description in this answer (to the same question on CS Theory SE) convincing.

If you were to use the same initial value from SHA-256 for SHA-224, you would ultimately just be truncating the SHA-256 hash to 224-bits. This equates the problem of finding a SHA-224 hash collision to finding two SHA-256 hashes that differ in the final 32 bits. By using different initial values you reduce the likelihood that a partial collision in SHA-256 will inform the possibility of collisions in SHA-224.

The same relationship would apply to preimages. For example, if someone were to find a way to generate partial second-preimages for SHA-256 (partial in the sense that they match on some number of bits in the hash), it may not bode well for SHA-256 but it would potentially be devastating to SHA-224. In the worst case, if someone could find such second-preimages that match on the first 224 bits, one would worry whether we are not only 232 iterations of that process away from finding full second-preimages of SHA-256. However, SHA-224 would undoubtedly be broken. However, if this attack is based on some weakness in initial values chosen for SHA-256, it may not also apply to SHA-224. By separating the domains of the two hash functions (by using different initial values), we increase the likelihood that an attack on one would not apply to the other.

$\endgroup$
  • 4
    $\begingroup$ Thanks! That answer contains the term "domain separation" which probably is key to explaining the different initial values. I'm mainly just posting this comment so it is somehow included on this page :) $\endgroup$ – Maarten Bodewes Jul 20 '18 at 15:41
  • $\begingroup$ @MaartenBodewes after looking into this a little more closely I've added a bit to my answer to help clarify somewhat what kinds of attacks are relevant here since that's what you asked about. I also made more explicit reference to domain separation given that I agree this is the key thing that is happening when you choose different initial values. $\endgroup$ – thesquaregroot Aug 6 '18 at 2:55
  • $\begingroup$ I've decided to accept fgrieu's answer as I think that the attack you are describing is somewhat hypothetical. The initial values of SHA-256 and SHA-224 haven't been chosen with a different security argument in mind - as far as I've understood, so the chance that either one is less secure than the other is about 50% (if they are insecure in the first place, of course). The answer of fgrieu is however directly practical and also includes the (domain) separation argument. Thank you so much for the additional edits! $\endgroup$ – Maarten Bodewes Aug 7 '18 at 1:24
  • $\begingroup$ @MaartenBodewes No worries! This question got me thinking and was a good excuse to research some things I knew I needed to get a better understanding of, so thanks for asking it! $\endgroup$ – thesquaregroot Aug 7 '18 at 1:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.