
The Little MAC Attack - jessaustin
http://dankaminsky.com/2015/05/07/the-little-mac-attack/
======
sdevlin
> 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!

~~~
dakami
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.

~~~
tptacek
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.

~~~
dakami
You're right. I'm specifically referring to his attacks.

I'm curious if you can find any references to the key expansion / hashing
collision before Solar Designer started talking about it a little while ago.

If they're obvious you should be able to find dozens of references. Because
they're obvious.

~~~
tptacek
This took 15 seconds to find:
[https://eprint.iacr.org/2012/684.pdf](https://eprint.iacr.org/2012/684.pdf)

------
mckiddy
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.

~~~
jessaustin
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.

~~~
tptacek
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.

------
oldmanjay
> (!= is nerd for Not Equal.)

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

~~~
ekimekim
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).

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

