home products company partners clients news careers contact us
aes modes background

Modes of AES
background information

Modes of AES - a short backgrounder

As stated previously, a "mode" is used to change the behaviour of the underlying block cipher (in this case AES), so that it has more useful properties. Modes are therefore a powerful way to enhance security, alter the behaviour of encryption in the face of data errors, or even to provide authentication instead of (or in addition to) encryption.

Why do we need to use modes?

In cryptographic terms it is possible to just push your plain data through the AES algorithm to yield encrypted cipher data directly. This is called ECB mode (standing for "Electronic Code Book"), and would use the basic AES core without additional logic as the bare core implements ECB mode. However, ECB mode is almost never used in real applications, mainly because if you put the same data through twice without changing the key, you get the same encrypted data every time. This is a significant security weakness, so in most cases measures must be taken to avoid this situation. The way we do this is to put some "history" into the process, usually in the form of some feedback around the AES algorithm, which ensures that repeated plain data doesn't produce repeated cipher data.

What mode choices do we have?

There are various ways to achieve this addition of history, and these are termed "Block Cipher Modes". They are standardised, and differ mainly in the detail as to where and how the feedback is introduced. Common modes include CBC (Cipher Block Chaining), CFB (Cipher Feedback), OFB (Output Feedback) and CTR (Counter Mode). Each mode has subtly different behaviour in the presence of data bit errors, or synchronisation errors between the two ends of the link, and these differences often dictate the choice of mode to be used....unless of course your application is aligned to a standard which specifies the mode you must use.

There are newer modes available which not only offer modified behaviour, but also change AES into an authentication algorithm, or even a combined encryption and authentication scheme, (for example AES-CCM and AES-GCM). Special requirements can also be fulfilled using more advanced mode techniques, for example in the case of disk encryption where none of the basic modes fit the needs (see AES-XTS for more details on this).

These advanced modes are obviously more complex than the simple feedback modes listed earlier, but offer powerful solutions based on AES. You will see these modes used in many new standards, and we can offer highly efficient implementations of these algorithms based on our well proven AES engines.

What is an Initialisation Vector (IV)?

Any mode which includes feedback or some kind of internal "state" to cover up repeated data, generally requires an Initialisation Vector (IV) to be provided. This can be viewed as being the initial value of the feedback or state before any data has been processed - kind of a "pre-history". To start the encryption of a new stream or message, you will need to feed an associated IV into the encryption process, and the same IV will need to be made available to the decryptor when that same message is decrypted.

Typically the IV need not be kept secret, as knowledge of it does not compromise security, so it is often transmitted unencrypted along with the encrypted message, or it may be derived locally from some information known to both ends of the link, for example a timestamp or message ID.

The various modes have differing requirements for their IVs; for example CTR mode requires that the same IV is never used twice with the same key, so steps must be taken to ensure that repeated IVs never get used.

Some modes require an IV for encryption, but you can choose not to bother transmitting that IV to the decryptor, if you can live with losing the first block of decrypted data. Modes which self-synchronise have this characteristic, often needing no framing for cryptographic synchronisation or additional bandwidth to transmit explicit IVs.

How can Helion help?

Helion AES cores can be configured to support any mode of operation, and we can guide you through the often tricky 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.

For further information on specific mode support, please follow the links from the mode table on our AES modes page.

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.


Copyright © Helion Technology Limited, 1998-2014. All rights reserved. Privacy and Cookies
Web Site Developed by Goldstag Limited