HMAC and SHA-1 weakness?

Question

Imagine the following scenario:

1. Select known data (known to several parties)
2. Mix data with secret key and generate SHA-1 hash
3. Mix SHA-1 hash with secret key and generate HMAC

The purpose is to verify the integrity of the data - to ensure that data has not been altered after the generation of the HMAC.

My question is:

• Is there any weakness to using a SHA-1 hash rather than for example SHA-256 in this scenario?
• Does the use of SHA-1 make it easier to for example extract the secret key compared to SHA-256?

Answer 1

Select known data (known to several parties)

If the data is already known then there is no reason to distribute it. You could just refer to it.

Mix data with secret key and generate SHA-1 hash

That's what you use a HMAC for.

Mix SHA-1 hash with secret key and generate HMAC

You'd normally use your symmetric key only once.

---

Is there any weakness to using a SHA-1 hash rather than for example SHA-256 in this scenario?

It's got smaller output and therefore less protection against brute force attacks, but HMAC in itself isn't vulnerable. SHA-1 is however under attack, with collision resistance the first to go. If you manage to muck up step 2 then you're likely in trouble. If you use HMAC then you may not be directly vulnerable to current known attacks. But attacks only get better.

Does the use of SHA-1 make it easier to for example extract the secret key compared to SHA-256?

No, the fact that SHA-1 may be less collision resistant doesn't mean that the algorithm is reversible.

---

That said, unless there are pressing requirements to use SHA-1, e.g. backwards compatibility, I would rather choose SHA-256 or SHA-512/256.

Answer 2

Regarding SHA-1 vs SHA-256, SHA-1 is somewhat deprecated because it's getting uncomfortably close to being broken for some applications: it may be possible to generate a collision for a cost of less than 1M\$ (although it's been a while since this prediction was made and nobody's published a collision yet). In your scenario, the important property is not collision resistance (i.e. being unable to find X and Y such that SHA-1(X) = SHA-1(Y) but X ≠ Y), but preimage resistance (being unable to find X given SHA-1(X)). There is no known attack against this property that's anywhere close to being feasible. So while it would be good hygiene to use SHA-256, SHA-1 is also ok.

Remembering HMAC-SHA-1(secret key, data) is sufficient to verify the integrity of the data without allowing entities that don't know the key to find what the data is. Even SHA-1(data) would mostly do for this, except that an adversary could verify a guess for the data. With HMAC-SHA-1, an adversary cannot verify a guess without knowing the secret key or asking a party that knows the secret key. If your only concern is to verify the integrity then SHA-1 is sufficient.

Your step 2 is not necessary and you should skip it. It's probably not harmful, but it might be. It depends exactly how you “mix data with secret key”. Generally speaking, it's a bad idea to use the same key for multiple purposes, because there might be coincidences in the way the key is used. For example, if the way you do this mix at step 2 is to calculate HMAC-SHA-1(secret key, data), then your integrity value is HMAC-SHA-1(secret key, HMAC-SHA-1(secret key, data)). If the intermediate value is revealed to an adversary then they can submit it as the data, and then they can get your system to calculate HMAC-SHA-1(secret key, HMAC-SHA-1(secret key, HMAC-SHA-1(secret key, data))), and so on, which might give them some advantage such as substituting some data with its HMAC. This sort of protocol attack tends to work only if things align just right, but in practice it does sometimes happen that things align just right, and that can completely break an otherwise-secure system. So, don't use the same key for different purposes.

If you need to use secret material in different places in a protocol, then use your secret material as a master secret rather than a key, and apply a key derivation function to generate independent-in-practice keys for each purpose. But here you should simply omit step 2 and use the key only once, for the single HMAC step.