# Is this a valid AES instruction reordering?

I'm trying to understand a verilog AES implementation. I know the order of the AES encryption steps to be as shown:

However the code I see doesn't do this. They do the following flow graph: at the beginning of the encryption state is loaded with newstate or the plaintext. The round is set to max and is decremented each round.

They then do the following set of operations for each round until round reaches 0. The internal variables are inside brackets and the operations are without.

(state) -> (sbbi) -> sbox -> (sbbo) -> shift -> (shro) -> mix -> (mxco)


They select the output of each round based on the round variable, this is used to set the newstate which sets the new input state:

if round == 0:
(state)
if round == max:
(shro)
else
(mxco)


The problem I'm having is I'm expecting to see the operations Sub, Shift, Keyadd for the last round (0 in this code). But that is not what it does and even taking the output of round 1 and seeing that as the 'last round' is wrong as that does a double key add.

• Can we presume that the AES code is running as intended (e.g. against another implementation / test vectors)? If I remember correctly the last round of AES is a bit different, I'm wondering if the diagram is correct, but I don't have the time to look it up right now. – Maarten Bodewes Jun 7 at 11:32
• @MaartenBodewes Yes when using this the ciphertext is checked and thus it works correctly. The last round is supposed to miss the Mix columns operation. The picture is from Understanding Cryptography by C Paar and identical pseudo code is given in the AES specification. – Tarick Welling Jun 7 at 11:48
• Are you sure round is getting decreased? maybe this is from the decryption setting? you also probably missed the add-key somewhere (hardcoded bitflips perhaps?). Otherwise looks legit – Fractalice Jun 7 at 14:18
• @Fractalice you are completely right. The encryption is done in the KEYSCHED state and not in the DECRYPT state (which I had interpreted as dual purpose with a terrible label). Thus the counter is indeed incrementing and thus the code is working as expected – Tarick Welling Jun 7 at 14:34
• This seems to be answering the question. If that's the case, @Fractalice could you make an answer out of your comment? – Maarten Bodewes Jun 8 at 9:27