Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It only takes a minute to sign up.
Sign up to join this community
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.
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.
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.
