# By using a block cipher multiple times in a row is a 128-bit BC as secure as a 256-bit BC which uses his 128-key only as part of the message?

For given 128-bit numbers $$S$$ and $$E$$ we want to find a series of keys $$k_i$$ with $$E = BC(BC(BC(.....BC(S, k_1),k_2) ..k_n)$$

• We can either use a 128-Bit blocksize block cipher similar to AES (ECB mode) with $$BC(m_i,k_i) \equiv AES(m_i,k_i)$$
• Or a 256-Bit blocksize block cipher similar to AES (like Rijndael, not AES256!) with $$BC(m_i,k_i) \equiv TakeOnlyLast128Bit[RIJ_{256}([k_i\space m_i],0)]$$ with a fixed key of $$0$$. The 128-bit key used is part of the block itself. This wont't have a symmetric key anymore. The first 128-bit part of $$RIJ_{256}([k_i\space m_i],0)$$ would serve as key for the inverse direction.

In each step we can change the key as we like (for 2nd case the first part of the block).

Question: Would any of those 2 options be significant faster in finding a suitable set of keys?

Both can be solved with meet-in-the-middle-attack by starting at the start $$S$$ and the end $$E$$ at the same time until some match occurs. For 128-bit $$S,E$$ this should have an expected BC calculation count of $$\approx 2^{64}$$.
Or is any of those 2 significant slower/faster? (we ignore the different round count here)

• I think that if you take seriously the design principle of confusion and diffusion [1] , and assume that the algorithm is a good approximation to that ideal, it follows that the role of the plaintext and the key should be indistinguishable with regards to producing the resulting ciphertext. Since you also ignore the number of rounds, my feeling is that there shouldn't be any complexity difference between both methods, but this is a somewhat handwavy argument, perhaps someone can come up with something better. [1]en.wikipedia.org/wiki/Confusion_and_diffusion
– Amit
Jan 31 at 19:32