8

A 2DES like cipher $c=E^{(2)}_{K_2}(E^{(1)}_{K_1}(p))$ where both halves have an $n$ bit key is vulnerable to a meet-in-the-middle attack.

Meet-in-the-middle using a big table

Create a table containing $E^{(1)}_{K_1}(p)$ for all possible $K_1$ and computing $D^{(2)}_{K_2}(c)$ for all values of $K_2$, looking for a matching result.

This approach requires a big table with about $2^n$ entries.

Meet-in-the-middle using cycle finding

An alternative approach would be to define a hash function that maps an $n+1$ bit value to another $n+1$ value:

Use $1$ bit of the input to decide between $E^{(1)}_{K}(p)$ and $D^{(2)}_{K}(c)$ and the remaining $n$ bits as key for this function.

A collision of this hash function can either have the same discriminator bit, in which case it's useless for our purposes, or different discriminator bits, in which case it's a successful meeting.

Now search for collisions of this hash function, applying the usual memory reduction techniques like cycle-finding and/or distinguished points. This should require only around $2^{n/2}$ table entries instead of $2^{n}$ table entries, while increasing computation cost only my a small constant factor.

Does this approach work?

Artjom B.
  • 2,045
  • 1
  • 22
  • 52
CodesInChaos
  • 24,841
  • 2
  • 89
  • 128
  • It would help to name the block width of $E^{(1)}$ and $E^{(2)}$, say $b=64$ in the case of DES; and state how from these $b$ bits we determine the $n+1$ bits kept for the iterated function, which is not trivial. – fgrieu Apr 26 '15 at 12:53
  • In the simplest case we could truncate. If we need a tweak to repeat the whole experiment with a different hash function (not sure if that's required) we can use any kind of tweakable hash (preferably a cheap one) 2) I don't think the block-size matters at all with most modes of operation (including ECB, CBC and CTR). We simply need a long enough known plaintext/ciphertext pair.
  • – CodesInChaos Apr 26 '15 at 13:08
  • Yes, it works. It's a standard trick; kudos for re-discovering it. I see no reason the table size would amount to $2^{n/2}$. The complications in working out exact parameters arise when you work out the details of (a) parallelism, (b) distinguished points, (c) the cost of memory and routing networks, to get the exact optimal tradeoff (if you care about constant factors). – D.W. Apr 27 '15 at 07:10
  • Working on a prototype implementation, I noticed that my assumptions about how iterated hashes cycle were wrong. I didn't know that a few cycles and their tails dominate. – CodesInChaos Apr 27 '15 at 09:44