[cryptography] HMAC over messages digest vs messages
jon at callas.org
Wed Nov 2 17:13:22 EDT 2011
On Nov 2, 2011, at 12:59 PM, Leandro Meiners wrote:
> I thought of that, but I could not convince myself because it seems to
> depend on the particular application.
> For example, lets assume the following scenario: m is a message that it
> authenticated by the HMAC.
> For example, in the HMAC(HASH(m)) scenario, you might find a collision,
> however it might be gibberish and therefore useless. However, it might
> be that m lacks structure so that HMAC(m) might be the valid signature
> for two different messages m1 and m2 that both give the same m to be
> signed. In this case, the HMAC(HASH(m)) could save you from such a
> Nevertheless, I am not sure of how to factor this into the reasoning as
> there are probably cases where an example can be found the other way around.
> Am I making any sense?
I think I understand where you're going. However, in the general case, as Marsh and Greg have pointed out, there are length issues, etc. that you'd want to at the very least hash the length + the message. Very likely more tweaks are needed, too.
But I have to ask why you're bothering? The best way in the world to introduce a crypto flaw is to improve an existing, known construction. Really. Don't. If you don't have a specific problem you're trying to fix, or feature you need to enable, treat the standard set of constructions like a box of Legos. Just put them together, and you'll almost always be fine. When you're not fine, you'll have problems that lots of people will understand, too.
The construction you have, an HMAC of a hash, computes three hashes, as opposed to the HMAC proper which only does two. So it's slower. On the security axis, we're now tweaking your contraction to remove flaws that wouldn't be there if you just used an HMAC.
Ask yourself what problem are you trying to solve that HMAC doesn't solve? If you don't have a good answer to that question, just use an HMAC.
More information about the cryptography