Is this an acceptable way to increase the block size of a block cipher?

Question

Note: This is all for fun and learning. None of this will go into production code.

I'm studying something (sponge functions, specifically) that benefit from large block sizes. AES has a (comparatively) small block size of only 128 bits. Is this a safe construction for increasing the block size?

$E(x)$ and $D(x)$ are encryption and decryption in ECB mode respectively. The size of the input $b_0$ is a multiple of the cipher's block size. The encryption proceeds as follows.

$$c_n = E(b_{n-1})$$ $$b_n = shift(c_n)$$

This is repeated once for every blocksize chunk in the input. For example, encrypting a 512-bit block with AES (a 128-bit block cipher) will take 4 rounds, so the output will be $b_4$.

Decryption is a simple reverse of the above algorithm.

$$c_{n} = shift^{-1}(b_n)$$ $$b_{n-1} = D(c_{n})$$

$shift(x)$ is defined as lining up the blocks vertically and shifting each row by an amount corresponding to it's row. All operations are done on the byte level. It is similar to ShiftRows in AES.

For example, with a block size of 8 (bytes) and an input of aaaaaaaabbbbbbbb12345678, $shift$ would proceed like this.

ab1 <-- shift by 0            = ab1
ab2 <-- shift by 1            = b2a
ab3 <-- shift by 2            = 3ab
ab4 <-- shift by 3 (equiv. 0) = ab4
ab5 <-- shift by 4 (equiv. 1) = b5a
ab6 <-- shift by 5 (equiv. 2) = 6ab
ab7 <-- shift by 6 (equiv. 0) = ab7
ab8 <-- shift by 7 (equiv. 1) = b8a

The resulting output would be ab3ab6abb2ab5ab81ab4ab7a.

The intention is to diffuse it enough to make sure every plaintext bit has an effect on every ciphertext bit.

Are there any major flaws I'm missing here?

Answer 1

The purpose of a mode of operation for a block cipher is to get rid of the size limitation imposed by the block size, so what you're proposing is to use an insecure mode, tweak it to try to hopefully make it secure, and finally build a new block cipher with this... At the cost of 4 AES encryption to achieve diffusion (whereas the MixColumn and ShiftRow operations in AES try to achieve the same diffusion at a much lower cost.) So I'm not convinced by the performance of your block cipher and don't see why it is superior to, say, AES-CBC with a fixed 512 bits size.

Now, what flaw are you possibly missing?

Well, since you are using AES ECB, if your plaintext is for example a repeating block of 128 bits, it will get encrypted into the same AES block by AES ECB, which means that your Shift operation will do nothing, since all of its row will be filled with a repetition of the same byte:

111 <-- shift by 0            = 111
222 <-- shift by 1            = 222
333 <-- shift by 2            = 333
444 <-- shift by 3 (equiv. 0) = 444
555 <-- shift by 4 (equiv. 1) = 555
666 <-- shift by 5 (equiv. 2) = 666
777 <-- shift by 6 (equiv. 0) = 777
888 <-- shift by 7 (equiv. 1) = 888

which means that you'll end up with a block of multiple AES-ECB encryption of the exact same blocks, which will give you interesting patterns in your ciphertext, and leak information, so you do not achieve the ciphertext indistinguishablity one would expect from a secure block cipher.

Which basically means that "No, this is not an acceptable way".

Could you tweak it further to avoid this problem? Most likely, but if you want to build bigger block cipher, you can as well just build a bigger AES and have better performance than stacking multiple AES on top of each other.
Should you? IMHO, no. Stick with secure AES constructs such as CBC, CTR, GCM, etc., or use a secure stream cipher such as ChaCha.