# Why is AES not a Feistel cipher?

I am studying for an exam right now. And I wanted to make sure I got this point correct.

AES is not a Feistel cipher because the operations in AES are not invertible.

Is the above statement correct? If not, why isn't it a Feistel cipher?

-
If the operations were not invertible we wouldn't be able to decrypt anything. Read the links in Reid's answer and try to memorize the schematics and what a Feistel network looks like. That's very different from a simple sub-perm network (link also in Reid's answer). A Feistel cipher is a cipher that uses a Feistel structure in its design - AES does not. –  rath Sep 28 '13 at 6:36
@rath you would not be able to decrypt anything if the cipher was not augmented with a mode that only requires one way encryption such as CTR mode –  owlstead Sep 28 '13 at 12:51
@owlstead Good point. [+1] –  e-sushi Sep 29 '13 at 7:10

Well, AES is not a Feistel cipher because it's a substitution-permutation network instead. If I were taking a test that asked me why AES was not a Feistel cipher, this would be my argument: namely, that the structure of substitution-permutation networks is fundamentally different from that of Feistel networks. (Here one could elaborate on invertibility and other differences.)

That said, your statement is not correct. In a Feistel cipher, the round function is not necessarily invertible (DES's round function is not), but in AES, like any substitution-permutation network, the rounds are invertible. This is a property of the construction itself.

-

By definition, a Feistel network uses a series of rounds that split the input block into two sides, uses one side to permute the other side, then swaps the sides. As always, Wikipedia has a nice diagram.

AES doesn't do this. Performing a round necessarily permutes the entire state. Each round consists of the SubBytes, ShiftRows, MixColumns, and AddRoundKey steps, none of which behave in a Feistel network-like manner:

• SubBytes performs byte-wise substitution from a constant table, no byte's value influences another byte's permuted value.
• ShiftRows permutes 4-byte words at a time using only those 4 bytes, no byte from another word influences their permuted output.
• MixColumns permutes 4-byte words at a time using only those 4 bytes, no byte from another word influences their permuted output.
• AddRoundKey is a permutation using the derived round key, no byte's value influences another byte's permuted value.

So only the ShiftRows and MixColumns steps even allow a byte to influence the permutation of any other bytes in the state, and in both of those steps a given byte only influences the permutation of other bytes when it itself is also being permuted.

None of that matches the "split the block into A and B and use A to permute B" style of a Feistel network.

-