After 20 years of AES, what are the retrospective changes that should have been made?

Question

I realize that this could be very opinion based, but I feel that there should be some solid information on AES at this point that could be referenced. After 20 years, I expect that there should be a "woulda, coulda, shoulda" list somewhere. For instance, I suspect that one could have gotten away with two fewer rounds, which would still have an acceptable security margin, but would this increase the speed of the cipher significantly.

Is there a comprehensive retrospective on AES in literature now that it has been used for 20 years?

Answer 1

Nobody seems to need a 192 bit version, we can do fine with just AES-128 and AES-256. Having a key that's 1.5 times the block size is a nuisance (or 0.75 times the block size if the block size is doubled).

A version with a larger block size, such as 256 bits, would be very welcome, since it would reduce the likelihood of block collisions and improve efficiency when processing large volumes of data. This capability is already defined in the original Rijndael specification so it would be easy to adopt.

The key schedules of AES-192 and AES-256 are vulnerable to attack; we could do with a better key schedule where even these attacks are avoided. They don't have much influence when the cipher is used for confidentiality, but we could do without those attacks regardless.

And while we're expanding the block size and fixing vulnerabilities to the key schedule anyway, we might as well make it suitable as underlying cipher for a cryptographic hash function and make it a tweakable block cipher.

Answer 2

I don't think that saving rounds to increase speed is necessary. On machines with AES-NI (which is most today), it takes less time to encrypt in AES than it does to read from memory. There are rare cases where the time to encrypt is too slow.

One change that I think should have been made is to also standardize a larger block size. Although 128 bits seems very big, in a standard CTR/GCM mode of operation with a 96-bit IV, you can only encrypt $2^{32}$ different messages safely. There are other solutions, but a larger block size would be a simple and better long term solution.

Answer 3

A serious issues with AES is its sensitivity to timing and cache side-channel attacks in many portable pure-software implementations, due to the hard-to-avoid table lookups (exceptions: bitsliced implementation, CPUs without a data cache, CPUs with AES-NI, some slow code). An ARX cipher (in the sense of using only additions, rotations/shifts, and XOR; e.g Serpent) would avoid this cleanly, while remaining compatible with all CPUs. I think (in retrospect) it would have been a better choice.

Having a 256-bit block would be nice, and simplify a safe choice of IV.

Answer 4

All AES candidates due to specification were Pseudo-Random Permutation (PRP), however, today we don't need a PRP. We can live with a Pseudo-Random Function (PRF) since the CTR mode is designed for PRFs. CTR modes don't need the reverse operation as CBC. This can reduce the area/time cost of implementations.

As an example; the ChaCha is a PRF and turned into a cipher with the CTR mode. It is based on add-rotate-XOR (ARX) operations - 32-bit addition, bitwise addition (XOR), and rotation operations.

All of the cipher suites in the TLS 1.3 (AES-GCM, AES-CCM, and ChaCha20) use CTR mode. The bonus; no padding oracles.

Using AES (PRP) in GCM and CTR has a long message distinguisher and therefore we need to restrict the number of encryption blocks due to the PRP-PRF switching lemma.

So I can say, a PRF with 256/512-bits block size and 128/256/512 key and 128/256 IV sizes. With this, we can live without IV collisions and long message problems. Plus, 32/64 bit CPU friendly design.

Bonuses;

• No padding oracles
• There is no need for a key schedule as in ChaCha
• No need for a separate decryption circuit.
• CPU friendly.
• Possibly an ARX - fast, cheap, and easy constant-time implementation on SW/HW.