# Why have hashes when you have MACs?

It would seem to a naive eye that if you have a MAC, you have a hash function: use a key that all the parties know (such as all-bits-zero).

A potential application would be a resource-constrained platform where code size is at a premium, and which needs to implement AES for confidentiality: instead of also implementing SHA-2 for integrity verifications, it could use e.g. AES-CMAC.

Is there a reason not to do this? Is the existence of hash functions alongside MAC due to security? Performance? History?

-

In general, a MAC with a known fixed "key" is not a secure hash. That is, you can have a secure MAC (that is, someone without the key, but with a large number of message/MAC pairs, cannot come up with another valid message/MAC pair) that is not collision resistant, or even preimage resistant, if the attacker does know the key.

In addition, you don't have to come up with an artificial example to demonstrate it; AES-CMAC is not even preimage resistant if you know the key. This is easy to demonstrate; pick an arbitrary message that is a multiple of 16 bytes; then it is straight-forward to find the specific 16 bytes you need to append to make the CMAC come out to the 16 byte value you picked.

In addition, this isn't specifc to AES-CMAC; MACs based on univeral hashes also have this property. In fact, the only MACs (in common use) that I can think of which is actually secure as a hash with a public key would be HMAC (which, of course, is designed around a secure hash function).

Now, you mention the use of a hash as an "integrity verification"; if you're checking the integrity of a transmitted message (and use a secret key), a MAC is a perfect choice for this operation (and, in fact, a hash function might not work as well). However, if you need something which is actually collision resistant (e.g. as a part of a signature scheme), then a MAC with a fixed key may have serious problems.

-

Using the definition from rfc2014, I would guess that it ought to be possible to evaluate
HMAC with $\:1\hspace{-0.04 in}+\hspace{-0.03 in}\epsilon\:$ to $\:2\hspace{-0.04 in}+\hspace{-0.03 in}\epsilon\:$ times the amount of work needed to evaluate the hash.
From this answer, I would conclude that HMAC-MD5 would be cheaper to implement than SHA-256, and that HMAC-SHA1 would probably be cheaper to implement than SHA-256 on a 64-bit system.
From the definition, even when the adversary gets to choose the key, HMAC is at
least as collision-resistant as its hash, and a second-preimage attack on HMAC would
require something resembling a chosen-prefix second-preimage attack on the hash.

(Of course, the only reason to use HMAC like that rather than just it's hash
would be if one had an implementation of HMAC but not of the hash.)

I have no clue whether or not there is a cipher-based MAC
that offers anything against an adversary who knows the key.

-
(I also commented on the OP's other question.) $\;$ – Ricky Demer Aug 23 '13 at 18:53