RCON for AES 192 and 256

Question

This is question about how many RCON values are used in AES 192 and 256.
I read the NIST Publication introducing AES and in Appendix A.2 and A.3 (Key Expansion for 192 and 256-bit keys), only $rcon_1$ to $rcon_8$ were used for 192 bits and upto $rcon_7$ for 256 bits. My question is how can only 7 or 8 values of $rcon$ be used when we have more rounds in AES 192 and 256.
To my understanding, $rcon$ is used every round so should't we have more $rcon$ values (owing to the increased no. of rounds in AES192 and 256) instead of less?

Answer 1

I've got a response from Vincent Rijmen. Here's the complete response:

rcon is used in the computation of the roundkeys. AES192 and AES256 have less iterations of the roundkey computation, since each of these computations produced more than 128 bits of roundkey material. That’s why we need less rcon values.

Paŭlo Ebermann's great answer gives some details in ASCII images, here I will try to explain this in a different way.

• AES-128 key schedule uses 4 32-bit word columns for 11 round keys that need 10 rcon values.
• AES-192 key schedule uses 6 32-bit word columns for 13 round keys that need 8 rcon values.
• AES-192 key schedule uses 8 32-bit word columns for 15 round keys that need 7 rcon values.

The extra round key is for the initial round key which is XORed with the plaintext.

• In AES-192: the 13 round keys need 52 32-bit words. Using 6 32-bit words with 8 rounds produces keys for 13.5 rounds, a little more than necessary. The first and half of the second is the key itself.

• In AES-256: the 15 round keys need 60 32-bit words. Using 8 32-bit words with 7 rounds produces keys for 16 rounds, more than necessary. The first two are the key itself.

Answer 2

I have been trying to understand and implement AES in a project and came across this. I know it is an older post, but I did not see an answer that DIRECTLY answered the question. After doing some digging and wrapping my head around this, here is the simplest answer I could come to:

Regardless of the length of the key used in AES (128, 192, 256), the data is encrypted using 16-byte blocks. Because of this, the key expansion requires more rounds to produce a sufficient number of bytes for encryption as the key length is reduced. The key length for AES-128 is 16 bytes, for AES-192 is 24 bytes, and for AES-256 is 32 bytes. From here, explicitly the number of rounds is:

(key expansion rounds) = (block bytes) * (encryption rounds) / (key length)

• For 128: (16 * 11) / 16 = 11 (key expansion rounds) for 176 bytes
• For 192: (16 * 13) / 24 = 8.667 (key expansion rounds) for 208 bytes
• For 256: (16 * 15) / 32 = 7.5 (key expansion rounds) for 240 bytes

This is how the higher-level encryption requires LESS rcon values, i.e. key expansion rounds, versus the lower-level encryption.

Answer 3

You have 10, 12, and 14 rounds respectively; however, they are not linear increments depending on the key schedule. For AES-192, you have 8 different values and you have 7 values for AES-256. The RCON value only changes with every round for AES-128.

The RCON value (in hardware) is generated by a register that is 8-bits and increments every round. It wraps around with the count, and left alone for encryption, you'd get:

0: 00000001 
1: 00000010 
2: 00000100 
3: 00001000 
4: 00010000 
5: 00100000 
6: 01000000 
7: 10000000 
8: 00011011 
9: 00110110 
10: 01101100 
11: 11011000 
12: 10101011 
13: 01001101 
14: 10011010 

This is not what you'll actually use, but it's necessary to have a complete discussion. In the above list, for AES-128, you'd start at round 0, and the final round, 9 (the 10th round), you will have 0x36.

For AES-192 and AES-256, you end up skipping constants due to the key schedule. For AES-192:

0: 00000001 
1: 00000001 
2: 00000001
3: 00000010 
4: 00000100 
5: 00000100 
6: 00001000 
7: 00010000 
8: 00010000 
9: 00100000 
10: 01000000 
11: 01000000 
12: 10000000 

For AES-256:

0: 00000001 
1: 00000001 
2: 00000001
3: 00000001 
4: 00000010
5: 00000010 
6: 00000100 
7: 00000100 
8: 00001000 
9: 00001000 
10: 00010000 
11: 00010000 
12: 00100000 
13: 00100000 
14: 01000000 

You can implement this in many ways. The naive approach that you'd have in class, but is easy to follow (also, FPGAs would do this generally):

The way that I generally do it (note, this is encryption, you move tap 4 for decryption):

The clock control increments the value.