Does SHA384 make sense with HMAC-SHA256?

Curious

12/2/22, 7:10 PM

In the sense of security level (as defined, for example, by Ferguson and Schneier in the book Practical Cryptography), does it make sense to use SHA384 with HMAC-SHA256 in the general settings. By birthday paradox, HMAC-SHA256 will give a security level of 128 bits, and SHA384 will give 192 bits. To my understanding, the overall security level will be limited to 128 bits and SHA384 is just faking around.

More specific settings: Transmitted packet is:

(x,y,z)

where

y = SHA384 (w)     
z = HMAC-SHA256(x||y)
x and w are any arbitrary values

Ferguson and Schneier also state that SHA384 is relatively useless (as in we do all the work SHA512 and then throw away the bits). Is it still valid for all possible implementations of SHA384?

245

1 + 0

hash

hmac

sha-2

Score:1

Crypto

Maarten Bodewes

12/2/22, 7:22 PM

A keyed hash is not susceptible to collisions / the birthday paradox as the attacker doesn't have the key; you cannot do any pre-calculation and create a set of known hashes because of that (well, you could if you'd have an Oracle with the key, but in that case the Oracle would be signing random data delivered to it).

So you underestimate the security offered by HMAC; in most cases it offers security that is approximately the same as the output size / size of the key. See also keylength.com / NIST recommendations for instance (you need to look at "Hash (B)" for HMAC in the table).

However, you are using y = SHA384(w). Now if an attacker can try and create collision for specific values of w, which would mean that the hash collision is used within the HMAC input, which will of course result in the same HMAC value as well. So here the birthday bound does apply.

So yes, in this case you could try and use SHA-384 or SHA-512 (as length extension attacks won't result in a collision, so those are not on topic). SHA-384 could be used if you suspect that another block of hashing is required if SHA-512 is used though; SHA-384 may then be slightly more efficient - if such efficiency is required at all.

However, please note that we generally assume that SHA-256 already has a strength of 128 bits even when assuming birthday attacks, so there is still no pressing need to use SHA-384 even then.

0 + 3

Curious

12/3/22, 6:21 AM

Your answer is not very clear to me. Can you explain a little bit? Specifically, I interpret your last paragraph as that it doesn't make much sense to use SHA384 instead of SHA256 here. But your second last paragraph kind of contradicts that saying that it could be used. Regarding the first paragraph, what, in your view, is the security level of HMAC-SHA256 then? Related to that, is there any consensus on the security levels of crypto primitives? If yes, is there an authentic and up to date source where one can find the up to date information on that?

Maarten Bodewes

12/3/22, 9:55 AM

Consensus? Um, yes, kind of. We simply assume the worst possible known attack against the primitives. Unless we have a hint that a stronger attack would be easily possible, then the order of the attack determines the security level. If the security level is just one or two bits off we generally just use the original strength (e.g. attacks on AES near $2^{127}$ do not significantly alter the 128 bit security). I've linked to keylength.com /NIST to give an idea of the security strength.

Maarten Bodewes

12/3/22, 10:00 AM

As for the point about SHA-384: well, yes, for collision resistance it could be used, but it offers more security than 128 bit, which generally is considered impossible to break. Still, that's less security than HMAC-SHA-256 offers, so you could go for SHA-512 to offer ~256 bit security.