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.
|
