[Cryptography] A Fun Trick: The Little MAC Attack

[Ray Dillinger]

On 05/08/2015 07:37 PM, Phillip Hallam-Baker wrote:
> On Thu, May 7, 2015 at 8:14 PM, Dan Kaminsky <dan at doxpara.com> wrote:
>> Practical HMAC-MD5 Collisions!
>>
>> Not that they should ever matter...
>>
>> http://dankaminsky.com/2015/05/07/the-little-mac-attack/
> 
> There is actually a mode where they could matter. There exist
> applications where a MAC is used as the digest for a signature. This
> enables a mode where the signature can only be verified by someone who
> knows the secret without the loss of non-repudiation that a straight
> HMAC entails.


So this common construction for message authentication codes,
which with vector2 = 0x363636... and vector1= 0x5c5c5c....
constitutes the usual definition of HMAC:

   hash(key XOR vector1) XOR hash(key XOR vector2 XOR message)

allows the ability to create collisions in the hash to be extended
to the ability to create collisions in the MAC, when the attacker
knows the key.

I don't see any significant damage here; if the attacker knows
the key, the point of a MAC function (particularly a symmetric
MAC function in which knowledge of the same key needed to verify
the MAC is the requirement for generating a bogus MAC) is hosed
anyway.

I have never understood, though, why the above form is preferred
to the more straightforward construction:

    hash(Encrypt(key, message))

.  The only reason I know why the first form was EVER preferred
has to do with crypto export regulations back in the bad old
days when, in certain contexts, certain authorities permitted
hash functions to be part of exportable software but not
encryption functions.

Why it would still be preferred today is a mystery.

				Bear



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20150509/2738851e/attachment.sig>