# In AES Keyschedule : Infer all round keys and cipher key from last round key

I am given the last round key in AES and I want to infer all round keys and the first round key which is the cipherkey.

Can anyone provide an algorithm to do that?

• What's the key size? For AES-128, it's easy. – poncho Jul 31 '17 at 15:45
• @poncho I'm supposed to be able to deal with 128, 192 and 256 bits keys. But first, let's deal with 128 bits keys :) – SebMa Jul 31 '17 at 15:59

For AES-128, it's easy (that is, so easy that there are hardware AES implementations that, in decrypt mode, just store the last round key, and derive all the other subkeys, including the first one, on the fly).

Let us treat the expanded key as a series of 32 bit words $w, w, w, w, ..., w, w, w, w$, there $w, w, w, w$ are the 128 bit AES key, and $w, w, w, w$ is the last round key.

Then, the key expansion process is defined as $w[i] = w[i-4] \oplus F_i(w[i-1])$, where $F_i$ is a simple function that involves possibly sending the inputs through the sbox, and xoring in the round constant. Starting with $w, w, w, w$, this allows us to efficiently compute the rest of the $w$ array.

So, if we rewrite this as $w[j] = w[j+4] \oplus F_{j+4}(w[j+3])$ (which we get by setting $j = i-4$ and rearranging), then, starting with $w, w, w, w$, we can compute $w$ using this formula, and then work our way backwards through the key schedule, ending with the initial values.

For AES-192 and AES-256, it's actually pretty similar, except that you need more information than the last round key (which makes sense; there are only 128 last round key bits; not enough information to recover the full 192 or 256 bit key). However, if you have the last 6 $w$ elements (for AES-192), or last 8 elements (for AES-256), the same logic works.

• Can you please give the code for the function Fj+4(x) ? – SebMa Jul 31 '17 at 16:33
• @SebMa: it's the same $F$ function that's used during the forward-direction key generation process. – poncho Jul 31 '17 at 19:28
• Are you not sure that j = i - 4 instead ? – SebMa Aug 1 '17 at 12:20
• @SebMa: oops, you are correct; I'll go ahead and fix it. – poncho Aug 1 '17 at 12:23
• If I want to consider 192 or even 256 bits keys, I guess I must use $j = i - Nk$, right ? – SebMa Aug 1 '17 at 12:49