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
