Block Cipher Modes of Operation

and
the CMAC Mode for Authentication
Alberto Grand
December 20, 2007

Abstract
A block cipher is a symmetric key cipher which operates on fixed-
length groups of bits. Whenever the input plaintext exceeds the block
size, a so called “mode of operation” must be employed along with
the block cipher. A block cipher mode, or mode, for short, is an algo-
rithm that features the use of a symmetric key block cipher algorithm
to provide an information service, such as confidentiality or authenti-
cation. The first part of this article aims at outlining five NIST recom-
mended modes of operation which provide confidentiality (but do not
ensure message integrity): Electronic Codebook (ECB), Cipher Block
Chaining (CBC), Cipher Feedback (CFB), Output Feedback (OFB)
and Counter (CTR). The second part of the article focuses on a mes-
sage authentication code (MAC) algorithm based on a symmetric key
block cipher, the CMAC algorithm. The CMAC authentication mode
is also one of the seven modes which may be used with NIST’s ap-
proved encryption algorithms.

1
Contents
1 Cipher block modes of operation 3
1.1 Five confidentiality modes of operation . . . . . . . . . . . . . 3
1.1.1 Electronic Codebook (ECB) . . . . . . . . . . . . . . . 3
1.1.2 Cipher Block Chaining (CBC) . . . . . . . . . . . . . . 5
1.1.3 Cipher Feedback (CFB) . . . . . . . . . . . . . . . . . 7
1.1.4 Output Feedback (OFB) . . . . . . . . . . . . . . . . . 11
1.1.5 Counter (CTR) . . . . . . . . . . . . . . . . . . . . . . 12
1.2 Generation of Initialization Vectors . . . . . . . . . . . . . . . 15
1.3 Padding-related issues . . . . . . . . . . . . . . . . . . . . . . 15
1.3.1 Padding techniques . . . . . . . . . . . . . . . . . . . . 15
1.3.2 Ciphertext stealing (CTS) . . . . . . . . . . . . . . . . 16
1.4 Related-mode attacks . . . . . . . . . . . . . . . . . . . . . . . 18
1.4.1 Exploiting an ECB Oracle to attack the CTR mode . . 18
1.4.2 Exploiting a CBC Oracle to attack the CTR mode . . 18

2 The CMAC Mode for Authentication 19

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2 Cipher Block Chaining MAC (CBC-MAC) . . . . . . . . . . . 19
2.2.1 Description . . . . . . . . . . . . . . . . . . . . . . . . 20
2.2.2 Weaknesses . . . . . . . . . . . . . . . . . . . . . . . . 20
2.3 CMAC Specification . . . . . . . . . . . . . . . . . . . . . . . 21
2.3.1 Subkeys generation . . . . . . . . . . . . . . . . . . . . 21
2.3.2 CMAC generation . . . . . . . . . . . . . . . . . . . . . 22
2.3.3 CMAC verification . . . . . . . . . . . . . . . . . . . . 22
2.4 Security issues . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.4.1 Length of the MAC . . . . . . . . . . . . . . . . . . . . 23
2.4.2 Message span of the key . . . . . . . . . . . . . . . . . 24
2.4.3 Protection against replay attacks . . . . . . . . . . . . 25

References 26

2
1 Cipher block modes of operation
1.1 Five confidentiality modes of operation
1.1.1 Electronic Codebook (ECB)
The Electronic Codebook (ECB) is the simplest, and the most insecure, of
the five modes of operation hereby described. Each input block is processed
independently of all others. The algorithm lies, for each and every block,
in a permutation over the set of all input blocks. The term codebook is
used because, for a given key, there is a unique ciphertext for every block
of plaintext. Therefore, we can imagine a gigantic codebook in which there
is an entry for every possible plaintext pattern showing its corresponding
ciphertext.
This mode of operation requires that the input plaintext size be a multiple
of the block size; if this is not the case, padding must be added to the last
input block. Padding techniques, along with possible drawbacks, will be
furtherly discussed.
The mode of operation is defined as follows:

ECB encryption: Cj = CIP Hk (Pj )

Figure 1: ECB encryption.

ECB decryption: Pj = CIP Hk−1 (Pj )

Every block being processed separately, both encryption and decryption

can be carried out in parallel on different blocks; this is one of the few ad-
vantages, if any, of the ECB mode of operation. Because of this peculiarity
of the ECB mode, bit errors in a single ciphertext block only cause the cor-
responding decrypted block to be incorrect and do not affect other blocks. A

3
 Figure 2: ECB decryption.

single bit error in a ciphertext block may produce an error in any bit posi-
tion of the decrypted block, with an expected error rate of 50% (depending,
however, on the underlying block cipher).

On the other hand, identical plaintext blocks always get encrypted into
identical ciphertext blocks. This is a serious weakness of the ECB mode of
operation, because it results in data patterns being scarcely hidden. To some
extent, message confidentiality is even compromised. An example of how
ineffectively data patterns in the plaintext are handled is given in Figure 3.

(a) Original (b) Encrypted with ECB

Figure 3: ECB maintains data patterns.

Protocols which do not provide integrity protection are also more exposed
to replay attacks when the ECB mode is used.
The ECB mode is ideal for a short amount of data, such as an encryption
key. Thus, if we want to transmit a DES key securely, ECB is the appropriate
mode to use.

4
1.1.2 Cipher Block Chaining (CBC)
To overcome the security deficiencies of ECB, we would like a technique in
which the same plaintext block, if repeated, produces different ciphertext
blocks. The Cipher Block Chaining (CBC) mode of operation features the
combining (hence the word “chaining”) of each plaintext block with the pre-
vious ciphertext block by means of XORing. This way our requirement is
satisfied.
The CBC mode requires an initialization vector (IV), which is combined
with the first plaintext block. The IV does not need to be secret, but it
must be unpredictable and its integrity must be preserved; the generation of
IVs will be discussed later on. Like the ECB mode, the CBC mode requires
padding when the plaintext size is not an integer multiple of the block size
in use.
The mode of operation is the following:

CBC encryption: C1 = CIP Hk (P1 ⊕ IV )

Cj = CIP Hk (Pj ⊕ Cj−1 ) for j = 2...n

Figure 4: CBC encryption.

CBC decryption: P1 = CIP Hk−1 (C1 ) ⊕ IV

Pj = CIP Hk−1 (Cj ) ⊕ Cj−1 for j = 2...n

In CBC encryption, the input block to each forward cipher operation (but
the first one) depends on the previous encrypted block; therefore, it is not
possible to perform such operations in parallel. Each CBC decryption opera-
tion, however, only takes as inputs ciphertext blocks, thus allowing multiple
operations to occur in parallel. For the same reason, random access to the
blocks is possible when decrypting.

5
 Figure 5: CBC decryption.

Due to block chaining, bit errors in a single ciphertext block cause cor-
ruption of the corresponding decrypted block and of its successor. A one-bit
change may produce errors in any bit position of the current decrypted block
and inverts the corresponding bit in the following block.
A specific problem exists concerning the IV. An exposed IV might allow a
man-in-the-middle (MITM) to change the IV value in-transit. Changing the
IV changes only the deciphered plaintext for the first block, without garbling
the second block. Any or all bits of the first block plaintext can be changed
systematically with complete control. In marked contrast, when ciphertext
is changed in CBC mode, it does change the next block plaintext bit-for-bit,
but it also garbles the plaintext for the current block and so is easily detected.
An obvious solution to prevent deliberate MITM changes to the first
block by altering the IV is to encipher the IV. Another possibility is to
use a message number value known to both parties to produce the IV by
means of ciphering. Techniques to reset the message number and maintain
synchronization would of course be required.
We must, however, bear in mind that CBC does not provide integrity, but
only confidentiality. If higher assurance of message integrity are required,
authentication (which ensures integrity) might be necessary.

Propagating Cipher Block Chaining (PCBC) The Propagating Ci-

pher Block Chaining (PCBC) mode is a variant of the CBC mode which
was designed to propagate small errors (one-bit errors) in the ciphertext.
Encryption and decryption routines are as follows:

PCBC encryption: Ci = CIP Hk (Pi ⊕ Pi−1 ⊕ Ci−1 ), P0 ⊕ C0 = IV

PCBC decryption: Pi = CIP Hk−1 (Ci ) ⊕ Pi−1 ⊕ Ci−1 , P0 ⊕ C0 = IV

6
 Since a single-bit error in a cipherblock thus affects all subsequent blocks,
the entire message is very likely to be rejected. Whether this is a desirable
feature for a mode of operation largely depends on the application. In some
cases, a one-bit change may indicate a possible attack; it is therefore most
preferrable to discard the entire message. On the other hand, when bit errors
are more likely to be introduced by the transmission line, rather than by a
malicious user, resilience of the data may be favourable.
The PCBC mode of encryption has not been formally published as a fed-
eral or national standard, and it does not have widespread general support. It
was used in Kerberos v4, but was abandoned starting from version 5 because
the exchange of two adjacent blocks does not affect subsequent blocks.
As a matter of fact, when Ci and Ci+1 are received in order:

Pi = CIP Hk−1 (Ci ) ⊕ Pi−1 ⊕ Ci−1

Pi+1 = CIP Hk −1(Ci+1 ) ⊕ Pi ⊕ Ci

= CIP Hk−1 (Ci+1 ) ⊕ CIP Hk−1 (Ci ) ⊕ Ci ⊕ Ci−1 ⊕ Pi−1

Pi+2 = CIP Hk−1 (Ci+2 ) ⊕ Pi+1 ⊕ Ci+1

= CIP Hk−1 (Ci+2 ) ⊕ CIP Hk−1 (Ci+1 ) ⊕ CIP Hk−1 (Ci ) ⊕ Ci+1 ⊕ Ci ⊕
⊕Ci−1 ⊕ Pi−1

When Ci and Ci+1 are exchanged:

Pi = CIP Hk−1 (Ci+1 ) ⊕ Pi−1 ⊕ Ci−1

Pi+1 = CIP Hk−1 (Ci ) ⊕ Pi ⊕ Ci+1

= CIP Hk−1 (Ci+1 ) ⊕ CIP Hk−1 (Ci ) ⊕ Ci+1 ⊕ Ci−1 ⊕ Pi−1

Pi+2 = CIP Hk−1 (Ci+2 ) ⊕ Pi+1 ⊕ Ci

= CIP Hk−1 (Ci+2 ) ⊕ CIP Hk−1 (Ci+1 ) ⊕ CIP Hk−1 (Ci ) ⊕ Ci+1 ⊕ Ci ⊕
⊕Ci−1 ⊕ Pi−1

The two expressions for Pi+2 are identical.

1.1.3 Cipher Feedback (CFB)

The Cipher Feedback (CFB) mode of operation turns the underlying block
cipher into a stream cipher. A stream cipher is a symmetric cipher where
plaintext bits are combined with a pseudorandom cipher bitstream, called

7
a keystream. The CFB mode of operation is very close to the CBC mode.
It entails the feedback of ciphertext segments which are ciphered to gener-
ate output blocks; the latter are then XORed with the plaintext to produce
ciphertext (whereas in the CBC mode the XOR operation precedes the ci-
phering). For this mode of operation the plaintext size need not be a multiple
of the block size. As a matter of fact, a further parameter s, named the seg-
ment size, is considered; it can assume any value between 1 and the block
size b. The plaintext is thus decomposed into n segments Pj# , which are
encrypted into n ciphertext segments Cj# .
The algorithm operates as follows:
CFB encryption: I1 = IV
#
Ij = LSBb−s (Ij−1 )||Cj−1 for j = 2...n
Oj = CIP Hk (Ij ) for j = 1...n
Cj# = Pj# ⊕ M SBs (Oj ) for j = 1...n

Figure 6: CFB encryption.

CFB decryption: I1 = IV
#
Ij = LSBb−s (Ij−1 )||Cj−1 for j = 2...n
Oj = CIP Hk (Ij ) for j = 1...n
Pj# = Cj# ⊕ M SBs (Oj ) for j = 1...n

In both CFB encryption and decryption, the IV is enciphered to produce

the first output block. The s most significant bits of the first output block
(of length b) are then XORed with the first plaintext segment, while the
b − s least significant bits are discarded. Starting from the second iteration,

8
 Figure 7: CFB decryption.

the b − s least significant bits of the previous input block are concatenated
with the previous ciphertext segment to form the current input block. This
operation is equivalent to shifting the previous input block to the left by s
positions and replacing the s least significant bits of the result with the last
ciphertext segment.

In CFB encryption, just like CBC encryption, the input block to each ci-
pher operation depends on the result of the previous one. Although encryp-
tion cannot be executed in parallel on multiple blocks, a form of pipelining
is possible, since the only encryption step that requires the actual plaintext
is the last. This is useful when low latency between the arrival of plaintext
and the output of the corresponding ciphertext is required (e.g., in some
applications of streaming media).
Decryption can be performed in parallel.
A further advantage of the CFB mode is that the cipher function is only
ever used in the forward direction.

The CFB mode of operation relates to bit errors in the opposite way with
respect to the CFB mode. A single-bit error in a ciphertext block results in
an error in the same bit position of the corresponding decrypted block and
may affect the following db/se segments in an unpredictable way. Bit errors
in the IV affect, at a minimum, the decryption of the first ciphertext segment
and possibly following segments, depending on the position of the rightmost
bit error in the IV; in general, a bit error in the i th position (counting from
the left) affects the decryption of the first di/se segments.
The CFB mode is exposed to the risk of intentional introduction of bit
errors in specific bit positions when it is used with an underlying block cipher
which does not provide data integrity. Unlike other modes of operation,
however, the existence of such errors may be inferred by their randomizing

9
effects on the following ciphertext segments.
The insertion or deletion of bits into a ciphertext segment spoils the
synchronization of the segment boundaries. The decryption of the subsequent
segments will almost certainly be incorrect until synchronization is restored.
When the 1-bit CFB mode (i.e., the CFB mode with a segment size of 1 bit)
is used, the synchronization is automatically restored after b + 1 segments.
For other values of s the synchronization must be restored manually.

Attacking the OpenPGP CFB mode The OpenPGP Message Format

is a very popular and commonly used format for signing and encrypting data
files, particularly for signing and encrypting email. The formats described
in the OpenPGP RFC have been implemented in a wide variety of popu-
lar freeware and commercial encryption products. Symmetric encryption in
OpenPGP is performed using a variant of the standard CFB mode. The
main difference with the OpenPGP variant is that a plaintext initialization
vector, as described above, is not used, but instead a random block R is en-
crypted as the first block of ciphertext. Two bytes of R are repeated in the
second block in order to quickly check whether the session key K is incorrect
upon decryption. This “quick check” is really an integrity check on the key
and it is this ad-hoc integrity mechanism, used in a mode of operation that
wasn’t designed to accommodate it, that allows the attack.
The successful outcome of the attack relies on two assumptions: 1) the
first 2 bytes of the first plaintext block can be easily guessed, and 2) an oracle
O that, when given a purported ciphertext encrypted using the OpenPGP
CFB mode of operation with a given key, will correctly determine whether or
not the integrity check was successful is available. Both these assumptions
are reasonable. As a matter of fact, compression algorithms are very often
used along with the OpenPGP CFB mode; the first 2 bytes of the message are
therefore likely to be a known packet tag and a known compression algorithm
identifier. This justifies the first assumption. As to the second assumption,
mechanisms to inform the end user that the integrity check failed on the
encrypted message are very likely to be available on a system implementing
the OpenPGP CFB mode. If, however, this should not be the case, timing
attacks would always be possible, since the decryption of the message does
not start if the integrity check fails.
The knowledge of the first 2 bytes of the message enable a malicious user,
after an initial setup of about 215 oracle queries, to find out 16 bits of any
block with 215 queries for each block. Further details, mathematical proofs,
as well as extensive discussion of possible solutions, is given in [4].

10
1.1.4 Output Feedback (OFB)
The Output Feedback (OFB) mode of operation, just like CFB, converts the
underlying block cipher into a stream cipher. It features the iteration of
the forward cipher function on an IV to generate keystream blocks, which
are combined with the plaintext blocks by means of XORing. The plaintext
size is not requested to be an integer multiple of the block size. The last
block may be a partial block of size u; in that case, it is XORed with the u
most significant bits of the last keystream block to produce the last (partial)
ciphertext block.
It is defined as follows:

OFB encryption: I1 = IV
Ij = Oj−1 for j = 2...n
Oj = CIP Hk (Ij ) for j = 1...n
Cj = Pj ⊕ Oj for j = 1...n − 1
Cn∗ = Pn∗ ⊕ M SBu (On )

Figure 8: OFB encryption.

OFB decryption: I1 = IV
Ij = Oj−1 for j = 2...n
Oj = CIP Hk (Ij ) for j = 1...n
Pj = Cj ⊕ Oj for j = 1...n − 1
Pn∗ = Cn∗ ⊕ M SBu (On )

Both encryption and decryption make use of recurrent ciphering of an IV;

this prevents from performing multiple cipher operations at the same time.
Nonetheless, if the IV is known, then the keystream blocks can be pre-
computed, prior to the availability of the plaintext or ciphertext data.

11
 Figure 9: OFB decryption.

The OFB requires the IV to be a nonce, i.e. that the IV be unique for every
message that is encrypted with a given key. When this requirement is not
met, the confidentiality of the encrypted message may be compromised. If a
plaintext block is known to a malicious user, the latter can easily reconstruct
the corresponding keystream block from the ciphertext block. Reusage of
the same IV therefore enables the malicious user to gain knowledge of the
corresponding block of information by simply XORing the ciphertext block
with the keystream block. The same holds when any of the input blocks
to the forward cipher is designated as the IV for the encryption of another
message under the same key.

Bit errors within a ciphertext block only affect the decryption of that block;
flipping a bit in the ciphertext produces a flipped bit in the plaintext at the
same location. This property is useful, in that it allows many error correcting
codes to function normally even when applied before encryption. However,
OFB is less resistant to message stream modification attacks. An attacker
may in fact systematically change bits of his choosing in every block and
correspondingly alter the checksum part of the message in such a way that
the modifications will not be detected by an error-correcting code.
Conversely, bit errors in the IV affect the decryption of all ciphertext
blocks.

1.1.5 Counter (CTR)

As with the OFB mode of operation, the Counter (CTR) mode of operation,
also known as Segmented Integer Count (SIC), makes a block into a stream
cipher. Keystream blocks are generated by encrypting a sequence of input
blocks, named counters. The word “counter” assumes here a broader mean-
ing; it can be any function which is known to produce a sequence of blocks

12
that do not repeat for a long time. An actual counter is the simplest and
most popular of such functions. The property that all counter blocks must
be different does not apply to a single message: across all of the messages
that are encrypted under a given key, counters must be distinct.
Given a sequence of counters T1 , T2 , ..., Tn , the CTR mode is defined as
follows:

CTR encryption: Oj = CIP Hk (Tj ) for j = 1...n

Cj = Pj ⊕ Oj for j = 1...n − 1
Cn∗= Pn∗ ⊕ M SBu (On )

Figure 10: CTR encryption.

CTR decryption: Oj = CIP Hk (Tj ) for j = 1...n

Pj = C j ⊕ O j for j = 1...n − 1
Pn∗= Cn∗ ⊕ M SBu (On )

Figure 11: CTR decryption.

13
 The CTR mode can operate with input plaintexts whose size is not an
integer multiple of the block size b. In that case, the last block Cn∗ will be a
partial block.
Both CTR encryption and decryption work on counter blocks and plain-
text/ciphertext blocks independent from one another; multiple forward ci-
pher functions can thus be performed in parallel, providing greater hard-
ware efficiency than all other modes of operation. The only limitation is the
amount of parallelism that can be achieved on a given machine.
In addition, the CTR mode provides true random access to any particular
ciphertext block. The forward cipher function can also be applied to each of
the counters in advance, so that decryption can start as soon as ciphertext
blocks are available.
A further advantage of the CTR mode is its simpicity, since the cipher
algorithm is only needed for encryption, while simple XOR operations are
used for decryption. This matters most when the decryption algorithm differs
substantially from the encryption algorithm, as it does for AES.

In order to ensure the uniqueness of each counter block, two aspects must
be taken into account. First, an appropriate incrementing function that
generates the counter blocks from any initial counter block must guarantee
that counters do not repeat within a given message. Second, the initial
counter blocks for every message must be chosen in such a way that counter
blocks do not repeat across all messages that are encrypted under a given
key.

The Standard Incrementing Function The standard incrementing func-

tion can apply either to an entire block or to a part of a block. Let m be
the number of bits involved in the incrementation. This m-bit string can be
regarded as a binary non-negative number x; the incrementing function takes
the binary number x and returns x + 1 mod 2m . This way, the uniqueness
requirement for the counter blocks is satisfied within a given message of n
blocks, provided that n ≤ 2m .

Choice of the Initial Counter Blocks Two possible approaches are

discussed here.
The first approach entails the sequential encryption of all the messages
that are ever encrypted under a given key. Any initial block of b bits may
be chosen as the initial counter block for the first message. For all successive
messages, the initial counter block is obtained by applying the standard
incrementing function to the last counter block of the previous message.

14
This approach requires that the total number of blocks, across all messages,
be at most 2m ; care should also be taken to ensure the proper sequencing of
the messages.
A second approach lies in the assignment of a unique identifier (i.e., a
nonce) to every message. The nonce is a (b−m)-bit string that is incorporated
in every counter block of a given message. To ensure that it is used only once,
it should be time-variant or generated with enough random bits to guarantee
a probabilistically insignificant chance of collision. The incrementing function
is applied to the remaining m bits. The nonce and the actual counter can be
subsequently concatenated, added or XORed to produce the unique counter
block.

1.2 Generation of Initialization Vectors

Four of the modes of operation hereby described (i.e., all but the ECB mode)
require an initialization vector. For the CBC and CFB modes, the IV must
be unpredictable. This means that, given a plaintext, it must not be possible
to predict the IV that will be associated to it in advance of its generation. A
method to produce unpredictable IVs is to apply the forward cipher function
to a nonce. As an alternative, an unpredictable IV may be obtained by
resorting to a FIPS-approved random number generator.
The OFB mode does not require the IV to be unpredictable, but it must
be unique to the execution of the encryption operation. It can be a nonce or
a message number. The same observation applies to the CTR mode, where
each of the counter blocks may be regarded as an IV.

1.3 Padding-related issues

1.3.1 Padding techniques
For three of the modes of operation formerly described, the input plaintext
must be a sequence of complete blocks (for the ECB and CBC modes) or
segments (for the CFB mode). If the initial plaintext does not satisfy this
property, extra bits must be appended at the end of the last (partial) block
or segment to complete it. Two simple ways of padding a message are bit
padding and byte padding.

A bit padding scheme is described in RFC1321 and was originally used

with the DES algorithm. A single set (‘1’) bit is added at the trailing end
of the message and then as many reset (‘0’) bits as required are appended.
This method can be used to pad blocks of any size, not necessarily an integer

15
number of bytes. For the above padding method, the padding bits can be
removed unambiguously, provided that the receiver can determine that the
message is indeed padded. In order to ensure that the receiver does not mis-
takenly remove bits from an unpadded message, the sender may be required
to pad every message, even though the last block is already complete. In
that case, an entire block of padding is added.

Byte padding schemes are defined in a number of official papers. In ANSI

X.923 a byte padding scheme is specified for use with blocks whose size is an
integer number of bytes. Null bytes are padded and the last byte defines the
padding boundaries or the number of padded bytes. ISO 10126 describes a
very similar padding scheme which uses random bytes instead of null bytes.
In the PKCS7 scheme, defined in RFC3852, the value of each padding byte
is the total number of padded bytes (e.g. N bytes are added, each of value
N ). Finally, the zero padding scheme pads all bytes with null bytes.

Besides incrementing the amount of data to be transmitted, padding may

have other outcomes. Padding with random values may be necessary when
a regular, known data pattern needs to be sent; this has the side benefit
of making some kinds of cryptanalysis more difficult. However, in some
circumstances the use of padding may expose the exchange of a message to
timing attacks.

1.3.2 Ciphertext stealing (CTS)

In some applications, such as data streaming, or when a number of messages
whose sizes do not align to block boundaries need to be transmitted, the use of
padding may be inconvenient. Some nifty techniques have been developed to
avoid the transmission of extra ciphertext; one of them is ciphertext stealing
(CTS).
In order to produce ciphertext of the same length as the correspond-
ing plaintext, we must avoid adding extra, unneeded information, such as
padding. Block ciphers, however, need entire plaintext blocks to perform
encryption. One may at this point decide to pad the incomplete block, en-
crypt it and discard as many bits of the corresponding ciphertext block as
the padding bits, mistakenly judging them unnecessary. This is not so. Since
a block cipher is being used, no direct kinship between a bit in the plaintext
and the corresponding bit in the ciphertext can be assumed (or else the block
cipher would be a stream cipher!) and all bits in the ciphertext are poten-
tially necessary to reconstruct a single bit of plaintext. The CTS technique
can be applied to the ECB and CBC modes of operation and provides a

16
workaround to this problem. The goal is achieved at the cost of an increased
complexity of the encryption and decryption process. The encryption and
decryption algorithms for the ECB mode only are described below.

Encryption:

1. En−1 = CIP Hk (Pn−1 )

2. Cn∗ = M SBm (En−1 )

3. Dn = Pn ||LSBb−m (En−1 )

4. Cn−1 = CIP Hk (Dn )

Decryption:

1. Dn = CIP Hk−1 (Cn−1 )

2. En−1 = Cn∗ ||LSBb−m (Dn )

3. Pn = M SBm (Dn )

4. Pn−1 = CIP Hk−1 (En−1 )

During encryption, all plaintext blocks except the last one are encrypted
normally. After the second-to-last block has been encrypted, the m most
significant bits are taken to create the last partial ciphertext block. The
remaining bits are then appended to the last incomplete plaintext block and
the block thus obtained is enciphered to create the second-to-last ciphertext
block. This way we transmit as many bits as were in the original message.
The receiver normally decrypts all blocks except the last one. The m
most significant bits of the plaintext block obtained from the decryption
of the second-to-last ciphertext block give the last plaintext block, whereas
the remaining b − m bits are concatenated to the last ciphertext block and
decrypted, yielding the second-to-last plaintext block.

As we can notice, a portion of the second-to-last plaintext block is en-

crypted twice and some additional bit-wise operations are required. Allow-
ing for even higher complexity when the CBC mode is used, and bearing
in mind that really short messages (i.e. messages that fit in less than one
full block) can still not be encrypted without padding, the CTS technique
is nowadays hardly ever worthwhile. The CBC mode of operation is being
largely replaced by the CTR mode, which does not need padding.

17
1.4 Related-mode attacks
Block ciphers are often proposed with several variants, in terms of a different
secret key size and corresponding number of rounds. The so called “related-
cipher attack” model refers to a situation in which some ciphers are related,
in the sense that they are exactly identical to each other, differing only in the
key size and most often also in the total number of rounds. The knowledge
that one cipher is being used and the availability of an oracle which provides
the forward and inverse cipher functions of a related cipher can be exploited
in order to attack the exchange of information enciphered using the first
cipher.
The concept has then been extended to a larger class of related models,
in particular to cipher encryptions with different block cipher modes of oper-
ation, but with the underlying block cipher being identical. This new model
has been named a “related-mode attack” model. It has been shown that
when an adversary has access to an oracle for any one mode of operation
(ECB, CBC, CFB, OFB, CTR), then almost all other related cipher modes
can be easily attacked. Examples of such attacks are briefly outlined in the
following paragraphs. Further examples may be found in [6].

1.4.1 Exploiting an ECB Oracle to attack the CTR mode

We suppose the attacker has access to an ecnryption-only oracle O under
ECB mode and strives to attack another related cipher in the CTR mode.
Let Pi and Ci denote, respectively, the current plaintext and ciphertext blocks
of the related-cipher mode being attacked, while Pi0 and Ci0 denote, respec-
tively, the current plaintext and ciphertext blocks used in the interaction
with the oracle O. Having intercepted Ci , the attacker chooses Pi0 = C0 + i
to feed the ECB encryption and hence obtains Ci0 = CIP Hk (C0 + i). Since
Ci = CIP Hk (C0 + i) ⊕ Pi , he can easily compute Pi = Ci ⊕ Ci0 . In summary,
he only needs one chosen plaintext (CP) query encrypted under ECB to
obtain the plaintext block corresponding to any ciphertext block encrypted
under CTR.

1.4.2 Exploiting a CBC Oracle to attack the CTR mode

The adversary can in a similar way attack the CTR mode having access to
a CBC encryption-only oracle. First the adversary queries the encryption
0 0
oracle with the the plaintext block Pi−1 and gets the ciphertext block Ci−1 .
0 0
He then chooses Pi = Ci−1 ⊕ (C0 + 1) and queries again the oracle, obtaining
Ci0 = CIP Hk (Ci−1
0
⊕ Pi0 ) = CIP Hk (C0 + 1). This value is directly related to
an intermediate value in CTR, since Ci = Pi ⊕ Ci0 , and enables the attacker

18
to find Pi . On the whole, two CP queries under CBC are required to obtain
a block enciphered under CTR.

2 The CMAC Mode for Authentication

2.1 Introduction
The CMAC is a block cipher-based message authentication code algorithm
which may be used to provide assurance of the authenticity and, hence, the
integrity of binary data. Its role is analogous to the standard hash function-
based MAC (HMAC) and it may be appropriate for information systems
where an approved block cipher is more readily available than an approved
hash function.
The ancestor of the CMAC mode for authentication is the Cipher Block
Chaining MAC (CBC-MAC) algorithm, a block cipher-based algorithm to
create MACs that has serious security deficiencies. A first improvement
of the CBC-MAC was proposed by Black and Rogaway and submitted to
NIST under the name XCBC. Iwata and Kurosawa provided a further refine-
ment, which was initially submitted as the One-Key CBC-MAC (OMAC)
and, later, as OMAC1, which included additional security analysis and effi-
ciently reduced the key size of XCBC. CMAC is equivalent to OMAC1.

CMAC, like any well-designed MAC algorithm, provides stronger assurance

of data integrity than a checksum or an error detecting code. The verification
of a checksum or an error detecting code is designed to detect only accidental
modifications of the data, while CMAC is designed to detect intentional,
unauthorized modifications of the data, as well as accidental modifications.

2.2 Cipher Block Chaining MAC (CBC-MAC)

The CMAC mode addresses many of the weaknesses of the original Cipher
Block Chaining MAC (CBC-MAC). In order to better understand its mech-
anism, as well as the attacks to which a message authentication code (MAC)
may be exposed, a brief overview of the CBC-MAC, along with its drawbacks,
is provided in the following paragraphs.

19
2.2.1 Description
In the Cipher Block Chaining MAC, the message is encrypted with some
underlying block cipher algorithm using the CBC mode of operation and zero
IV, so as to create an interdependence between each block and its predecessor.
As a consequence, a change to any of the plaintext bits will cause the final
encrypted block to change in a way that cannot be predicted or counteracted
without knowing the key to the block cipher. The final ciphertext block is
taken as the message authentication code (MAC) for the current message.

2.2.2 Weaknesses
Given a secure underlying block cipher, the CBC-MAC mode for authenti-
cation is secure for fixed-length messages (i.e., when the two parties agreed
on a message length and any message of a different length will be discarded,
as considered inauthentic). However, it is not secure for variable-length mes-
sages. An attacker who knows two distinct messages, m0 and m00 , with their
associated CBC-MACs, t0 and t00 , can produce a third message m∗ , whose
CBC-MAC will also be t00 . This is done by simply XORing the first plaintext
block of m00 with t0 and then chaining m0 with the thus modified m00 :

m∗ = m0 k[(m001 ⊕ t)km002 k...km00q ]

As a matter of fact, when the receiver computes the CBC-MAC over the
received message m∗ , the first block of m00 will be XORed with the last ci-
phertext block of m0 , which is in fact t0 . XORing of two identical bit-vectors
yields the zero vector, which results, in practice, in computing the CBC-MAC
over m00 only, “undoing” all past history (represented by m0 ):

M ACIV =0 (m∗ )= M ACIV =0 (m0 k[(m001 ⊕ t)km002 k...km00q ])

= M ACIV =t ((m001 ⊕ t)km002 k...km00q )
= M ACIV =0 (m00 )
= t00

The MAC verification will therefore succeed and the message will be mistak-
enly accepted as authentic.

Another security problem of the CBC-MAC arises when the same key is
used for CBC encryption and CBC-MAC. Although reuse of a key for dif-
ferent purposes is bad practice in general, in this particular case the mistake
may lead to an unparallaled attack.

20
 Suppose a message m = m1 km2 k...kmq is encrypted using the CBC mode
under the key k, yielding the ciphertext c1 kc2 k...kcq . We here assume that
the IV for the encryption is obtained by forward-ciphering a bit-vector (e.g.,
a nonce), which we will call m0 . The same key is then used to produce a
CBC-MAC t for the IV and the message. An attacker may now change every
bit before the last ciphertext block cq , and the MAC will still be valid. This
is because t = CIP Hk (mq ⊕cq−1 ) = cq , so as long as the last ciphertext block
remains unaltered, the CBC-MAC verification will succeed. This is also the
reason why inexperienced users often make such a gross mistake: it allows
to encrypt the message and compute its MAC in a single pass, increasing
performance by a factor of two. This also shows that the CBC-MAC cannot
be used as a collision resistant one-way function: given a key, it is trivial to
find a different message which maps to the same MAC.

2.3 CMAC Specification

2.3.1 Subkeys generation
The CMAC mode for authentication requires two additional parameters, be-
sides the block cipher key. These parameters, named the subkeys, K1 and
K2 , are derived from the block cipher key; they must be kept secret. The
subkeys are fixed for any invocation of CMAC under a given key. As a con-
sequence, they do not need to be recomputed anew every time; they may,
instead, be calculated once and stored along with the block cipher key. The
subkeys are generated as follows:
1. L ← CIP Hk (0b )

2. if M SB1 (L) = 0 then K1 ← L << 1

else K1 ← (L << 1) ⊕ Rb

3. if M SB1 (K1 ) = 0 then K2 ← K1 << 1

else K2 ← (K1 << 1) ⊕ Rb
In step 1, 0b indicates the bit string that consists of b 0s. The value that is
obtained from applying the forward cipher function to the zero string must
also be kept secret.
In step 2 and 3 the parameter Rb appears; this value is a bit string that
is completely determined by the block size b. For example, for the AES
underlying block cipher the block size is 128 bits and Rb = 0120 10000111;
for the other currently approved block cipher, TDEA, the block size is 64
bits and the corresponding value of Rb is 059 11011. Given a block size b, in
order to find Rb we must find the lexicographically first among all irreducible

21
polynomials of degree b having the minimum possible number of nonzero
terms. If we let that polynomial be ub + cb−1 ub−1 + ... + c2 u2 + c1 u + c0 ,
then Rb is the bit string cb−1 cb−2 ...c2 c1 c0 . The generation of K1 and K2 is
essentially equivalent to multiplication by u and u2 , respectively, within the
Galois field that is determined by this polynomial.

2.3.2 CMAC generation

Once the subkeys K1 and K2 have been computed (or retrieved, together
with the shared secret K), the CMAC can be generated from the plaintext
message. Unlike CBC-MAC, CMAC is secure for variable-length messages.
Mathematical proof is provided in [7]. The CMAC is generated as follows:
1. if Mlen = 0 then n ← 1
else n ← dMlen /be
2. if Mn∗ is a complete block then Mn ← K1 ⊕ Mn∗
else Mn ← K2 ⊕ (Mn∗ k10j ), where j = nb − Mlen − 1
3. C0 ← 0b
4. for i ← 1 to n do
Ci ← CIP Hk (Ci−1 ⊕ Mi )
5. T ← M SBTlen (Cn )
The two subkeys K1 and K2 are used to mask the last block Mn∗ . When
the latter is a complete block, then it is simply masked with K1 and the
sequence of blocks M1 M2 ...Mn is the formatted message. When the last
block is incomplete, a padding string is appended to it, composed by a single
‘1’ followed by as many ‘0’s (possibly none) as are necessary to complete the
block. The padded block is subsequently masked with K2 , yielding Mn .
After the initial formatting, the following step is identical to the CBC-
MAC algorithm. The final step truncates the last CBC output block accord-
ing to the MAC length parameter.
The formatting of the message does not need to complete for the CBC
operations to start. These two processes may occur in parallel.

2.3.3 CMAC verification

After an authorized party has applied the CMAC generation process to the
data to be authenticated to produce a MAC, any authorized party can apply
the verification process to the received data and the received MAC. Successful
verification provides assurance of data authenticity and, hence, of integrity.

22
 Figure 12: Two cases of CMAC generation.

The verification of the MAC involves two steps. Prior to verification, the
received data must be decrypted using the appropriate mode of operation
and underlying algorithm. The CMAC algorithm is applied to the decrypted
data and a MAC is generated. The result is then compared with the received
MAC. Upon successful comparison, the verification process terminates suc-
cesfully.

2.4 Security issues

2.4.1 Length of the MAC
A parameter that has great incidence on security-related issues is the length
of the MAC. Choosing an appropriate length for the MAC may prove fun-
damental in resisting to guessing attacks.
The verification process determines whether an alleged MAC is a valid
output of the CMAC generation process applied to the message the MAC
came with. If the verification process fails, then the message is undoubtedly
inauthentic i.e., it was not produced by an authorized party, and is therefore
discarded. Upon successful verification, CMAC provides sufficient assurance
that the message is authentic and, hence, was not corrupted in transit. This
assurance, however, is not absolute. An attacker might have, for instance,
simply guessed the correct MAC for the message. By selecting a MAC at
random from the set of all possible bit strings of length Tlen , the attacker
has a probability of 1/2Tlen that his or her guess will be correct. As a con-
sequence, using a longer MAC provides better protection against guessing
attacks. On the other hand, larger values of Tlen require more storage space
and bandwidth, which may not be acceptable for some applications.
The attacker might also repeatedly attempt to guess the right MAC,
thereby increasing his chances of succeeding in the attack. For that reason,

23
care should be taken to ensure that the maximum number of unsuccessful
CMAC verifications on a given system be limited.

For most applications, a value of at least 64 bits should provide sufficient

protection. Choosing a length that is less than 64 bits should be accompa-
nied by careful pondering of the risks of accepting an inauthentic message
as authentic and by restricing the number of unsuccessful attempts. More
specific guidance in the choice may be quantified in terms of two parameters:
M axInvalids, a limit on the number of times that the verification process
may fail before the key is retired, and Risk, the highest acceptable probabil-
ity for an inauthentic message to pass the verification process. Tlen should
then satisfy the following inequality:

Tlen ≥ log2 (M axInvalids/Risk)

A simple example may be useful to understand the above formula. Suppose

we want at most 25% of the messages we receive to be mistakenly accepted
as authentic; we also allow only one attempt. The resulting value for Tlen is
thus 2 bits. This is correct, since there is a probability of 1/4 that a malicious
user can guess the correct MAC out of the 4 possible 2-bit patterns.
We now increase the number of attempts to two, always with a risk of
25%. The above equation yields Tlen = 3. As a matter of fact:
P[ correct guess ]=P[1st guess correct]+
+P[2nd guess correct |1st guess incorrect]
= 18 + 17 87
= 14

2.4.2 Message span of the key

The message span of a given key is the total number of messages to which
the CMAC algorithm is applied under the same key. The message span of a
key affects the security of the system against attacks that are based on the
detection of a pair of distinct messages which lead to the same MAC before
its truncation. Such an event is called a collision. An attacker might exploit
a collision to append the MAC of a message to a new message whose content
may largely differ from the original one.
Collisions cannot be utterly avoided, because the number of all possible mes-
sages is much higher than the number of all possible MACs. However, col-
lisions should not occur among the messages for which MACs are actually
generated with a given key. The probability that at least one collision ac-
tually occurs during the lifetime of the key depends on the message span of

24
the key, relative to the block size of the underlying block cipher. For a given
block size b, a collision is expected to exist among a set of 2b/2 messages. The
message span of a key should therefore be reasonably limited, with respect
to the value of the data involved in the exchange.

For general-purpose applications, the message span is measured in terms

of the total number of messages the same key is used with. When the block
size of the underlying block cipher is 128 bits, such as with AES, the message
span should be limited to no more than 248 messages; when the block size is
64 bits, as it is the case with TDEA, the limit is 221 messages.
For applications which require a higher level of security, the message span is
expressed in terms of message blocks. In this case, when the block size of
the underlying algorithm is 128 bits, a message span of at most 248 message
blocks (222 GB) is recommended; for a block size of 64 bits, the recommended
limit is 221 blocks (16 MB).
Within these limits, the probability that a collision will occur is proved to
be less than 10−9 for a block size of 128 bits and less than 10−6 for a block
size of 64 bits.

Sometimes the limit for the message span of a given key may be established
by restraining the time span during which the key remains in use (i.e., its
cryptoperiod).

2.4.3 Protection against replay attacks

The successful verification of the MAC gives assurance that the source of the
message executed the MAC generation algorithm. However, this does not
ensure that the sender of the message is the actual source that produced it.
An attacker may in fact intercept a legitimate message with its MAC, store it
and send it at a later time, claiming to be an authorized party. Therefore, the
CMAC algorithm does not inherently provide any protection against replay
attacks.
Such protection must be provided, instead, by the protocol or application
that is using the CMAC mode to authenticate its messages by inserting
some identifying information at the beginning of the message. For instance,
a sequential number, a timestamp, a nonce etc. may be incorporated in each
message, in order to make it possible to detect replayed messages, out-of-
sequence messages or missing messages.

25
References
[1] Morris Dworkin. Recommendation for Block Cipher Modes of Operation.
Methods and techniques. NIST Special Publication 800-38A, 2001.
http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf

[2] Morris Dworkin. Recommendation for Block Cipher Modes of Operation:

The CMAC Mode for Authentication. NIST Special Publication 800-38B,
2001.
http://csrc.nist.gov/publications/nistpubs/800-38B/SP 800-38B.pdf

[3] Wikipedia. The free encyclopedia.

http://www.wikipedia.org/

[4] S. Mister, R. Zuccherato. An Attack on CFB Mode Encryption As Used

By OpenPGP
http://eprint.iacr.org/2005/033.pdf

[5] W. Stallings. Cryptography and Network Security. Principles and Prac-

tices. IV edition, Prentice-Hall, 2005.

[6] D. Wang, D. Lin, W. Wu. Related-Mode Attacks on CTR Encryption

Mode
http://ijns.nchu.edu.tw/contents/ijns-v4-n3/ijns-2007-v4-n3-p282-287.pdf

[7] T. Iwata, K. Kurosawa. OMAC: One-Key CBC MAC

http://crypt.cis.ibaraki.ac.jp/omac/docs/omac.pdf

26