0

A HMAC is usually said to be H(sk || msg) for some secret key sk and message msg.

My first question is, can we compute it as H(msg || sk) instead ? Is there any drawbacks doing it ?

If the answer is yes, consider H as vulnerable to length extension attacks, would such a MAC be vulnerable to length extension attacks ? I can't see how since such an attack would just lead to H(msg || sk || msg2) which is not valid.

Makubu
  • 21
  • 2
  • 2
    Actually, HMAC is more like $\text{Hash}(SK \oplus opad || \text{Hash}(SK2 \oplus ipad || Message ))$ - hence, neither collision nor length extension attacks apply – poncho Dec 13 '23 at 18:39
  • 1
    When talking about secret-suffix MAC rather than HMAC, this question has already been answered here and here. For HMAC, the message parameter can be used as a key because it's a dual-PRF. This is done in major Internet protocols, as explained in that linked paper. – samuel-lucas6 Dec 13 '23 at 21:35
  • On the generic question of the tile: the answer is generally no. For example: a secure block cipher is also a secure MAC (for fixed size inputs). However, if we switch the input and keys of the block cipher, this becomes insecure and broken with a single query. As said before, tho, if we have a dual PRF, then switching is fine. – Marc Ilunga Dec 14 '23 at 04:15

2 Answers2

0

I could think of at least 3 problems that can happen when we switch the message and the key in HMAC:

  1. The message acting as the key, most likely, won't have the needed cryptographic randomness expected from a secret key. Hence, the security strength of this operation will be severely demoted
  2. All the internals of HMAC will be messed up. First the key length is compared to block size then certain operations are done on the key to produce k0. K0 then is XOR'ed with ipad, etc. All this will now happen on the message! Likewise, the message which is usually variable length will act as the key so unexpected behavior could be an understatement here.
  3. According to Bellare's Authenticated Encryption: Relations among notions and analysis of the generic composition paradigm, a MAC doesn't provide IND-CPA. In other words, the MAC could reveal information about the plaintext. If we switch message and key, it could mean that we are revealing information about the key; which is never good!
hlayhel
  • 376
  • 1
  • 7
  • 1
    And yet HMAC is used with the message as the key in Internet protocols and HKDF... – samuel-lucas6 Dec 13 '23 at 21:42
  • Point 2 is faire when considering variable message lengths. Since the internals of HMAC will allow some trivial collisions. But when restricted to some lengths, this is actually fine, as the comment above says. On point 3, IND-CPA isn't typically a property expected of MACs. Note that that issue doesn't go away even with normal MACs. The question doesn't seem to require any additional notions besides unforgeability. – Marc Ilunga Dec 14 '23 at 04:19
0

My first question is, can we compute it as H(msg || sk) instead ? Is there any drawbacks doing it ?

The obvious issue is that if we find a state collision in two messages (that is, two different messages that yield the same hash state), then they'll also MAC the same (no matter what the key is).

Collision resistance is a stronger assumption than the normal assumptions that HMAC makes, hence this doesn't seem to be a great trade-off.

poncho
  • 147,019
  • 11
  • 229
  • 360