AES key expansion vs. a hash

Question

Is there something special about the AES key expansion algorithm that makes it secure, or it is a compromise between security and speed? For example, say with a key I expand it by taking pbkdf2(key) or scrypt(key) as the next round, and scrypt(scrypt(key)) as the round after that, until I have all of my subkeys. Would this be more or less secure than the standing key-generation method, and preferred in the case of having a machine which can perform them both in the same amount of time (impossible I know, but it's hypothetical).

Often I hear the key expansion is the weakest part of AES, but conflictingly that it was designed to prevent the use of "weak keys" which its predecessor suffered from.

Answer 1

Often I hear the key expansion is the weakest part of AES, but conflictingly that it was designed to prevent the use of "weak keys" which its precedent suffered from.

The terms "weak" here mean different things.

Some of the best attacks on AES have been oriented at attacking the key schedule. When these attacks were released the cryptographic community was not too surprised because the key schedule had seemed like one of the easier attack vectors from as far back as the original AES competition. If you consider the AES algorithm as a whole, the key schedule is an easier component to craft attacks against, making it a weak point of the algorithm.

However, "weak keys" as a phrase has a specific meaning. It refers to keys that, for their respective algorithms, provide abnormally poor encryption properties relative to the other keys. For example a DES key of all 0s or all 1s is considered weak. AES does not have any such weak keys, all keys are expected to perform equally securely.

Answer 2

The AES key schedule is firstly very fast, and build from a component (the s-box) that is used in the main encryption algorithm, too, so it can be implemented easily, sharing code (in software) or chip area (in hardware).

I'm not sure how the AES key schedule avoids "weak keys" – I suppose this is meant to say that every AES key, when expanded, contains "random-looking enough" bits that the actual encryption function sufficiently perturbs the plaintext to the ciphertext.

Using a real pseudo-random function (or even more, a slow one like scrypt) would work, too (though you wouldn't chain scrypt, but use it only once to generate the full key output size – its output size is configurable), and likely would not introduce more vulnerabilities.

But it would be terribly slow, and speed is an important criterion for a block cipher selection.