Modes of AES

Common AES Block and Stream Cipher Modes

How do Helion support modes?

The "classic" block cipher modes like CBC, CFB, OFB and CTR basically consist of feedback taken from various points around the AES engine, which is then applied back into the datapath using an XOR function. Helion offer full support for all these modes with a suite of "mode wrapper" reference designs, which efficiently implement these mode configurations around our AES cores. These single mode wrappers are supplied at no extra cost to our AES core customers on request.

Some applications require selectable multi-mode support, and Helion have special mode wrappers available which offer this enhanced functionality. Please contact Helion to discuss any multi-mode requirements in more detail.

The great advantage in supporting modes this way is that you don't have to live with "built-in" modes which you don't need. You can tailor your solution to reflect exactly what you need and no more, thereby saving logic in what may be an area critical application.

If you are not familiar with the concept of block cipher modes, please take a look at our AES modes backgrounder page where we explain all this in more detail.

An overview of the basic modes

ECB mode - Electronic Code Book

This mode is essentially the AES function without any feedback applied, so you put the plain data right through the AES function and use the resulting cipher data directly. Since repeated plain data encrypted using the same key will always yield the same cipher data, this mode is considered vulnerable and so is rarely used in practical systems. However, where simplicity is required plus maybe random access within a long encrypted stream, it is worth considering. Data can only be processed in blocks which match the block-size of the underlying encryption function (so 128-bit blocks on the case of AES), and synchronisation at this block level must be provided between the encrypting and decrypting engines, otherwise data will be indecipherable.

CBC mode - Cipher Block Chaining

This mode is a common mode used in many secure applications (eg. IPsec) where the data goes through the AES function, and feedback is applied to modify the pre-encrypted data, so that repeated plain data does not yield the same encrypted data. Data can only be processed in blocks which match the block-size of the underlying encryption function (so 128-bit blocks on the case of AES), and synchronisation at this block level must be provided between the encrypting and decrypting engines, otherwise data will be indecipherable.

CFB mode - Cipher FeedBack mode

This mode is a common mode, and offers the possibility of making an underlying block cipher work like a stream cipher; ie. so that the data being processed can be a stream of shorter values (for example bytes or even individual bits) rather than being processed only as much larger blocks. In CFB mode, the data itself does not go through the AES engine, but gets XORed with a value which the AES engine generates from previous message history. This means that the latency through the CFB function can be minimised, as the only processing applied to the data is an XOR function. Data widths can be set to any size up to the underlying cipher block size, but note that throughput decreases as the widths get smaller in the ratio of the data width to the block size. Synchronisation at the chosen data width level must be provided between the encrypting and decrypting engines, otherwise data will be indecipherable.

OFB mode - Output Feedback mode

This mode is a slightly less common mode, quite similar to CFB above, but which should not be used as a stream cipher due to inherent weaknesses when the data width doesn't match the blocksize of the underlying encryption algorithm. Again, the latency through the OFB function can be minimised, as the only processing applied to the data is an XOR function. Synchronisation at this block level must be provided between the encrypting and decrypting engines, otherwise data will be indecipherable.

CTR mode - Counter mode

This mode is a very common mode used in many secure applications where a blocksized count value is maintained, and encrypted, the result being XORed with the data to generate encrypted output. It is not necessary to use the full 128-bits of output, and so input data need not be padded up to the blocksize of the underlying encryption algorithm. As in the cases of CFB and OFB, the data itself does not go through the AES engine, but gets XORed with a value which the AES engine generates from the counter. This means that the latency through the CTR function can be minimised, as the only processing applied to the data is an XOR function. Encrypted data widths can be set to any size up to the blocksize of the underlying cipher, but obviously that throughput decreases as the widths get smaller. Synchronisation at the block level must be provided between the encrypting and decrypting engines, otherwise data will be indecipherable.

Summary of mode characteristics

Each mode has subtly different behaviour in the presence of data bit errors in the ciphertext or IV, or block synchronisation errors between the encryptor and decryptor, and these differences often dictate the choice of mode to be used. Furthermore, some modes only use an underlying encrypt function to support both encryption and decryption, whereas others require both encrypt and decrypt functions. Avoiding the use of a decryptor can save area, increase speed and reduce cost. In addition, some modes require that the data fed to them is an integer multiple of the cipher block size, and so require padding (and therefore subsequent message length growth), whilst other modes can work with arbitrary length messages.

The main characteristics of the basic modes are summarised below;

How can Helion help?

All the modes described above are fully supported by Helion's AES cores; please specify your choice at time of ordering to ensure that you receive the appropriate support. For further information on specific mode support, please follow the links from the mode table on our AES modes page.

Helion recognise that the choice of mode can often be a tricky one, so we can also help guide you through the process of deciding which is the best mode to use for your particular application. Unique amongst security IP vendors, we have many years of experience in designing real data security products as well as encryption IP, so we are well placed to advise on these kinds of issues; and of course this kind of additional support comes as standard to our customers.

Contact

For more detailed information on this or any of our other products and services, please feel free to email us at helioncores@heliontech.com and we will be pleased to discuss how we can assist with your individual requirements.