AES-128 takes a 128-bit key (four 32-bit words), and expands it to a 352-bit key schedule (11 words). Speck48/72 takes a 72-bit key (three 24-bit words), and expands it to a 528-bit key schedule (22 words). Key expansion is an extremely popular practice, but I can’t figure out why.

Why not instead use a longer key without any processing—a full 352 bits, 528 bits, whatever is required, of entropy? It’ll be longer and a tad more unwieldy, sure, but that doesn’t seem like a problem to me: for all but the lightest-weight ciphers in the most extremely resource-constrained implementations, surely the difference is negligible, and a longer key would be more secure, and initialisation should be faster too since no processing is required.

In typical round-based block ciphers, I don’t think there are supposed to be any particular properties of the round keys—my impression is that a good key schedule function is just about diffusion, and sure completely random round keys are even better than that.

Am I missing something?

(This is mildly related to Security importance of Key Schedule in Block Cipher, but it’s decidedly a different question.)

  • 2
    $\begingroup$ This means you have to generate more random, store, and transfer it. You need very long passwords for a password-based key generation or ridiculously increased DHKE modulus sizes. $\endgroup$
    – kelalaka
    Commented Jun 16, 2022 at 16:52
  • 3
    $\begingroup$ In addition, hardware AES implementations hate long keys, and would prefer expanding keys as needed (potentially on the fly) $\endgroup$
    – poncho
    Commented Jun 16, 2022 at 17:09
  • $\begingroup$ @kelalaka: hmm, I wasn’t thinking about those cases, but assuming fully random keys generated ahead of time in controlled environments (since that’s the situation I’m dealing with and I haven’t had to deal with situations like you describe); in that situation, generating and storing more randomness isn’t an issue. As for key exchange, doesn’t seem to me like that’d be a problem—you could split the key up into chunks. $\endgroup$ Commented Jun 16, 2022 at 17:11
  • 1
    $\begingroup$ ( more memory, more time, more electricity) = more money. More DHKE round, that is again more time and calculation. Intel will hate it on AES-NI. Also, see What are the requirements of a key schedule? $\endgroup$
    – kelalaka
    Commented Jun 16, 2022 at 17:15

1 Answer 1


There are a few reasons for this. First, the goal of a cipher is to be as secure as possible with the smallest key size. The AES key schedule, although simple, is sufficient for expanding the key into all necessary round keys. Other block ciphers use other key schedules. The requirements are fairly modest. Some block ciphers use very complicated and slow key schedules, whereas others use relatively fast but more fragile key schedules. Either one is better than having no key schedule.

Second, a good block cipher has a flat keyspace. This means that no bits are more important than any other bits, and all keys are equally secure. If the master key is simply longer and is split up into each round key as you suggest, then it would not have a flat keyspace. Certain keys would be less secure than others. For example, a 128-bit block cipher with 10 rounds that takes a 1408-bit key (10 rounds usually require 11 round keys) could be vulnerable to a slide attack if that 1408-bit key is made of repeating 128-bit values (i.e. the same 128-bit value is used for each round). You could get around this by demanding that the cipher only be keyed with a randomly-generated key, but then you're placing limitations on the use of the cipher, which is a bad thing. You could use a PRNG to generate all the key material and merely seed it, but then you've just re-invented the key schedule!

Third, the only reason to use a larger key would be to increase the total keyspace (i.e. the number of possible keys) to make brute force attacks more difficult. A 256-bit key is more than enough and increasing the size of the key is simply unnecessary. If the key size really needed to be increased, it would be easy enough to do so without getting rid of the key schedule.

Finally, some ciphers have a large number of rounds. Threefish has up to 80 rounds and a block size of up to 1024 bits. Round keys are added every four rounds and before the first round totaling ~21.5 KiB of key material, and using a key of that size would be utterly impractical. A cipher that uses many rounds does so because each round is weaker and provides less security than each round in a cipher that requires fewer rounds but achieves the same security. There is no reason for the size of the key to be influenced by the design choice of using many weak rounds or few strong rounds.

  • $\begingroup$ Comments are not for extended discussion; this conversation has been moved to chat. $\endgroup$
    – forest
    Commented Jun 17, 2022 at 22:28
  • $\begingroup$ Plus the practical side of a short-ish key, like being able to drop the key in some config file as N3ekPhOGmJNrHC4Upwy2Mg== or 3777a43e138698936b1c2e14a70cb632 instead of some multi-kB monstrosity? $\endgroup$
    – ilkkachu
    Commented Jun 19, 2022 at 19:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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