I'm not a cryptologist, just an interested engineer (& now retired). I used to design hardware with AES en/decryption blocks & generate test vectors using my own Tcl script using the embedded aes function.

However, I was wondering if modifying AES to use more than 1 SBox (& inverse), it would be "more secure", or is that not the case? I've found 1108 SBoxes that meet the original criteria (out of 256! possible combinations). My view would be to have a short table to indicate which SBox to use for each round of 14 (assuming 256 key). I realise this would complicate h/w a bit, but not be very complicated to modify a C program. Initially just using 2 SBoxes, the original & one other, but easily expandable to use 3,4.. etc in software.

Just after thoughts really.

  • 3
    $\begingroup$ AES has a very regular structure that enables it easy to analyze. That is a design change that will complicate the security analysis. It was a nice question for DES since the NSA modifications and people wondered about the resasons. $\endgroup$
    – kelalaka
    Dec 29 '20 at 17:54
  • 1
    $\begingroup$ Also it wouldn't be AES. AES is a standard. If you change it, it ceases to be AES, it's some other cipher. Possibly a Rijndael variant, possibly something entirely different. There's no such thing as "AES with other SBoxes". It's like "US 2020 issue one dollar bills with faces other than George Washington", they don't exist, and can't exist, since they wouldn't meet the criteria of being 2020 issue US one dollar bills! $\endgroup$ Dec 29 '20 at 18:28

Honestly, it would be more secure, but not by much, and that is assuming you are using finite field inversion s-boxes.

A better use of multiple 8-bit s-boxes would be to make them key dependent, however in software that can have the unfortunate side effect of creating another side channel to leak information about the key.

If you want something based on the AES design but with small modifications that make it more secure, what you want is not more s-boxes, but a better s-box with more algebraic complexity. In terms of round design that is probably the only modification you can make before it strays too much from the original design.

The other place to look is the key schedule, which is very simple and fast. This is both beneficial and detrimental, as it is probably the weakest point of the cipher, but makes applications requiring key changes usable. Think a wifi chip that needs a different key for each connected device and needs to constantly switch keys to communicate with them. It can also "roll" to save memory on embedded systems, but this means that round subkeys can be used to recover the key.

From a software only perspective, security can be improved with changes to the key schedule, slowing it down and generating the subkeys using a one way function with less linearity.


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.