0

I'm really having some trouble with this one.

Let $H$ be a MAC function. For every key $K$ we can create an unkeyed hash function (i.e.an MDC) by using $H$ to hash messages with the fixed key $K$. We denote this unkeyed hash function by $H_K.$ (Note that every key $K$ gives a different hash function $H_K$. Therefore, we can create a large family of MDC functions from a single MAC function, one for each key).

Show that if $H_K$ is not collision resistant, then $H$ is not computation resistant for every key $K$.

Make your argument as clear as possible.

kelalaka
  • 48,443
  • 11
  • 116
  • 196
countduckula
  • 61
  • 2
  • 4
  • Well I am sure that I am required to prove that if there exists M, M' s.t. HK(M)=HK(M') IS computationally feasible (not collsition resistant) then this implies --> given M, MAC(K,M) (one message -mac pair) and M' it is computationally possible to compute MAC(K,M')

    Now we know if HK has a n-bt output we can find a collsion after check 2^(n/2) and I am guessing I need to use the fact one one could perform a meet in the middle attack the M and MAC(K,M) which again you would have to check 2^(n/2) ?

     – countduckula Nov 13 '18 at 12:48
  • HK is not collision resistant means that you can find a collision, no need to go birthday attack. Now assume that you find a collision. – kelalaka Nov 13 '18 at 13:02
  • Well, HK is not collision resistant so we expect a collision [HK(M)=HK(M')] after hashing 2^(n/2) inputs (birthday paradox). Thus we have found for Key K two Messages that have the same hash value. and therefor these messages when pumped through the MAC with Key K will have the same MAC value? – countduckula Nov 13 '18 at 13:04
  • Yay :) no it doesn't however I do have a Q that says an attacker can perform 10^21 hach operations a second, how many years would it take to perform a brute force birthday attack on SHA-256. I put 2^128/(10^21x60x60x24x7x52) which is ~ 1.8 billion years. I wasn't sure about this as this seems like a huge number – countduckula Nov 13 '18 at 13:22
  • See a computation about reaching $2^{63}$ here. and stay on the question line. And post your answer when ready. – kelalaka Nov 13 '18 at 13:27
  • 1
    On the off topic calculation: well, you're some 2.25 billion days off (or more if you consider the slow down of the earths' rotation), but don't let that stop you :). – Maarten Bodewes Nov 13 '18 at 14:16
  • I don't know what "computation resistant" means. This is not a standard term. If it means that the MAC is not secure, I'm actually not at all sure that this is even correct. (The fact that I can find a collision given the key does not mean that I can find one with only black-box access to a MAC oracle.) Am I missing something? – Yehuda Lindell Nov 13 '18 at 17:06
  • @YehudaLindell, not the definition but the usage I found here. And if we think that forging, then directly a collision produces a forging? – kelalaka Nov 13 '18 at 17:13
  • OK, so computation resistant is "unforgeable" in the standard sense. I still don't see why the question is correct. Assume that I can find a collision in every H_K when given K. This doesn't mean I can find a collision in the MAC game when I don't have K. – Yehuda Lindell Nov 13 '18 at 17:22
  • @YehudaLindell Why not, let $m_1 \neq m_2$ be two messages such that $HK(m_1) = HK(m_2)$ (i.e. collision) then $H_K(m_1) = H_k(m_2)$, right? And this question waits your comment too – kelalaka Nov 13 '18 at 19:20
  • Because how do you find $m_1,m_2$ that collide? I'm assuming you can find them when you KNOW $K$ (since it's a fixed-key hash function and so you know $K$). In the MAC experiment, you don't know $K$. – Yehuda Lindell Nov 13 '18 at 19:32
  • @YehudaLindell am I missing something? The question is: if HK is not collision resistant, then I can assume that I can find and show that result? – kelalaka Nov 13 '18 at 19:57
  • But you need to know HK, and you don't. You only have oracle access to the MAC oracle. – Yehuda Lindell Nov 13 '18 at 20:07
  • @YehudaLindell that is the point that I don't see. maybe you write the problems and hint in the answer? – kelalaka Nov 13 '18 at 20:15

1 Answers1

2

By my read of the question, I don't see why this is even correct. It does depend on how one interprets that "H is not computation resistant for every key K". I assume that this just means that $H$ is not computation resistant for a randomly chosen key $K$. Otherwise, I'm not sure what it would mean.

According to this understanding, I don't see why the statement is true. From here on, I will use the term "a secure MAC" rather than "computation resistant", since this is more standard terminology.

Now, the straightforward way you would try to prove this is to find a collision in $H_K$ and use this to break the MAC. However, the fact that $H_K$ is not collision resistant for a fixed $K$ means that when you are given the function description, you can find a collision. However, this doesn't mean that you can also do it when you are not given the function description. To be very concrete, define $H_K$ as follows. Parse $K$ into a key for a PRF and into the description of a group where the discrete log is assumed to be hard, along with a generator $g$ and random value $a$ and value $h=g^a$. The function works by first hashing the message using $hash(x_1\|x_2)=g^{x_1}\cdot h^{x_2}$ (using Merkle-Damgård based on this compression function, you get a full-blown hash function) and then applying the PRF. Now, if you know the value $a$, then it's easy to find collisions. Thus, $H_K$ is not collision resistant for any fixed key, since in the fixed-key setting you know $K$. However, in the standard MAC setting where you don't know $K$ and so don't know $a$, this will be a secure MAC (under the assumption that the discrete log problem is hard in this group).

So, I must be misreading the question somewhere. Either there is something in the quantifiers with the "for every key $K$" that I am misreading, or the intention of what a fixed-keyed hash function is is different to what I understand. Or there's an error in the question...

In any case, I wrote this out in detail since I think it has value.

Yehuda Lindell
  • 27,820
  • 1
  • 66
  • 83