2
$\begingroup$

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

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.

Improve this question
$\endgroup$
5
  • 2
    $\begingroup$ 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. $\endgroup$
    – Maarten Bodewes ♦
    Jun 7, 2021 at 11:32
  • 2
    $\begingroup$ @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. $\endgroup$
    – Tarick Welling
    Jun 7, 2021 at 11:48
  • 1
    $\begingroup$ 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 $\endgroup$
    – Fractalice
    Jun 7, 2021 at 14:18
  • 2
    $\begingroup$ @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 $\endgroup$
    – Tarick Welling
    Jun 7, 2021 at 14:34
  • 2
    $\begingroup$ This seems to be answering the question. If that's the case, @Fractalice could you make an answer out of your comment? $\endgroup$
    – Maarten Bodewes ♦
    Jun 8, 2021 at 9:27

1 Answer 1

Reset to default
1
$\begingroup$

Are you sure round is getting decreased? The counter reminds the decryption setting. You also probably missed the AddRoundKey somewhere. Otherwise the description looks correct.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.