Question

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?

Answer 1

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.