The Little MAC Attack

http://dankaminsky.com/2015/05/07/the-little-mac-attack/

by jessaustin • 11 years ago

52 27 11 years ago

dankaminsky.com

oldmanjay2• 11 years ago

(!= is nerd for Not Equal.)

made me laugh out loud. how many not-nerds would have made it that far?

ekimekim• 11 years ago

I could feasibly see a mathematician understanding all this but not being familiar with that symbol, which is mostly used in programming (math prefers a ≠ b instead of a != b).

oldmanjay2• 11 years ago

good point, I paid more attention to the code listing than anything else so in retrospect, I hadn't really considered that.

dakami8• 11 years ago

It's the crazy little things that people don't understand. You can't spell tax, without syntax.

dakami8• 11 years ago

Er, syntax without tax. ANYWAY

sdevlin3• 11 years ago

And yet. This is novel

No.

EDIT: I've been told to elaborate.

This is just direct fallout from the way Merkle-Damgard hash functions work. MD hash functions look like this:

    function MD(C, h, M):
        M <- pad(M)
        for m in blocks(M):
            h <- C(h, m)
        return h

The core of an MD hash is the compression function C, which takes an input state h and a message block m and produces a new state. When you find a collision in an MD hash function, you're really finding a collision in C. That is, some state h and some pair of message blocks m1 and m2 such that C(h, m1) = C(h, m2).

Now, HMAC. HMAC is defined over a hash function, and it looks like this:

    function HMAC(H, k, M):
        k1 <- ipad ^ k
        k2 <- opad ^ k 
        return H(k2 || H(k1 || M))

Where "||" is the concatenation operator. A simplified view of HMAC is that the key is used to scramble the initial state of H. This prevents the attacker from finding collisions on the inner hash function, because they don't know any interior state h. (The outer hash prevents length-extension attacks.)

Which makes this article pretty silly: the whole point of HMAC is that the attacker doesn't get to know interior hash states. It pretty much goes without saying that if a) an attacker can find collisions on H for arbitrary states h and b) they know some interior state h of the HMAC, then it follows directly that they can find collisions on the HMAC.

Hey, want to see some more practical "attacks" on HMAC? Here we go!

    In [11]: HMAC(b'\x00', b'chili dog', sha256).hexdigest()
    Out[11]: '3128a12ed7dd6cd4ad9d2720126698d1c0c3e2d991ddbf73ebbecd947581acd9'

    In [12]: HMAC(b'\x00\x00', b'chili dog', sha256).hexdigest()
    Out[12]: '3128a12ed7dd6cd4ad9d2720126698d1c0c3e2d991ddbf73ebbecd947581acd9'

Whoaaa, what?! Again!

    In [17]: HMAC(sha256(b'A'*500).digest(), b'chili dog', sha256).hexdigest()
    Out[17]: '426b6ec9b0e6b5fae9d12924432c023e8bc3444aa3adc4c48fdc875357c54c2f'

    In [18]: HMAC(b'A'*500, b'chili dog', sha256).hexdigest()
    Out[18]: '426b6ec9b0e6b5fae9d12924432c023e8bc3444aa3adc4c48fdc875357c54c2f'

Oh nooo! HMAC!

sarciszewski4• 11 years ago

I especially like the second one, because it's less obvious even to someone used to breaking apps with null bytes. :)

sdevlin3• 11 years ago

The two collision examples I used both rely on the key expansion step in HMAC, which I glossed over in my explanation. If you go look up the HMAC spec, it should be pretty clear why these work.

dakami8• 11 years ago

It's novel in that I wasn't able to find anyone else who had posted a colliding HMAC pair, and the couple papers people have found have sniffed around but hadn't quite gotten to the point of "Oh, yeah, compensate for ipad and collide after the first block".

You're correct that it went without saying in that people did not actually say it.

Way to not cite Solar Designer though.

tptacek6• 11 years ago

What exactly should he have cited Solar Designer about? If you're going to criticize someone for not citing, and the citation isn't obvious, you should probably provide a link.

Are you referring to the key expansion property that Scott mentioned downthread? He cited the appropriate source: the HMAC specification. The properties he's talking about are obvious: the key is zero-padded to the block size and, if longer than the block size, hashed.

dakami8• 11 years ago

I stand corrected, there are in fact a decent number of people who mentioned HMAC(K,X)==HMAC(H(K),X) when len(K)>blocksize. So, you had no reason to cite Solar Designer and I shouldn't have implied you should. Sorry about that!

Still interested if you can find an earlier cite for HMAC collision. Most of what I find implies mad crypto cleverness, not this silly little construction.

mckiddy• 11 years ago

If you know the HMAC key, why would you ever need to generate a collision? You can just reevaluate the MAC and replace the old one.

tptacek6• 11 years ago

Yup.

"This almost certainly doesn’t have any security impact, but I’m happy(ish) to be proved wrong."

There's a few words I'd remove from that sentence, I guess.

sdevlin3• 11 years ago

SNARK REDACTED

jessaustin• 11 years ago

I think the point was that if some dumb protocol were misusing HMAC (and I'm not good enough at thinking about protocols to imagine how it might do so), it could be vulnerable to collisions generated this way.

tptacek6• 11 years ago

The point of the parent commenter is that a misuse of HMAC that gives attackers knowledge of the key admits much simpler attacks than this.

The Little MAC Attack

Related Stories