48

Can anyone point out what the advantage of using HMАC is?

For example, if I have a text T and a key K, I can use either HMAC-MD5 algorithm or Md5(T + K) to get a signature.

scoa
  • 19,359
  • 5
  • 65
  • 80
user496949
  • 83,087
  • 147
  • 309
  • 426

3 Answers3

38

HMAC is not susceptible to length extension attacks.

md5(T + K) should be fine for most uses unless your adversary is motivated to tamper with your message and has very good computing power. As long as you control T, birthday attacks are not applicable and you only have brute-force attacks. But it is good to be aware of the limitations. If you want to go with this approach you may want use SHA1(T + K) instead of MD5.

md5(T+K) is certainly better than md5(K+T) where an attacker may append text to your message and generate another valid MAC.

With md5(T+K), the issue is that if an attacker can find a collision with T2 such that md5(T) = md5(T2), then md5(T+K) = md5(T2+K). But this requires a brute-force attack.

Note: I say "as long as you control T", because if changes can be made to T (in such a way that it is not obvious) one can try to generate 2 messages T1 and T2 where T1 can pass for T and md5(T1) = md5(T2). Now this is relatively lot easier to do (we are talking 2^64 instead of 2^128) and the reason is the so-called Birthday paradox or Birthday attack.

Note: The design of HMAC was motivated to avoid these kinds of extension attacks. There are no known attacks against HMAC.

B T
  • 57,525
  • 34
  • 189
  • 207
Babu Srinivasan
  • 2,339
  • 23
  • 24
  • 1
    1: There are collision attacks on MD5 far faster the usual birthday attack. 2: There are plenty of theoretical attacks on HMAC-MD4 and HMAC-MD5 (which usually means a practical attack is on the horizon; you should be using at least HMAC-SHA-1). 3: `MD5(K + T + K)` seems preferable to both T+K and K+T, and it also makes bruteforcing slower (with `MD5(T + K)` where T is long, an attacker can precompute the hash state for T and simply iterate over K, which might be an order of magnitude speedup). – tc. Mar 06 '12 at 16:53
  • Collision attacks, where you find two arbitrary inputs with same hash, are not germane here. OP said that he has *a text T and a key K*. Here pre-image resistance applies, which for md5, is practically not much different from brute-force: 2^128. OP wanted to know advantage of using HMAC over just hashing. I replied that "HMAC is not susceptible to length extension attacks" and also "you may want use SHA1(T + K) instead of MD5." As HMAC RFC 2104 says "The cryptographic strength of HMAC depends on the properties of the underlying hash function" and so HMAC-SHA1 would be preferable over HMAC-MD5. – Babu Srinivasan Apr 07 '12 at 10:06
  • 1: My point was that the birthday bound is still quite high; the latest attacks on MD5 are *much* more efficient. Also note that there's a (theoretical) preimage attack on MD5, but attacks only get better. 2: I think it depends on what you mean by an "attack on HMAC". RFC 6151 also says "the practical impact [of attacks on HMAC-MD5] on HMAC usage as a pseudorandom function ... is not well understood. ... for a new protocol design, a ciphersuite with HMAC-MD5 should not be included." My point is that MD5 should always be discouraged unless the implementer is fully aware of the vulnerabilities. – tc. Apr 10 '12 at 18:44
  • 1
    A really nice example of the "susceptible to extension attacks" point is given in this explanation. http://dev.ionous.net/2009/03/hmac-vs-raw-sha-1.html look for "_but please don't call me anymore_" – Rhubarb Apr 18 '16 at 18:28
29

The Wikipedia article on HMAC gives a good explanation of this.

In the Security section of the same article it goes on to say:

HMACs are substantially less affected by collisions than their underlying hashing algorithms alone.

So adding an HMAC to an MD5 hash would make it substantially more difficult to break via a rainbow table.

Martin
  • 37,119
  • 15
  • 73
  • 82
Evan M
  • 2,573
  • 1
  • 31
  • 36
6

I would recommend reading the HMAC papers by Bellare, Canetti, and Krawczyk.

Zed
  • 3,387
  • 19
  • 14