Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'd like to understand a bit more about the AES key schedule if anyone would mind explaining that. For instance, why is the way the schedule generated (with recursive xors and occasional substitutions) more secure than say, using pbkdf2 on the key, then using it on the result, and on until there is enough data?

The reason I ask is because I'd like to experiment with an extended AES implementations, with more rounds, but need to devise a way to generate the extra sub keys.

share|improve this question

The AES key schedule isn't more secure than using PBKDF2 on the data -- but it is a lot faster, and requires many fewer gates in silicon. Performance is important.

As far as devising your own variant of AES, with more rounds: don't do that. There's no good reason to do that (it is exceptionally unlikely that AES is the weakest link in your system), and you can easily introduce subtle security vulnerabilities. Whatever problem you have that you think motivates this, modifying AES isn't the solution.

share|improve this answer

As D.W. said, the AES key schedule is not a pseudo-random function by itself, and certainly not more secure than something like PBKDF2 (with a hash function or MAC) or any other pseudorandom function. (There is saying that the key schedule is the weakest part in Rijndael/AES.)

It is meant to be fast, still a bit non-linear (so applications of the individual subkeys in each round don't somehow cancel out each other), and easily implementable (using even the same components as AES itself). In low-memory implementations, one can easily calculate the key schedule again for each encrypted (or decrypted) block on the fly, without really big performance-hits, which certainly wouldn't be possible with something like a big-factor slow hash function.

Note that any modification on AES will not be AES anymore. Using more rounds doesn't even give another Rijndael variant. Rijndael is a larger family of block ciphers with key sizes and block sizes each one of 128, 160, 192, 224 or 256 bits – the ones with block sizes 128 and key sizes of 128, 192 or 256 have been standardized as AES.

Rijndael uses a specified round count for the various block/key size combinations: Always $6 + \frac{\max(N_b, N_k)}{32}$ rounds (which comes to 10, 12 and 14 rounds for AES-128, AES-192 and AES-256). If you use more or less, your algorithm isn't Rijndael (and even less AES).

On the other hand, the Rijndael key schedule is flexible enough to produce an expanded key of any length, e.g. enough round keys for any number of rounds.

Have a look at my answers to How does the key schedule of Rijndael looks for key sizes other than 128 bit? and What are the practical difference between 256-bit, 192-bit, and 128-bit AES encryption? for a description of the key schedule. The schedule algorithm simply creates more subkeys from the previous ones, and thus can be simply repeated as long as needed.

Also the Rijndael encryption algorithm itself is modular enough so you can easily add more rounds – simply call the round function some more times, with additional subkeys, before the final round.

It is not clear at all whether this would improve security. It will hurt performance (though you should still be able to use the AES instructions in your processor), and it certainly will hurt interoperability. And most likely the block cipher will not be the weak point.

Don't do this for any production use, just like any homebrewn scheme.

And don't name the resulting algorithm AES or Rijndael – it isn't.

share|improve this answer
I think it makes some sense that adding rounds to AES would increase its security, as weaknesses have been reported on reduced round variants. Bruce Schneier did say "I suggest AES-128 at 16 rounds, AES-192 at 20 rounds, and AES-256 at 28 rounds." This might just be an off the cuff remark, but it's Schneier. – quantumSoup Dec 6 '12 at 0:08
@quantumSoup, yes, but Bruce also wrote: "choosing the number of rounds for a cipher is a combination of experience and guesswork. The AES rounds of 10, 12, and 14 were arbitrary, but represented the designers' best guess as to what would be secure. In my 2000 paper, I recommended increasing the number of rounds considerably, based on my best guess at the time. The round recommendations I gave above -- 16, 20, 28 -- are designed to restore AES's security cushion. They're off the top of my head, and certainly not the last word on the topic." – D.W. Dec 6 '12 at 3:37
The reason I asked this question is to clarify exactly how he had that in mind. Simply add more rounds and use the same key expansion algorithm, using more round constants? – Dakota West Dec 6 '12 at 21:27
@DakotaWest The round constants follow a simple scheme, and Wikipedia gives a table of all 255 of them. You'll need only $N_r + 1$ ones, if you have same block and key size. So extending the expansion is straightforward. – Paŭlo Ebermann Dec 7 '12 at 9:03

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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