Would adding more rounds to AES increase security?

Question

As the title states, would increasing the rounds by doubling them to Bruce Schneiers recommendation of 16, 20, and 28 increase security? And how much?

As a bit more, would increasing rounds, keys, blocksize, or almost everything increase security?

Answer 1

Would adding more rounds to AES increase security?

Not really.

The cheapest known attacks on AES today are essentially generic key searches. That is, they don't really depend on the details of AES itself. If you increased the number of rounds, that would slightly raise the cost of testing each key, but it would also raise the cost of using your AES variant. Raising the number of rounds doesn't meaningfully affect the cost of generic key searches.

With fewer rounds, there may be shortcuts to attacking AES that do depend on the details of AES itself. But the number of rounds we settled on two decades ago seems to have held up quite well. If someone suddenly came up with a new brilliant idea for a cheaper-than-generic attack on AES that eluded the world's best crypanalysts for two decades, maybe more rounds would thwart that, but that's all.

As a bit more, would increasing rounds, keys, blocksize, or almost everything increase security?

In principle, assuming no specialized attacks, increasing the key and block size does increase security in the following senses:

• The cost of an attack on AES-128 can be much less than $2^{128}$ AES evaluations—specifically, an adversary attacking a batch of $t$ different AES keys need only spend cost proportional to $2^{128}\!/t$ to find the first key.

  That's why you should use AES-256, not AES-128, for a ‘128-bit security level’ against all adversaries (including quantum adversaries). This one is an easy choice for you to make.

  (If AES-256 is too costly in software, maybe you should use Salsa20 or ChaCha instead, and really an authenticated cipher like crypto_secretbox_xsalsa20poly1305 or ChaCha/Poly1305, which as a bonus avoids timing side channels that plague software implementations of AES. But you should also measure measure measure.)

• The block size of a permutation like AES affects the birthday bound for protocols, which is why Sweet32 hurts 64-bit block ciphers much more than 128-bit block ciphers no matter what the key size is—an adversary's advantage at breaking an application that handles $q$ blocks of data of $b$ bits apiece is usually around $q^2\!/2^b$. A 128-bit block size makes Sweet32-type attacks much harder to pull off. But the birthday bound of around $2^{64}$ blocks is still within the realm of feasibility—for example, the Bitcoin network today computes more than $2^{64}$ SHA-256 hashes every second.

  If AES had a 256-bit block size, then the birthday bound would be around $2^{128}$, which is so large you never have to worry about it. But it doesn't. The original Rijndael proposal supported 256-bit blocks, but they weren't included in AES as adopted by NIST. There's no easy choice you can make here without using a nonstandard AES variant that has received relatively little scrutiny—which means it is more likely to have specialized attacks cheaper than generic key searches that we don't know about.

  (Again, maybe consider using crypto_secretbox_xsalsa20poly1305 or ChaCha/Poly1305 so that you don't have to worry about the AES block size either!)