Re: [cryptography] HMAC over messages digest vs messages
On 2011-11-02, Jack Lloyd wrote: It seems like it would be harder (or at least not easier) to find a collision or preimage for HMAC with an unknown key than a collision or preimage for an unkeyed hash, so using HMAC(H(m)) allows for an avenue of attack that HMAC(m) would not, namely finding an inner collision (or preimage) on H. Agreed, and in general this seems like yet another version of the repeated crypto is automatically safer fallacy. That has already been discussed in the past, more than one time. -- Sampo Syreeni, aka decoy - de...@iki.fi, http://decoy.iki.fi/front +358-50-5756111, 025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] HMAC over messages digest vs messages
On 11/02/2011 06:13 PM, Jon Callas wrote: 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. Sure, I completely agree: I would have simply kept it at the basics (i.e. using an HMAC on the data). I am going over somebody else's design and came up with this which I found weird and wanted to double check if it was in fact non-standard or just something I wasn't aware of. Cheers, Lea.- -- Leandro Federico Meiners ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] HMAC over messages digest vs messages
Hi List! I was wondering if anybody could give me some pointers as to papers or books that discuss the advantages/disadvantages of computing an HMAC of a message versus previously computing a hash of the message and then calculating the HMAC of the hash. My initial thoughts are that there isn't any additional security provided by either method. What about calculating the HMAC of the message concatenated to the hash? This seems more secure but I have no idea how to prove either statement. Any helps is greatly appreciated. Cheers, Leandro.- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] HMAC over messages digest vs messages
On Wed, Nov 02, 2011 at 04:25:30PM -0300, Leandro Meiners wrote: Hi List! I was wondering if anybody could give me some pointers as to papers or books that discuss the advantages/disadvantages of computing an HMAC of a message versus previously computing a hash of the message and then calculating the HMAC of the hash. My initial thoughts are that there isn't any additional security provided by either method. It seems like it would be harder (or at least not easier) to find a collision or preimage for HMAC with an unknown key than a collision or preimage for an unkeyed hash, so using HMAC(H(m)) allows for an avenue of attack that HMAC(m) would not, namely finding an inner collision (or preimage) on H. Consider, for instance attacking HMAC-MD5(m) vs HMAC-MD5(MD5(m)). -Jack ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] HMAC over messages digest vs messages
On 11/02/2011 02:33 PM, Jack Lloyd wrote: It seems like it would be harder (or at least not easier) to find a collision or preimage for HMAC with an unknown key than a collision or preimage for an unkeyed hash, so using HMAC(H(m)) allows for an avenue of attack that HMAC(m) would not, namely finding an inner collision (or preimage) on H. That also goes for length extension attacks, something that HMAC is sometimes used specifically to prevent. HMAC(k, m) is much better than HMAC(k, H(m)). - Marsh ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] HMAC over messages digest vs messages
On 2011 Nov 2, at 12:25 , Leandro Meiners wrote: Hi List! I was wondering if anybody could give me some pointers as to papers or books that discuss the advantages/disadvantages of computing an HMAC of a message versus previously computing a hash of the message and then calculating the HMAC of the hash. My initial thoughts are that there isn't any additional security provided by either method. What about calculating the HMAC of the message concatenated to the hash? This seems more secure but I have no idea how to prove either statement. Any helps is greatly appreciated. Cheers, Leandro.- If I have two documents that collide under the hash function, calculating the MAC over the hash of the documents would allow me to substitute one for the other without the MAC changing, even though I don't know the MAC's key. But calculating the MAC directly on the document almost certainly wouldn't collide, nor would an attacker (who doesn't know the key) be able to calculate collisions offline. Greg. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] HMAC over messages digest vs messages
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 situation. 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. Jon ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
