11

It is known that setting the secret key to a fixed, public value does not make MACs like CBC-MAC or GMAC into secure unkeyed cryptographic hash functions that could be used - for instance - for digital signatures.

In other words, the resulting hash function is not 1st pre-image, 2nd pre-image, and collision resistant.

What are the MACs that do not suffer from that limitation? I believe HMAC is one of them, provided the underlying unkeyed hash is strong.

Are there any others?

EDIT: if the hash used for HMAC is broken, also the HMAC constructed with it will probably be so.

SquareRootOfTwentyThree
  • 1,755
  • 12
  • 17

2 Answers2

3

I have ask as part of my answer, "What problem are you trying to solve?"

Do you want a secure unkeyed hash function? If you do, then there are plenty of them around. Even some of the ones that are broken for some uses might be okay for yours (SHA-1 springs to mind -- note the discussion above on HMAC and how broken a hash function has to be). But really, you ought to look at SHA-256, SHA-512, or the new SHA-512/t construction.

If you don't like that, look at any of the SHA-3 finalists. (Full disclosure, I'm the co-author of Skein.)

You're right that HMAC is one of them -- but that's basically the null statement. HMAC is a wrapper around an unkeyed hash function that strengthens it against a number of attacks (and adds a key). If you remove the key (or make it a constant), then all you have is a function with two iterations of a hash function with a bunch of frosting and sprinkles over it. It is obvious that if you start with a secure hash function, make a secure MAC and then remove the key then that you will end up with a secure hash function.

What are you really asking? What do you really want to do?

Jon

Jon Callas
  • 2,371
  • 15
  • 15
0

As pointed out by others, MAC systems based on hash functions can trivially be made back into hash functions by making the key a public constant. E.g. $hash(msg) = HMAC(key_{const}, msg)$.

It's also possible to convert MAC systems based on ciphers into hash functions but the lack of a secret key needs to be compensated for. If the message is not longer than the authentication tag then a simple xor between them works, otherwise some compression function is needed so that they are the same length, e.g. $hash(msg) = CBCMAC(key_{const}, msg)\oplus compress(msg)$. This ensures that an attacker cannot decrypt the output even with the correct key if they don't know the message. Important however that the compression function doesn't lose too much information from the message. Trucation, for example, which discards everything except for the first chunk of the message, would be unsuitable as a compression function, and xor-folding which xor:s together each chunk of the message into one chunk, ensuring that all parts of the message affects the output, would be at least a little bit better. One could of course use a secure hash function as compression function but that defeats the purpose of a construction based on a MAC since you might as well just use that instead then.

Unfortunately, I don't know enough about universal hash functions to say if or how MAC systems based on them could be turned into regular secure hash functions.

n-l-i
  • 1,084
  • 5
  • 15