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

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.