Galois Finite Fields and the Advanced Encryption Standard (AES)
cs.uaf.edu
cs.uaf.edu
Back in the day it was tractable to build AES lookup tables for computing MixColumns and SubBytes similar to the site's multiplication table. Then djb found a remote timing attack, so processors started implementing hardware AES instructions.
It is worth mentioning that in modern AES usage this feature does not really matter, because block cipher is used in CTR mode. In CTR block cipher is used to create long keystream bytes (pretty much one-time-pad key). This keystream gets xor'ed with plaintext to get ciphertext. Then getting from ciphertext back to plaintext is exactly the same xor operation with same keystream, no inverse AES operations needed.
CBC with a block cipher has been completely obsolete for decades, even if the huge inertia of cryptography software development has kept it in use in many places, even until today.
However, CBC has a descendant that is still useful. CBC is a derivative of CFB, from which it differs only in the place from which the output is extracted from the encryption automaton.
There is another derivative of CFB, where the block cipher function with a secret key is replaced by a wider bijective mixing function, where the output is extracted by truncation. Here the role of the secret key is played by the part of the state that is not extracted in the output and the encryption automaton obtained thus is equivalent with a CFB mode for a block cipher where the key would be changed after each block. The fact that no 2 blocks are encrypted with the same key eliminates all security problems of the traditional CBC/CFB.
Only the fact that encryption and decryption are not parallelizable is a disadvantage, but this is partially mitigated because integrity verification is a byproduct that is provided without additional expenses (by extending the string to be encrypted with a block of known content).
This mode of operation is what the team Guido Bertoni, Joan Daemen, Gilles Van Assche and Michaël Peeters has called "duplex encryption for sponge functions".
While that team has contributed many important things to the progress of cryptography, I hate that they have always coined a great number of new names for old things, and always without mentioning at all the correspondence between their new names and the old concepts that had been used for decades before them.
Their initial contributions from 2007 to 2012 were all about what is obtained when in all those of the classic modes of operation that were known by 1980 in which the inverse of the block cipher is not needed, one substitutes the block cipher with a truncated wide mixing function (in the Shannon sense), but for all of those they have invented new fancy names, like "sponge absorbing" (derived from CFB-MAC), "sponge squeezing" (derived from OFB), "donkeySponge" (derived from the Alred optimization of CBC-MAC) and the like.
Encryption is also used for other purposes, e.g. communication between private devices or data storage, for which other modes of operation have significant advantages.
Such as?
Encrypting UUIDs in a database?
ISO 9564-1 PIN encryption?
The current dominant AES-GCM mode of operation is the consequence of the broken US IP laws and its supremacy is not determined by technical reasons.
That said, for Internet communication AES-GCM is sufficiently close to the optimum that there is no need to replace it (by sufficiently close I mean that its speed is only very slightly slower and the probability of not detecting forgeries is only very slightly higher).
However, the better modes of operation require the inverse of the block cipher function.
Nonetheless, if one wants an even better security and the block size is extended to 256 bits, due to another historical accident, the definition of the Intel and ARM AES instructions is such that for extended block sizes the decryption would be slower than encryption (the reason is that the decryption instructions are not the inverses of the encryption instructions, as they should have been).
This misfeature can be avoided by not using the decryption instructions, which is possible if the block size is not extended as in the original AES definition, but by using a Feistel structure where the 128-bit AES instructions modify alternatively the 2 halves of a block.
So it is possible to implement both the direct and the inverse form of a 256-bit block cipher function, with equal throughputs, by using only the encryption AES instructions. Such a 256-bit block cipher function can be used in any mode of operation, including in those that require its inverse.
Wouldn't it be equivalent to polynomials of degree less than n (up to n−1)?