Take the 2-minute tour ×

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.

share|improve this question
If the underlying hash of HMAC is secure, then I agree that using HMAC in this way should result in a secure hash. However, does using HMAC and a less secure hash (the HMAC construction may still be secure) in this way, still result in a secure hash? If that is the case, we have a way of construction cryptographically secure hash functions from less secure hash functions... –  MartinSuecia May 28 '12 at 10:07
My point being that I think your statement that "HMAC is one of them" is probably wrong. Since HMAC is simply a hash function iterated twice, any weaknesses in the used hash-function will shine through and be valid also for the resulting hash-function. Please correct me if I'm wrong. –  MartinSuecia May 28 '12 at 10:15
@MartinSuecia You are totally right. I edited the question. However, I believe an HMAC (used really as a MAC) can be more secure than the underlying hash. It really depends on how broken the hash is. To say, MD5 is broken, but HMAC-MD5 is not currently deemed to be so (although it is not a brilliant idea to use it for new designs). RFC6151 explains it better than I can. –  SquareRootOfTwentyThree May 28 '12 at 10:28
Yes, that's what I meant by "(the HMAC construction may still be secure)". Or do you mean that the resulting unkeyed hash, using your construction, may also still be secure? –  MartinSuecia May 28 '12 at 10:30
An attack on the hash does not automatically apply to the HMAC construction (used as an unkeyed hash). To say, the hash could be broken in that you can construct collisions for messages that follow a certain structure. If you cannot efficiently force the hash to produce digests according to said structure, the attack won't apply to the HMAC construction. So, IMO iterating the hash function twice might foil certain attacks the original hash function is subject to. –  SquareRootOfTwentyThree May 28 '12 at 12:20

1 Answer 1

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?


share|improve this answer
I ask the question for two reasons:i) Curiosity ii) To know the limitation of the MACs and avoid an error that quite often people tend to do. One practical reason could also be that sometime you don't have the luxury of having the whole crypto zoo available. In some constrained systems, you may only pick one or two primitives. A MAC that can be turned into a (non-standard) secure unkeyed hash is beneficial in those cases. –  SquareRootOfTwentyThree May 30 '12 at 4:30
The thing is, even in a limited environment, you are going to have either a MAC from symmetric encryptions, which cant be used for a hash... or you already have a hash function. In general, the "more primitive" type is the hash function, and MACs are hash functions with fluff. –  tylo Jun 21 '13 at 9:32

Your Answer


