3
$\begingroup$

Why is Rijndael restricted to key length in $\lbrace 128, 160, 192, 224, 256\rbrace$ bits (and not larger)? The algorithm looks to me like it would support an arbitrary-sized key (multiple of $32$).

The rounds operate without the key. Between rounds, the state is XORed with as many key bytes as are needed according to the block size. The key generation process is dependent on the number of rounds, which is dependent on key size, so growing a key triggers a process that uses the key data.

I heard Dr. Eric Cole mention something about this like 10 years ago when first I took one of his classes which covered a "101" into to crypto. We were talking about how AES is replacing DES (triple DES, whatever) and he told us about basically said that Rijndael has variable key lengths. He didn't say specifically, but I took him to mean arbitrary. If I recall corrected he said that because of this feature we'd be using it for a long long time to come. He also talked about all the fun he had attending the NIST AES contests, but now I'm off topic. Does anyone actually know?

$\endgroup$
  • 5
    $\begingroup$ Probably because the designer didn't see a point in supporting keys larger than 256 bits. It's not like a conventional computer will ever brute-force 256 bits, and even with a quantum computer it's pretty expensive. $\endgroup$ – CodesInChaos Sep 5 '14 at 8:44
8
$\begingroup$

The key schedule uses constants that differ between the key sizes. For arbitrary sized keys you would have to define an algorithm for deriving them. Each key size also uses a different number of rounds, for which you would have to do the same.

Also, what's the point? 256-bit keys are enough for all eternity. Using a longer keylength variant would likely just introduce a false sense of security.

If AES gets broken, it is IMO unlikely that such an attack would break a 256-bit key variant without also breaking an e.g. 512-bit variant with an equal number of rounds. The main exception would be if there was something wrong with the key schedule for one, like the weaknesses in the 256-bit variant, but in that case a less studied longer key variant would be even more of a risk.

$\endgroup$
  • $\begingroup$ Even a weak key schedule is only a problem if the key is attacker-controlled or otherwise used in a non-recommended way. A fully uniform, random key should be fine even if the key schedule is a lot weaker than we thought. $\endgroup$ – forest May 28 '18 at 2:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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