Why is there no AES-512 for CTR & variants to have good large nonces?

Question

AES-CTR and authenticated variants tend to have a 'problem' with lacking bit real-estate for nonce & counter.

Why hasn't an AES-512 variant been standardized at some point? It would allow moving the nonce into the AES key.

Answer 1

AES is a subset of the functions defined within the Rijndael specifications. The Rijndael specifications which allows block sizes between 128 and 256 bits and key sizes between 128 and 256 bits, all with 32 bit increments. AES only allows block sizes of 128 bits and key sizes of 128, 192 and 256 bits. The value at the end of the name is the key size as that is the only parameter that may differ for AES. So AES-512 would be AES with a 128 bit block size and a key size of 512 bits. The text of the question does make clear that this distinction is known, but the existence of higher block sized versions of Rijndael may not be.

A block cipher with a block size of 128 bits is a permutation of 128 bit values. Basically that means that you set a key and everything else is provided through the block operation. In principle it is possible to split a 512 bit key into a key section and an IV section of - for instance - 256 bits each. This is not common because keys and IV's are often handled differently : an IV can be public while the key needs to be secret.

Another issue is that the key length is usually close to the strength against bruteforcing the algorithm given a key. That means that AES-512 would signal to an unsuspecting user that it would have near 512-bits of security. This would however not be the case if part of the key consists of the IV as that is considered to be public information. It would depend on the cipher definition if it could offer 512 bits security because it would also require to increase the internal state size and likely the number of operations used within the cipher.

---

If you want you could use Rijndael-256-256 or even Rijndal-256-128 where the block size is the first parameter and key size is the final parameter in the name. Another way of doing things is using a Keyak variant. Keyak is based on the Keccak sponge function used in SHA-3 and SHAKE and allows for a variable sized nonce as it is just absorbed by the sponge together with the key and data. [Edit: Sorry, I forgot to mention the XChaCha20 cipher which has a 192 bit nonce size and is fast in software].

The main trouble is that NIST unfortunately hasn't standardized any of these modes, which also means that implementations may be lacking. For instance, it seems to be possible to somewhat accelerate Rijndael-256-256 but AES-NI is geared towards the 128 bit block size.

Answer 2

Because AES is standardized around Rijndael with 128 bit blocks. In order to use larger "state" (ie nonce and counter combination) you need a block cipher with a larger block size. Unfortunately there is no NIST standardized block cipher that has a block size larger than 128 bits. In theory you could try using AES in a wide block cipher scheme but as far as I am aware, no such scheme has been NIST standardized as well.

That's not to say there isn't talk about potentially standardizing the Rijndael cipher with a 256 bit block size. There has been discussion on the NIST ciphermodes forum about this. It would make things cryptographically easier (i.e. you can have larger nonces and counter blocks) and wouldn't be as hard to standardize compared to a new dedicated block cipher. It would also be able to take some advantage of preexisting AES support such as the AES-NI instruction set on all supported x64 processors.

Answer 3

AES has a weak key schedule. Such that extending the key size even further is inadvisable. There are related key attacks on 256bit keys which don't work on 128bit keys.

I would just replace the AES key schedule entirely with the one from SHA256 - there are CPU instructions for that nowadays too. It would also then accept 512 bit keys.

Alternatively, you can use Rijndael-256 (256 bit block size) while still using AES-NI:

It would go some ways to mitigate the problem you listed.

It's also possible to reuse the AES round function or just the s-box for a different primitive or to augment an existing one such as chacha20:

Source for the slides: https://csrc.nist.gov/csrc/media/Presentations/2023/constructions-based-on-the-aes-round/images-media/sess-5-gueron-bcm-workshop-2023.pdf