Hubbry Logo
Block cipher mode of operationBlock cipher mode of operationMain
Open search
Block cipher mode of operation
Community hub
Block cipher mode of operation
logo
8 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Block cipher mode of operation
Block cipher mode of operation
Block cipher mode of operation
View on Wikipedia
from Wikipedia
Six common block cipher modes of operation for encrypting

In cryptography, a block cipher mode of operation is an algorithm that uses a block cipher to provide information security such as confidentiality or authenticity.[1] A block cipher by itself is only suitable for the secure cryptographic transformation (encryption or decryption) of one fixed-length group of bits called a block.[2] A mode of operation describes how to repeatedly apply a cipher's single-block operation to securely transform amounts of data larger than a block.[3][4][5]

Most modes require a unique binary sequence, often called an initialization vector (IV), for each encryption operation. The IV must be non-repeating, and for some modes must also be random. The initialization vector is used to ensure that distinct ciphertexts are produced even when the same plaintext is encrypted multiple times independently with the same key.[6] Block ciphers may be capable of operating on more than one block size, but during transformation the block size is always fixed. Block cipher modes operate on whole blocks and require that the final data fragment be padded to a full block if it is smaller than the current block size.[2] There are, however, modes that do not require padding because they effectively use a block cipher as a stream cipher.

Historically, encryption modes have been studied extensively in regard to their error propagation properties under various scenarios of data modification. Later development regarded integrity protection as an entirely separate cryptographic goal. Some modern modes of operation combine confidentiality and authenticity in an efficient way, and are known as authenticated encryption modes.[7]

History and standardization

[edit]

The earliest modes of operation, ECB, CBC, OFB, and CFB (see below for all), date back to 1981 and were specified in FIPS 81, DES Modes of Operation. In 2001, the US National Institute of Standards and Technology (NIST) revised its list of approved modes of operation by including AES as a block cipher and adding CTR mode in SP800-38A, Recommendation for Block Cipher Modes of Operation. Finally, in January, 2010, NIST added XTS-AES in SP800-38E, Recommendation for Block Cipher Modes of Operation: The XTS-AES Mode for Confidentiality on Storage Devices. Other confidentiality modes exist which have not been approved by NIST. For example, CTS is ciphertext stealing mode and available in many popular cryptographic libraries.

The block cipher modes ECB, CBC, OFB, CFB, CTR, and XTS provide confidentiality, but they do not protect against accidental modification or malicious tampering. Modification or tampering can be detected with a separate message authentication code such as CBC-MAC, or a digital signature. The cryptographic community recognized the need for dedicated integrity assurances and NIST responded with HMAC, CMAC, and GMAC. HMAC was approved in 2002 as FIPS 198, The Keyed-Hash Message Authentication Code (HMAC), CMAC was released in 2005 under SP800-38B, Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication, and GMAC was formalized in 2007 under SP800-38D, Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC.

The cryptographic community observed that compositing (combining) a confidentiality mode with an authenticity mode could be difficult and error prone. They therefore began to supply modes which combined confidentiality and data integrity into a single cryptographic primitive (an encryption algorithm). These combined modes are referred to as authenticated encryption, AE or "authenc". Examples of AE modes are CCM (SP800-38C), GCM (SP800-38D), CWC, EAX, IAPM, and OCB.

Modes of operation are defined by a number of national and internationally recognized standards bodies. Notable standards organizations include NIST, ISO (with ISO/IEC 10116[5]), the IEC, the IEEE, ANSI, and the IETF.

Initialization vector (IV)

[edit]
Main article: Initialization vector

An initialization vector (IV) or starting variable (SV)[5] is a block of bits that is used by several modes to randomize the encryption and hence to produce distinct ciphertexts even if the same plaintext is encrypted multiple times, without the need for a slower re-keying process.[citation needed]

An initialization vector has different security requirements than a key, so the IV usually does not need to be secret. For most block cipher modes it is important that an initialization vector is never reused under the same key, i.e. it must be a cryptographic nonce. Many block cipher modes have stronger requirements, such as the IV must be random or pseudorandom. Some block ciphers have particular problems with certain initialization vectors, such as all zero IV generating no encryption (for some keys).

It is recommended to review relevant IV requirements for the particular block cipher mode in relevant specification, for example SP800-38A.

For CBC and CFB, reusing an IV leaks some information about the first block of plaintext, and about any common prefix shared by the two messages.

For OFB and CTR, reusing an IV causes key bitstream re-use, which breaks security.[8] This can be seen because both modes effectively create a bitstream that is XORed with the plaintext, and this bitstream is dependent on the key and IV only.

In CBC mode, the IV must be unpredictable (random or pseudorandom) at encryption time; in particular, the (previously) common practice of re-using the last ciphertext block of a message as the IV for the next message is insecure (for example, this method was used by SSL 2.0). If an attacker knows the IV (or the previous block of ciphertext) before the next plaintext is specified, they can check their guess about plaintext of some block that was encrypted with the same key before (this is known as the TLS CBC IV attack).[9]

For some keys, an all-zero initialization vector may generate some block cipher modes (CFB-8, OFB-8) to get the internal state stuck at all-zero. For CFB-8, an all-zero IV and an all-zero plaintext, causes 1/256 of keys to generate no encryption, plaintext is returned as ciphertext.[10] For OFB-8, using all zero initialization vector will generate no encryption for 1/256 of keys.[11] OFB-8 encryption returns the plaintext unencrypted for affected keys.

Some modes (such as AES-SIV and AES-GCM-SIV) are built to be more nonce-misuse resistant, i.e. resilient to scenarios in which the randomness generation is faulty or under the control of the attacker.

  • Synthetic initialization vectors (SIV) synthesize an internal IV by running a pseudo-random function (PRF) construction called S2V on the input (additional data and plaintext), preventing any external data from directly controlling the IV. External nonces / IV may be fed into S2V as an additional data field.
  • AES-GCM-SIVs synthesize an internal IV by running POLYVAL Galois mode of authentication on input (additional data and plaintext), followed by an AES operation.

Padding

[edit]
Main article: Padding (cryptography)

A block cipher works on units of a fixed size (known as a block size), but messages come in a variety of lengths. So some modes (namely ECB and CBC) require that the final block be padded before encryption. Several padding schemes exist. The simplest is to add null bytes to the plaintext to bring its length up to a multiple of the block size, but care must be taken that the original length of the plaintext can be recovered; this is trivial, for example, if the plaintext is a C style string which contains no null bytes except at the end. Slightly more complex is the original DES method, which is to add a single one bit, followed by enough zero bits to fill out the block; if the message ends on a block boundary, a whole padding block will be added. Most sophisticated are CBC-specific schemes such as ciphertext stealing or residual block termination, which do not cause any extra ciphertext, at the expense of some additional complexity. Schneier and Ferguson suggest two possibilities, both simple: append a byte with value 128 (hex 80), followed by as many zero bytes as needed to fill the last block, or pad the last block with n bytes all with value n.

CFB, OFB and CTR modes do not require any special measures to handle messages whose lengths are not multiples of the block size, since the modes work by XORing the plaintext with the output of the block cipher. The last partial block of plaintext is XORed with the first few bytes of the last keystream block, producing a final ciphertext block that is the same size as the final partial plaintext block. This characteristic of stream ciphers makes them suitable for applications that require the encrypted ciphertext data to be the same size as the original plaintext data, and for applications that transmit data in streaming form where it is inconvenient to add padding bytes.

Common modes

[edit]

Authenticated encryption with additional data (AEAD) modes

[edit]
Main article: Authenticated encryption

A number of modes of operation have been designed to combine secrecy and authentication in a single cryptographic primitive. Examples of such modes are ,[12] integrity-aware cipher block chaining (IACBC)[clarification needed], integrity-aware parallelizable mode (IAPM),[13] OCB, EAX, CWC, CCM, and GCM. Authenticated encryption modes are classified as single-pass modes or double-pass modes.

In addition, some modes also allow for the authentication of unencrypted associated data, and these are called AEAD (authenticated encryption with associated data) schemes. For example, EAX mode is a double-pass AEAD scheme while OCB mode is single-pass.

Galois/counter (GCM)

[edit]
Main article: Galois/Counter Mode
GCM
Galois/counter
Encryption parallelizableYes
Decryption parallelizableYes
Random read accessYes
Partial last blockYes

Galois/counter mode (GCM) combines the well-known counter mode of encryption with the new Galois mode of authentication. The key feature is the ease of parallel computation of the Galois field multiplication used for authentication. This feature permits higher throughput than encryption algorithms.

GCM is defined for block ciphers with a block size of 128 bits. Galois message authentication code (GMAC) is an authentication-only variant of the GCM which can form an incremental message authentication code. Both GCM and GMAC can accept initialization vectors of arbitrary length. GCM can take full advantage of parallel processing and implementing GCM can make efficient use of an instruction pipeline or a hardware pipeline. The CBC mode of operation incurs pipeline stalls that hamper its efficiency and performance.

Like in CTR, blocks are numbered sequentially, and then this block number is combined with an IV and encrypted with a block cipher E, usually AES. The result of this encryption is then XORed with the plaintext to produce the ciphertext. Like all counter modes, this is essentially a stream cipher, and so it is essential that a different IV is used for each stream that is encrypted.

Galois/Counter (GCM)
GCM mode encryption

The ciphertext blocks are considered coefficients of a polynomial which is then evaluated at a key-dependent point H, using finite field arithmetic. The result is then encrypted, producing an authentication tag that can be used to verify the integrity of the data. The encrypted text then contains the IV, ciphertext, and authentication tag.

Counter with cipher block chaining message authentication code (CCM)

[edit]
Main article: CCM mode

Counter with cipher block chaining message authentication code (counter with CBC-MAC; CCM) is an authenticated encryption algorithm designed to provide both authentication and confidentiality. CCM mode is only defined for block ciphers with a block length of 128 bits.[14][15]

Synthetic initialization vector (SIV)

[edit]

Synthetic initialization vector (SIV) is a nonce-misuse resistant block cipher mode.

SIV synthesizes an internal IV using the pseudorandom function S2V. S2V is a keyed hash based on CMAC, and the input to the function is:

  • Additional authenticated data (zero, one or many AAD fields are supported)
  • Plaintext
  • Authentication key (K1).

SIV encrypts the S2V output[failed verification] and the plaintext using AES-CTR, keyed with the encryption key (K2).

SIV can support external nonce-based authenticated encryption, in which case one of the authenticated data fields is utilized for this purpose. RFC5297[16] specifies that for interoperability purposes the last authenticated data field should be used external nonce.

Owing to the use of two keys, the authentication key K1 and encryption key K2, naming schemes for SIV AEAD-variants may lead to some confusion; for example AEAD_AES_SIV_CMAC_256 refers to AES-SIV with two AES-128 keys and not AES-256.

AES-GCM-SIV

[edit]

AES-GCM-SIV is a mode of operation for the Advanced Encryption Standard which provides similar performance to Galois/counter mode as well as misuse resistance in the event of the reuse of a cryptographic nonce. The construction is defined in RFC 8452.[17]

AES-GCM-SIV synthesizes the internal IV. It derives a hash of the additional authenticated data and plaintext using the POLYVAL Galois hash function. The hash is then encrypted an AES-key, and used as authentication tag and AES-CTR initialization vector.

AES-GCM-SIV is an improvement over the very similarly named algorithm GCM-SIV, with a few very small changes (e.g. how AES-CTR is initialized), but which yields practical benefits to its security "This addition allows for encrypting up to 250 messages with the same key, compared to the significant limitation of only 232 messages that were allowed with GCM-SIV."[18]

Confidentiality only modes

[edit]

Many modes of operation have been defined. Some of these are described below. The purpose of cipher modes is to mask patterns which exist in encrypted data, as illustrated in the description of the weakness of ECB.

Different cipher modes mask patterns by cascading outputs from the cipher block or other globally deterministic variables into the subsequent cipher block. The inputs of the listed modes are summarized in the following table:

Summary of modes
Mode Formulas Ciphertext
Electronic codebook (ECB) Yi = F(PlainTexti, Key) Yi
Cipher block chaining (CBC) Yi = PlainTexti XOR Ciphertexti−1 F(Y, Key); Ciphertext0 = IV
Propagating CBC (PCBC) Yi = PlainTexti XOR (Ciphertexti−1 XOR PlainTexti−1) F(Y, Key); Ciphertext0 = IV
Cipher feedback (CFB) Yi = Ciphertexti−1 Plaintext XOR F(Y, Key); Ciphertext0 = IV
Output feedback (OFB) Yi = F(Yi−1, Key); Y0 = F(IV, Key) Plaintext XOR Yi
Counter (CTR) Yi = F(IV + g(i), Key); IV = token() Plaintext XOR Yi

Note: g(i) is any deterministic function, often the identity function.

Electronic codebook (ECB)

[edit]
ECB
Electronic codebook
Encryption parallelizableYes
Decryption parallelizableYes
Random read accessYes
Partial last blockNo

The simplest of the encryption modes is the electronic codebook (ECB) mode (named after conventional physical codebooks[19]). The message is divided into blocks, and each block is encrypted separately. ECB is not recommended for use in cryptographic protocols: the disadvantage of this method is a lack of diffusion, wherein it fails to hide data patterns when it encrypts identical plaintext blocks into identical ciphertext blocks.[20][21][22]

Electronic Codebook (ECB)
ECB mode encryption
ECB mode decryption


A striking example of the degree to which ECB can leave plaintext data patterns in the ciphertext can be seen when ECB mode is used to encrypt a bitmap image which contains large areas of uniform color. While the color of each individual pixel has supposedly been encrypted, the overall image may still be discerned, as the pattern of identically colored pixels in the original remains visible in the encrypted version.

Original image
Using ECB allows patterns to be easily discerned
Modes other than ECB result in pseudo-randomness

ECB mode can also make protocols without integrity protection even more susceptible to replay attacks, since each block gets decrypted in exactly the same way.[citation needed]

Cipher block chaining (CBC)

[edit]
CBC
Cipher block chaining
Encryption parallelizableNo
Decryption parallelizableYes
Random read accessYes
Partial last blockNo

Ehrsam, Meyer, Smith and Tuchman invented the cipher block chaining (CBC) mode of operation in 1976. In CBC mode, each block of plaintext is XORed with the previous ciphertext block before being encrypted. This way, each ciphertext block depends on all plaintext blocks processed up to that point. To make each message unique, an initialization vector must be used in the first block.

Cipher block chaining (CBC)
CBC mode encryption
CBC mode decryption

If the first block has index 1, the mathematical formula for CBC encryption is

while the mathematical formula for CBC decryption is

Example
[edit]
Example
CBC encryption example with a toy 2-bit cipher
CBC decryption example with a toy 2-bit cipher

CBC has been the most commonly used mode of operation. Its main drawbacks are that encryption is sequential (i.e., it cannot be parallelized), and that the message must be padded to a multiple of the cipher block size. One way to handle this last issue is through the method known as ciphertext stealing. Note that a one-bit change in a plaintext or initialization vector (IV) affects all following ciphertext blocks.

Decrypting with the incorrect IV causes the first block of plaintext to be corrupt but subsequent plaintext blocks will be correct. This is because each block is XORed with the ciphertext of the previous block, not the plaintext, so one does not need to decrypt the previous block before using it as the IV for the decryption of the current one. This means that a plaintext block can be recovered from two adjacent blocks of ciphertext. As a consequence, decryption can be parallelized. Note that a one-bit change to the ciphertext causes complete corruption of the corresponding block of plaintext, and inverts the corresponding bit in the following block of plaintext, but the rest of the blocks remain intact. This peculiarity is exploited in different padding oracle attacks, such as POODLE.

Explicit initialization vectors take advantage of this property by prepending a single random block to the plaintext. Encryption is done as normal, except the IV does not need to be communicated to the decryption routine. Whatever IV decryption uses, only the random block is "corrupted". It can be safely discarded and the rest of the decryption is the original plaintext.

Propagating cipher block chaining (PCBC)

[edit]
PCBC
Propagating cipher block chaining
Encryption parallelizableNo
Decryption parallelizableNo
Random read accessNo
Partial last blockNo

The propagating cipher block chaining[23] or plaintext cipher-block chaining[24] mode was designed to cause small changes in the ciphertext to propagate indefinitely when decrypting, as well as when encrypting. In PCBC mode, each block of plaintext is XORed with both the previous plaintext block and the previous ciphertext block before being encrypted. Like with CBC mode, an initialization vector is used in the first block. Unlike CBC, decrypting PCBC with the incorrect IV (initialization vector) causes all blocks of plaintext to be corrupt.

Propagating cipher block chaining (PCBC)
PCBC mode encryption
PCBC mode decryption

Encryption and decryption algorithms are as follows:

PCBC is used in Kerberos v4 and WASTE, most notably, but otherwise is not common.

On a message encrypted in PCBC mode, if two adjacent ciphertext blocks are exchanged, this does not affect the decryption of subsequent blocks.[25] For this reason, PCBC is not used in Kerberos v5.

Cipher feedback (CFB)

[edit]
Full-block CFB
[edit]
CFB
Cipher feedback
Encryption parallelizableNo
Decryption parallelizableYes
Random read accessYes
Partial last blockYes

The cipher feedback (CFB) mode, in its simplest form uses the entire output of the block cipher. In this variation, it is very similar to CBC, turning a block cipher into a self-synchronizing stream cipher. CFB decryption in this variation is almost identical to CBC encryption performed in reverse:

Cipher feedback (CFB)
Cipher feedback (CFB) encryption
Cipher feedback (CFB) decryption
CFB-1, CFB-8, CFB-64, CFB-128, etc.
[edit]

NIST SP800-38A defines CFB with a bit-width.[26] The CFB mode also requires an integer parameter, denoted s, such that 1 ≤ s ≤ b. In the specification of the CFB mode below, each plaintext segment (Pj) and ciphertext segment (Cj) consists of s bits. The value of s is sometimes incorporated into the name of the mode, e.g., the 1-bit CFB mode, the 8-bit CFB mode, the 64-bit CFB mode, or the 128-bit CFB mode.

These modes will truncate the output of the underlying block cipher.

CFB-1 is considered self synchronizing and resilient to loss of ciphertext; "When the 1-bit CFB mode is used, then the synchronization is automatically restored b+1 positions after the inserted or deleted bit. For other values of s in the CFB mode, and for the other confidentiality modes in this recommendation, the synchronization must be restored externally." (NIST SP800-38A). I.e. 1-bit loss in a 128-bit-wide block cipher like AES will render 129 invalid bits before emitting valid bits.

CFB may also self synchronize in some special cases other than those specified. For example, a one bit change in CFB-128 with an underlying 128 bit block cipher, will re-synchronize after two blocks. (However, CFB-128 etc. will not handle bit loss gracefully; a one-bit loss will cause the decryptor to lose alignment with the encryptor)

CFB compared to other modes
[edit]

Like CBC mode, changes in the plaintext propagate forever in the ciphertext, and encryption cannot be parallelized. Also like CBC, decryption can be parallelized.

CFB, OFB and CTR share two advantages over CBC mode: the block cipher is only ever used in the encrypting direction, and the message does not need to be padded to a multiple of the cipher block size (though ciphertext stealing can also be used for CBC mode to make padding unnecessary).

Output feedback (OFB)

[edit]
OFB
Output feedback
Encryption parallelizableNo
Decryption parallelizableNo
Random read accessNo
Partial last blockYes

The output feedback (OFB) mode makes a block cipher into a synchronous stream cipher. It generates keystream blocks, which are then XORed with the plaintext blocks to get the ciphertext. Just as with other stream ciphers, flipping a bit in the ciphertext produces a flipped bit in the plaintext at the same location. This property allows many error-correcting codes to function normally even when applied before encryption.

Because of the symmetry of the XOR operation, encryption and decryption are exactly the same:

Output feedback (OFB)
OFB mode encryption
OFB mode decryption


Each output feedback block cipher operation depends on all previous ones, and so cannot be performed in parallel. However, because the plaintext or ciphertext is only used for the final XOR, the block cipher operations may be performed in advance, allowing the final step to be performed in parallel once the plaintext or ciphertext is available.

It is possible to obtain an OFB mode keystream by using CBC mode with a constant string of zeroes as input. This can be useful, because it allows the usage of fast hardware implementations of CBC mode for OFB mode encryption.

Using OFB mode with a partial block as feedback like CFB mode reduces the average cycle length by a factor of 232 or more. A mathematical model proposed by Davies and Parkin and substantiated by experimental results showed that only with full feedback an average cycle length near to the obtainable maximum can be achieved. For this reason, support for truncated feedback was removed from the specification of OFB.[27]

Counter (CTR)

[edit]
CTR
Counter
Encryption parallelizableYes
Decryption parallelizableYes
Random read accessYes
Partial last blockYes
Note: CTR mode (CM) is also known as integer counter mode (ICM) and segmented integer counter (SIC) mode.

Like OFB, counter mode turns a block cipher into a stream cipher. It generates the next keystream block by encrypting successive values of a "counter". The counter can be any function which produces a sequence which is guaranteed not to repeat for a long time, although an actual increment-by-one counter is the simplest and most popular. The usage of a simple deterministic input function used to be controversial; critics argued that "deliberately exposing a cryptosystem to a known systematic input represents an unnecessary risk".[28] However, today CTR mode is widely accepted, and any problems are considered a weakness of the underlying block cipher, which is expected to be secure regardless of systemic bias in its input.[29] Along with CBC, CTR mode is one of two block cipher modes recommended by Niels Ferguson and Bruce Schneier.[30]

CTR mode was introduced by Whitfield Diffie and Martin Hellman in 1979.[29]

CTR mode has similar characteristics to OFB, but also allows a random-access property during decryption. CTR mode is well suited to operate on a multi-processor machine, where blocks can be encrypted in parallel. Furthermore, it does not suffer from the short-cycle problem that can affect OFB.[31]

If the IV/nonce is random, then they can be combined with the counter using any invertible operation (concatenation, addition, or XOR) to produce the actual unique counter block for encryption. In case of a non-random nonce (such as a packet counter), the nonce and counter should be concatenated (e.g., storing the nonce in the upper 64 bits and the counter in the lower 64 bits of a 128-bit counter block). Simply adding or XORing the nonce and counter into a single value would break the security under a chosen-plaintext attack in many cases, since the attacker may be able to manipulate the entire IV–counter pair to cause a collision. Once an attacker controls the IV–counter pair and plaintext, XOR of the ciphertext with the known plaintext would yield a value that, when XORed with the ciphertext of the other block sharing the same IV–counter pair, would decrypt that block.[32]

Note that the nonce in this diagram is equivalent to the initialization vector (IV) in the other diagrams. However, if the offset/location information is corrupt, it will be impossible to partially recover such data due to the dependence on byte offset.

Counter (CTR)
CTR mode encryption
CTR mode decryption

Error propagation

[edit]

"Error propagation" properties describe how a decryption behaves during bit errors, i.e. how error in one bit cascades to different decrypted bits.

Bit errors may occur intentionally in attacks or randomly due to transmission errors.

  • Random bit errors occur independently in any bit position with an expected probability of ½.
  • Specific bit errors occur in the same bit position(s) as the original bit error(s).
  • Specific bit errors in stream cipher modes (OFB, CTR, etc.) are trivial. They affect only the specific bit intended.
  • Specific bit errors in more complex modes such (e.g. CBC): adaptive chosen-ciphertext attack may intelligently combine many different specific bit errors to break the cipher mode. In Padding oracle attack, CBC can be decrypted in the attack by guessing encryption secrets based on error responses. The Padding Oracle attack variant "CBC-R" (CBC Reverse) lets the attacker construct any valid message.

For modern authenticated encryption (AEAD) or protocols with message authentication codes chained in MAC-Then-Encrypt order, any bit error should completely abort decryption and must not generate any specific bit errors to decryptor. I.e. if decryption succeeded, there should not be any bit error. As such error propagation is less important subject in modern cipher modes than in traditional confidentiality-only modes.

Mode Effect of bit errors in Ci Effect of bit errors in the IV or nonce
ECB Random bit errors in Pi —
CBC Random bit errors in Pi
Specific bit errors in Pi+1		 Specific bit errors in P1
CFB Specific bit errors in Pi
Random bit errors in Pi+1, …, until synchronization is restored		 Random bit errors in P1, …, until synchronization is restored
OFB Specific bit errors in Pi Random bit errors in P1, P2, …, Pn
CTR Specific bit errors in Pi Random bit errors in Pi for bit error in counter block Ti

(Source: SP800-38A Table D.2: Summary of Effect of Bit Errors on Decryption)

It might be observed, for example, that a one-block error in the transmitted ciphertext would result in a one-block error in the reconstructed plaintext for ECB mode encryption, while in CBC mode such an error would affect two blocks. Some felt that such resilience was desirable in the face of random errors (e.g., line noise), while others argued that error correcting increased the scope for attackers to maliciously tamper with a message.

However, when proper integrity protection is used, such an error will result (with high probability) in the entire message being rejected. If resistance to random error is desirable, error-correcting codes should be applied to the ciphertext before transmission.

Other modes and other cryptographic primitives

[edit]

Many more modes of operation for block ciphers have been suggested. Some have been accepted, fully described (even standardized), and are in use. Others have been found insecure, and should never be used. Still others don't categorize as confidentiality, authenticity, or authenticated encryption – for example key feedback mode and Davies–Meyer hashing.

NIST maintains a list of proposed modes for block ciphers at Modes Development.[26][33]

Disk encryption often uses special purpose modes specifically designed for the application. Tweakable narrow-block encryption modes (LRW, XEX, and XTS) and wide-block encryption modes (CMC and EME) are designed to securely encrypt sectors of a disk (see disk encryption theory).

Many modes use an initialization vector (IV) which, depending on the mode, may have requirements such as being only used once (a nonce) or being unpredictable ahead of its publication, etc. Reusing an IV with the same key in CTR, GCM or OFB mode results in XORing the same keystream with two or more plaintexts, a clear misuse of a stream, with a catastrophic loss of security. Deterministic authenticated encryption modes such as the NIST Key Wrap algorithm and the SIV (RFC 5297) AEAD mode do not require an IV as an input, and return the same ciphertext and authentication tag every time for a given plaintext and key. Other IV misuse-resistant modes such as AES-GCM-SIV benefit from an IV input, for example in the maximum amount of data that can be safely encrypted with one key, while not failing catastrophically if the same IV is used multiple times.

Block ciphers can also be used in other cryptographic protocols. They are generally used in modes of operation similar to the block modes described here. As with all protocols, to be cryptographically secure, care must be taken to design these modes of operation correctly.

There are several schemes which use a block cipher to build a cryptographic hash function. See one-way compression function for descriptions of several such methods.

Cryptographically secure pseudorandom number generators (CSPRNGs) can also be built using block ciphers.

Message authentication codes (MACs) are often built from block ciphers. CBC-MAC, OMAC and PMAC are examples.

See also

[edit]

References

[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Block cipher mode of operation

View on Grokipedia
from Grokipedia
A block cipher mode of operation is an algorithm that specifies how a symmetric-key —such as AES, which processes fixed-size blocks (typically 128 bits)—can be applied to messages of arbitrary length to achieve security goals like , , or authenticity. These modes extend the cipher's functionality beyond single-block by incorporating techniques such as feedback, , or counter-based generation of keystreams, often using an (IV) or nonce to ensure unique outputs for identical inputs. The concept of block cipher modes emerged in the late 1970s alongside the , with early formalization in standards like FIPS PUB 81 (1980), which defined four basic confidentiality modes for DES. Over time, modes evolved to address limitations of basic ciphers, incorporating authentication mechanisms and support for associated data, as seen in NIST's SP 800-38 series starting with SP 800-38A (2001), which expanded to five confidentiality modes and influenced international standards like ISO/IEC 10116. Modern modes prioritize efficiency, parallelizability, and resistance to common attacks, with NIST's ongoing updates (e.g., IR 8459 in 2024) recommending against insecure practices like using ECB for sensitive data while preserving legacy modes for compatibility. Modes are broadly categorized into confidentiality-only, authentication (MAC), and authenticated encryption with associated data (AEAD). Key confidentiality modes include:
  • Electronic Codebook (ECB): Encrypts each block independently without an IV, simple but insecure for repetitive data due to pattern leakage.
  • Cipher Block Chaining (CBC): Chains blocks by XORing with the previous block, requiring a random IV and for non-multiple lengths.
  • Cipher Feedback (CFB): Turns the into a self-synchronizing , processing data in segments smaller than the block size.
  • Output Feedback (OFB): Generates a keystream like a , avoiding error propagation but vulnerable to keystream reuse if the IV repeats.
  • Counter (CTR): Uses a counter to produce a keystream via the , enabling parallel processing and no needs.
For authentication, modes like CMAC (based on CBC) provide message codes with provable security under the assumption. AEAD modes, such as Counter with (CCM) and Galois/Counter Mode (GCM), combine and efficiently, supporting associated unencrypted data and widely used in protocols like TLS. Security in these modes relies on proper IV/nonce management—random and unpredictable for , unique and non-repeating for streams—and adherence to bounds like the birthday limit (approximately 2^{n/2} blocks, where n is block size) to prevent attacks. schemes, such as , ensure data aligns with block sizes but introduce risks like padding oracle attacks in CBC if not implemented carefully. NIST recommends misuse-resistant AEAD modes for new systems, emphasizing hardware-accelerated implementations (e.g., AES-NI for GCM) to balance performance and security.

Fundamentals

Block Ciphers and the Need for Modes

A is a symmetric-key cryptographic algorithm that encrypts and decrypts fixed-size blocks of data, typically producing output blocks of equal length, with the process parameterized by a secret key. For instance, the (AES), a widely adopted , operates on 128-bit blocks using key sizes of 128, 192, or 256 bits. Block ciphers first emerged in the 1970s, exemplified by the (DES), which was developed by and adopted as a U.S. federal standard in 1977 for securing 64-bit blocks with a 56-bit key. Directly applying a to messages longer than its fixed block size requires dividing the into independent blocks and encrypting each separately, as in the naive Electronic (ECB) mode. This approach reveals structural patterns in the because identical blocks encrypt to identical blocks, compromising ; for example, a of repeated identical characters, such as "AAAA...A", produces visibly repeating blocks that an attacker can exploit to detect the repetition without knowing the key. Additionally, messages shorter than the block size cannot be encrypted without , and longer messages risk exposing correlations across blocks without further processing. Modes of operation extend s to handle arbitrary-length messages securely by defining methods to chain or feedback block encryptions, thereby providing essential security properties such as and resistance to pattern-based attacks or message malleability. These modes transform the underlying into a versatile tool for real-world applications, mitigating the inherent limitations of block-wise while preserving efficiency.

Initialization Vectors

An initialization vector (IV) is a fixed-length block of random or pseudo-random bits used as an additional input to certain modes of operation, alongside the secret key, to initialize the encryption or decryption process and ensure that identical plaintexts produce distinct ciphertexts under the same key. Typically, the IV length matches the underlying block cipher's block size, such as 128 bits for the (AES). It serves a role analogous to a component but is designed for reuse across messages only under strict conditions to maintain security. For security, an IV must be unpredictable and unique for each encryption operation performed with a given key; predictability or repetition can compromise the confidentiality of the encrypted data. In modes such as Cipher Block Chaining (CBC) and Cipher Feedback (CFB), the IV requires full unpredictability to prevent chosen-plaintext attacks that distinguish encryptions. Output Feedback (OFB) mode treats the IV as a nonce, demanding uniqueness per message but not necessarily randomness. Counter (CTR) mode uses an initial counter value—often derived from an IV or nonce—that must never repeat across messages with the same key to avoid keystream reuse. If the IV is not transmitted to the recipient, it functions as a nonce, generated predictably from shared context like sequence numbers. Generation methods vary by mode to meet these requirements while ensuring efficiency. For CBC, CFB, and OFB, IVs are commonly produced using a FIPS-approved or by applying the to a unique nonce (though the latter is discouraged due to potential weaknesses under the same key). CTR mode typically employs an incrementing counter starting from an initial value, which may incorporate a fixed or derived IV component to span the full block size without overlap. Deriving IVs directly from the key is sometimes used but risks reducing effective key and is generally avoided in favor of independent . Reusing an IV with the same key across multiple messages severely undermines security, often enabling recovery of information or the key itself. In CBC mode, IV reuse effectively creates a two-time pad scenario, where the exclusive-OR of corresponding plaintext blocks from the two messages can be computed from the ciphertexts, leaking sensitive data patterns or allowing partial key recovery. Similar vulnerabilities arise in CFB and OFB, where repeated IVs expose plaintext XOR differences, while in CTR, reuse directly reuses keystream segments, turning the mode into a malleable vulnerable to bit-flipping attacks. NIST recommends limiting the probability of accidental reuse to less than 2^{-32} through sufficiently large IV spaces and rigorous generation practices. In practical protocols, the IV is not required to remain secret and is typically transmitted alongside the ciphertext to enable decryption. For instance, in (TLS) version 1.2 using CBC mode, an explicit IV is generated randomly for each record and prepended to the encrypted data. This approach ensures the recipient can initialize the decryption process without prior shared state, while maintaining the IV's role in achieving .

Padding

Block ciphers process fixed-size blocks of data, typically 128 bits for modern algorithms like AES, requiring input messages to be multiples of this block size for encryption. When a message length is not a multiple of the block size, must be added to extend it to the nearest multiple, ensuring compatibility with modes like CBC that operate on complete blocks. One widely adopted scheme is , which appends a number of bytes equal to the length, with each byte set to that length value. For a block size of 16 bytes, if 3 bytes of are needed, three bytes each with value 0x03 are added; if the message is already a multiple of the block size, a full block of 16 bytes each with value 0x10 is appended. This method, defined for use in , allows unambiguous removal during decryption by checking the last byte's value and verifying that all preceding bytes match it. Another common scheme is ANSI X9.23, which pads with zero bytes followed by a single byte indicating the total padding length. For instance, with 3 bytes needed, it adds two 0x00 bytes and one 0x03 byte. This approach, retained in some implementations for compatibility despite the standard's withdrawal, provides a deterministic way to signal padding boundaries but shares similar removal validation with PKCS#7. ISO 10126, an older scheme, fills the area with random bytes followed by a byte indicating the length, aiming to enhance through unpredictability. However, it was withdrawn in 2007 primarily due to its reliance on the obsolete single-DES encryption. During decryption in chained modes like CBC, is removed by reading the last byte to determine the length and stripping those bytes after verifying their values match the scheme; invalid indicates potential tampering and should trigger rejection of the message to prevent attacks. A notable arises from verification, as demonstrated in attacks where an adversary exploits error messages or timing differences to infer bits. In CBC mode, for example, Serge Vaudenay showed that by querying a — an entity that reveals whether is valid—an attacker can decrypt arbitrary ciphertexts block by block with an average of 128 queries per byte (approximately 2048 queries for a 128-bit block), without knowing the key. Alternatives to traditional padding exist in modes that emulate stream ciphers, such as CTR, where the block cipher generates a keystream via counter increments, allowing direct XOR with plaintext of any length without requiring padding or block alignment. This avoids padding-related overhead and vulnerabilities while maintaining efficiency for variable-length messages.

Historical Development and Standardization

Early Modes

The development of block cipher modes of operation began with the publication of the by the National Bureau of Standards (NBS, predecessor to NIST) in 1977, as specified in FIPS PUB 46, which established DES as a 64-bit based on the Feistel network structure originally proposed by Horst Feistel in the early 1970s. The Feistel structure influenced the design of modes by providing a reversible block transformation suitable for chaining operations. In response to the need for standardized ways to handle data larger than a single block, NBS proposed initial modes of operation, culminating in FIPS PUB 81 approved on December 2, 1980, which defined four modes for DES: Electronic Codebook (ECB), Cipher Block Chaining (CBC), Cipher Feedback (CFB), and Output Feedback (OFB). ECB emerged as the simplest early mode, functioning as a direct that encrypts each block independently using the underlying , making it straightforward but prone to revealing patterns in repetitive data. To mitigate ECB's vulnerability to pattern leakage—where identical plaintext blocks yield identical ciphertext blocks—CBC was developed, with its invention attributed to IBM researchers Eli D. Cohen, William F. Ehrsam, Carl H. W. Meyer, , and Walter L. Tuchman in a 1976 patent application (granted 1978), motivated by the need for diffusion across blocks via XOR chaining. CFB and OFB were proposed around the same time by NBS researchers, aiming to emulate behavior for variable-length data without requiring , by generating a keystream through feedback mechanisms applied to the output. These key events—DES adoption in 1977 and modes standardization in 1980—marked the formalization of operations for federal use, enabling secure handling of bulk data in applications like file encryption and communications. However, early modes lacked built-in , relying solely on , and were susceptible to known-plaintext attacks, especially in ECB where block mappings could be deduced from observed plaintext-ciphertext pairs. These foundations influenced subsequent modern standards.

Modern Standards and Evolution

The selection of the , based on the Rijndael algorithm, in 2001 marked a pivotal advancement in block cipher standardization, replacing the aging and enabling the development of a comprehensive suite of modes tailored for modern applications. This led to the NIST Special Publication (SP) 800-38 series, beginning with SP 800-38A in December 2001, which formalized five confidentiality modes—including the newly introduced Counter (CTR) mode—for use with AES and other approved block ciphers. CTR mode's design allows parallelizable and decryption, addressing performance bottlenecks in high-throughput environments like network communications. The evolution toward with associated data (AEAD) modes accelerated in the early to provide both and integrity in a single primitive, reducing the attack surface compared to separate and authentication. Counter with (CCM) was standardized in September 2003 via RFC 3610, primarily for protocols, combining CTR for with for authentication using 128-bit block ciphers like AES. Galois/Counter Mode (GCM) followed in NIST SP 800-38D in November 2007, leveraging AES in counter mode for and Galois field multiplication for efficient authentication, suitable for hardware-accelerated implementations. These AEAD modes gained widespread adoption due to their resistance to padding oracle attacks, which exploit malleability in padded -only modes like CBC; AEAD constructions avoid traditional altogether, ensuring integrity checks prevent such manipulations. Key protocols further entrenched AEAD standards, with TLS 1.3 (RFC 8446, August 2018) mandating AEAD cipher suites—such as AES-GCM—for all record protection, eliminating legacy non-AEAD options to enhance security against chosen-ciphertext attacks. Similarly, , published in March 2019, updated cryptographic module validation requirements, emphasizing proper nonce and (IV) management to mitigate reuse vulnerabilities in modes like GCM and CCM. Drivers for this shift included demands for hardware efficiency, exemplified by AES-GCM's integration into 3 (WPA3), where its parallelizable operations and low-latency authentication support high-speed wireless encryption without compromising security. Recent developments up to 2025 address lingering issues like nonce misuse, with AES-GCM-SIV standardized in RFC 8452 (April 2019) to provide nonce-misuse resistance; it derives a synthetic IV from the nonce and key, ensuring that nonce repetition leaks only message equality rather than enabling full decryption. Post-quantum considerations have emerged for modes, particularly in adapting classical constructions like CTR and GCM to lattice-based symmetric primitives, as analyzed in security proofs showing their resilience under quantum threats when paired with sufficiently large keys—though NIST's ongoing post-quantum efforts prioritize asymmetric algorithms, modes remain foundational for hybrid systems. In 2024, NIST initiated reviews of SP 800-38B (CMAC), SP 800-38C (CCM), and SP 800-38D (GCM/GMAC) to update these modes for contemporary security needs, with decisions to revise them announced in early 2025. Additionally, NIST launched development of the mode, a new tweakable mode for variable-length inputs as a general-purpose AEAD primitive.

Confidentiality-Only Modes

Electronic Codebook (ECB)

The Electronic Codebook (ECB) mode is the simplest confidentiality-only mode of operation for block ciphers, where each plaintext block is encrypted independently using the same key without any chaining or dependency between blocks. Introduced in the 1980 Federal Information Processing Standard (FIPS) 81 for the Data Encryption Standard (DES), ECB treats the block cipher as a fixed substitution for discrete blocks of data, analogous to looking up entries in a codebook. This mode partitions the plaintext into fixed-size blocks (e.g., 64 bits for DES or 128 bits for AES) and applies the cipher function directly to each, producing corresponding ciphertext blocks. In ECB encryption, for a plaintext consisting of nn blocks P1,P2,…,PnP_1, P_2, \dots, P_n, the jj-th ciphertext block is computed as Cj=CIPHK(Pj),C_j = \text{CIPH}_K(P_j), where CIPHK\text{CIPH}_K denotes the function with key KK, for j=1j = 1 to nn. Decryption reverses this process independently for each block: Pj=CIPHK−1(Cj),P_j = \text{CIPH}^{-1}_K(C_j), where CIPHK−1\text{CIPH}^{-1}_K is the inverse (decryption) function. This independence allows full parallelization of both and decryption operations, making ECB computationally efficient on multi-processor systems, and it avoids propagation, as a transmission in one ciphertext block affects only the corresponding block during decryption. Despite its simplicity, ECB has significant limitations due to its deterministic nature: identical blocks always encrypt to identical blocks under the same key, which can reveal statistical patterns in the . For instance, encrypting structured data like an image may preserve visible outlines in the , as repeated patterns map to repeated blocks. This mode is also vulnerable to block replay attacks, where an adversary can substitute or replay individual blocks to alter specific parts of the decrypted message without detection, especially in protocols lacking . Consequently, ECB is unsuitable for most applications requiring strong , as it lacks diffusion across blocks—unlike chained modes such as CBC—and is explicitly discouraged for encrypting secret data prone to pattern analysis. ECB finds limited use in scenarios involving small, random data where patterns are unlikely, such as single-block encryptions in challenge-response protocols for verification (PIV) cards or legacy systems processing independent data units. It remains approved for such narrow cases but is not recommended for general-purpose encryption due to its inherent weaknesses.

Cipher Block Chaining (CBC)

Cipher Block Chaining (CBC) mode is a block cipher mode of operation that enhances security by chaining blocks with previous blocks through XOR operations, providing better than simpler modes. Introduced in the 1980 specification for (DES) modes, CBC requires an (IV) to start the chaining process and ensures that identical blocks do not produce identical blocks, thereby hiding patterns in the data. In CBC encryption, the first block P1P_1 is XORed with the IV before : C1=EK(P1⊕IV)C_1 = E_K(P_1 \oplus \text{IV}), where EKE_K denotes under key KK. For subsequent blocks, each block PiP_i (for i≥2i \geq 2) is XORed with the previous block: Ci=EK(Pi⊕Ci−1)C_i = E_K(P_i \oplus C_{i-1}). The IV, treated as C0C_0, must be unpredictable and unique per to prevent certain attacks. Decryption reverses this process: the first block is recovered as P1=DK(C1)⊕IVP_1 = D_K(C_1) \oplus \text{IV}, and subsequent blocks as Pi=DK(Ci)⊕Ci−1P_i = D_K(C_i) \oplus C_{i-1}, where DKD_K is the decryption function. This allows parallel decryption but requires sequential . CBC offers advantages over the Electronic Codebook (ECB) mode by diffusing each block's encryption across the entire message, making it more resistant to statistical analysis of patterns. It has been widely adopted in protocols such as TLS 1.2, where suites like TLS_RSA_WITH_AES_128_CBC_SHA are mandatory to implement for compatibility and security. However, CBC is malleable, meaning an attacker who modifies a block can predictably alter the corresponding block during decryption—a bit flip in CiC_i will flip the same bit in PiP_i, while also randomizing Pi+1P_{i+1}. To mitigate risks, the IV must be randomly generated for each message, and the mode provides no , requiring separate checks in practice. Since CBC processes fixed-size blocks, the plaintext must be padded to a multiple of the block length (e.g., 128 bits for AES) before encryption; PKCS#7 padding is typically used, appending bytes whose value equals the number of padding bytes added. This padding is removed during decryption after verifying its validity.

Cipher Feedback (CFB)

Cipher Feedback (CFB) mode is a block cipher mode of operation that transforms a block cipher into a self-synchronizing stream cipher, processing input data in segments of arbitrary size up to the block length. It achieves this by encrypting an initialization vector (IV) or the previous ciphertext block to generate a keystream, which is then XORed with the plaintext segment to produce the corresponding ciphertext segment. The feedback mechanism shifts the output bits, incorporating ciphertext into the next encryption input, allowing for flexible segment sizes ss where 1≤s≤b1 \leq s \leq b and bb is the block size. This mode was originally specified for the Data Encryption Standard (DES) in 1980 and later generalized for any approved block cipher. In operation, CFB begins with an IV serving as the initial input block I1I_1. For subsequent blocks, the input IjI_j is formed by taking the least significant b−sb - s bits of the previous input and appending the most recent ss-bit ciphertext segment. The block cipher encrypts IjI_j to produce output OjO_j, and the most significant ss bits of OjO_j, denoted MSBs(Oj)MSB_s(O_j), are XORed with the ss-bit plaintext segment Pj#P_j^\# to yield the ciphertext segment Cj#=Pj#⊕MSBs(Oj)C_j^\# = P_j^\# \oplus MSB_s(O_j). Decryption reverses this process using the same keystream. For full-block CFB, where s=bs = b, the mode processes entire blocks and resembles Cipher Block Chaining (CBC) but uses only the encryption direction for feedback, avoiding decryption operations. The general form can be expressed as: Oi=MSBs(EK(Ci−1)),Ci=Pi⊕OiO_i = \text{MSB}_s \left( E_K(C_{i-1}) \right), \quad C_i = P_i \oplus O_i where C0C_0 is the IV, and indices denote segments. CFB requires no for non-block-aligned data, as it handles arbitrary segment lengths. CFB offers advantages such as self-synchronization after transmission errors—in 1-bit CFB, correct plaintext recovery resumes after b+1b + 1 bits—and suitability for streaming applications over error-prone channels. However, it mandates serial due to dependency on prior , resulting in slower performance compared to parallelizable modes like Counter (CTR). It finds use in legacy protocols and environments tolerant of limited error propagation, such as certain financial standards for . Unlike Output Feedback (OFB) mode, CFB feeds back rather than keystream output, introducing controlled error propagation for synchronization.

Output Feedback (OFB)

Output Feedback (OFB) mode is a confidentiality-only mode of operation for block ciphers that transforms the cipher into a synchronous by generating a keystream through iterative encryption of an (IV) and previous output blocks, which is then XORed with the to produce . The mode was originally proposed in 1976 during NBS meetings on DES modes of operation and standardized in FIPS PUB 81 (1980). In OFB encryption, the process begins with the IV serving as the initial input block O0=IVO_0 = \text{IV}. Each subsequent output block is computed as Oi=EK(Oi−1)O_i = E_K(O_{i-1}) for i=1,2,…i = 1, 2, \dots, where EKE_K denotes the forward function under key KK. The block CiC_i is then formed by Ci=Pi⊕OiC_i = P_i \oplus O_i, where PiP_i is the corresponding block and ⊕\oplus represents bitwise XOR. For the final partial block of length u<bu < b bits (where bb is the block size), the is Cn∗=Pn∗⊕MSBu(On)C^*_n = P^*_n \oplus \text{MSB}_u(O_n), taking only the most significant uu bits of the output block. Decryption reverses this by regenerating the keystream OiO_i identically and XORing it with the to recover the , ensuring the process is symmetric. A key advantage of OFB is its limited error propagation: a bit error in the affects only the corresponding bit in the decrypted , with no to subsequent blocks, making it suitable for transmission over error-prone channels. Additionally, the keystream can be precomputed independently of the , allowing for stream-like processing without requiring for messages shorter than full blocks. However, the mode operates serially, as each output block depends on the previous one, limiting parallelization during or decryption. From a security perspective, OFB behaves as a , providing equivalent to a pseudorandom function when the IV is unpredictable and unique per message under the same key. Reusing the same IV with the same key across messages is catastrophic, as it reduces the scheme to a two-time pad, allowing an attacker to recover by XORing corresponding ciphertexts. The IV must therefore function as a nonce, never repeating for a given key. OFB finds application in scenarios requiring insensitivity to transmission errors, such as stream over noisy channels like communications, where bit errors are common but propagation must be minimized.

Counter (CTR)

The Counter (CTR) mode transforms a into a by generating a keystream through the of successive counter values, which is then XORed with the to produce the . This approach avoids inter-block dependencies, allowing independent processing of each block. The counter block typically consists of a nonce (a unique value per ) concatenated with an incrementing counter starting from zero. The encryption operation for the ii-th block is given by Ci=Pi⊕EK(nonce∥counteri),C_i = P_i \oplus E_K(\text{nonce} \parallel \text{counter}_i), where EKE_K denotes the block cipher encryption under key KK, ∥\parallel represents , and counteri\text{counter}_i is the counter value for block ii, usually incremented by 1 from the previous. Decryption reverses this process identically, as Pi=Ci⊕EK(nonce∥counteri)P_i = C_i \oplus E_K(\text{nonce} \parallel \text{counter}_i), since XOR is its own inverse. Partial blocks at the message end are handled by truncating the keystream accordingly, eliminating the need for . CTR mode offers several advantages, including high parallelism: multiple blocks can be encrypted or decrypted simultaneously because each requires only a single forward invocation without relying on prior blocks. This enables significant speedups, such as up to 4 times faster software performance compared to chained modes like CBC, and even greater gains (30–100 times) in hardware implementations. Additionally, it supports to any block without sequential processing, making it suitable for applications like where specific sectors may need individual updates. No is required, allowing direct of messages of arbitrary length. Counter management is critical: the full counter block (nonce∥counteri\text{nonce} \parallel \text{counter}_i) must be unique for every plaintext block encrypted under the same key across all messages to prevent keystream reuse. The nonce provides per-message uniqueness, while the counter increments predictably (e.g., via modular addition) within a message, typically limited to 2322^{32} or fewer blocks to avoid overflow risks in 128-bit setups. From a perspective, CTR mode provides equivalent to a pseudorandom function under the assumption that the is a , with tight bounds proven in the multi-user setting. However, nonce reuse with the same key is catastrophic: it allows an attacker to recover the XOR of corresponding blocks by XORing the ciphertexts, as the keystream would be identical. Nonces must therefore be chosen to ensure global uniqueness, often using random or sequential generation. CTR mode is widely used in high-speed network protocols, such as for efficient packet , due to its parallelizability and low latency. It also serves as the confidentiality component in many modes, providing a foundation for constructions like GCM.

Propagating Cipher Block Chaining (PCBC)

Propagating Cipher Block Chaining (PCBC), also known as Plaintext Cipher Block Chaining, is a confidentiality-only mode of operation for s that extends the chaining mechanism of Cipher Block Chaining (CBC) by incorporating both the previous ciphertext and plaintext blocks into the feedback process. This design aims to enhance and provide implicit protection alongside , though it achieves neither goal robustly in practice. PCBC processes data in blocks of fixed size matching the underlying , requiring an (IV) for the first block and propagating feedback through subsequent blocks. In PCBC encryption, the ii-th ciphertext block CiC_i is computed by XORing the ii-th plaintext block PiP_i with both the previous ciphertext block Ci−1C_{i-1} and the previous plaintext block Pi−1P_{i-1} (or the IV for i=1i=1, where P0P_0 is typically zero or omitted), then encrypting the result with the block cipher EKE_K under key KK: Ci=EK(Pi⊕Ci−1⊕Pi−1)C_i = E_K(P_i \oplus C_{i-1} \oplus P_{i-1}) Decryption reverses this by first decrypting the ciphertext block with DKD_K, then XORing the output with the same previous values: Pi=DK(Ci)⊕Ci−1⊕Pi−1P_i = D_K(C_i) \oplus C_{i-1} \oplus P_{i-1} This feedback loop ensures that each block's processing depends on prior plaintext, making parallel decryption impossible and increasing computational interdependence compared to standard CBC. Note that recovering Pi−1P_{i-1} during decryption requires sequential processing from the start, as it is needed for subsequent blocks. PCBC was proposed in the late 1980s during the development of Kerberos Version 4, an authentication protocol from MIT, where it was used with DES to encrypt tickets and provide both confidentiality and a form of integrity checking without separate authentication tags. It appeared in the Kerberos V4 implementation around 1989 but was not formalized in any major cryptographic standard like FIPS or NIST recommendations. A key advantage of PCBC over basic CBC is its improved resistance to certain malleability attacks; modifying a single block alters the decryption of that block and propagates changes to multiple subsequent blocks due to the inclusion of in the feedback, potentially garbling more of the message and making targeted alterations harder. However, this comes at the cost of increased complexity in and , as the dependence on prior complicates error handling and parallelization. Despite its intentions, PCBC has significant disadvantages, including severe error propagation: a bit error or block modification affects not only the immediate block but also the next one (or potentially two, depending on the type), as the corrupted feeds into future chaining, leading to cascading decryption failures. Moreover, it remains non-standard and vulnerable to specific attacks, such as swapping adjacent blocks, which allows an adversary to rearrange message parts without immediately corrupting the entire output. These issues contributed to its limited adoption beyond early Kerberos deployments. Today, PCBC sees minimal use and is considered largely obsolete, having been replaced in modern systems by modes like GCM or CCM that explicitly provide both and without relying on fragile chaining tricks. Kerberos Version 5, standardized in RFC 1510 (1993) and later updates, abandoned PCBC in favor of explicit checksums and standard modes to address these shortcomings.

Authenticated Encryption Modes

Galois/Counter Mode (GCM)

Galois/Counter Mode (GCM) is an authenticated encryption with associated data (AEAD) mode of operation for block ciphers, providing both confidentiality and integrity protection in a single pass. It combines the Counter (CTR) mode for encryption with the GHASH function, a polynomial hash based on multiplication in the finite field GF(2^128), for message authentication. The mode processes the plaintext PP and associated data (AAD) AA using a secret key KK and a nonce NN, producing ciphertext CC and an authentication tag TT. GCM is designed for efficiency in both software and hardware, particularly with 128-bit block ciphers like AES. The encryption step uses CTR mode: the initial counter block J0J_0 is derived from the nonce (typically N∣∣031∣∣1N || 0^{31} || 1 for 96-bit NN), and the ciphertext is Ci=Pi⊕EK(J0+i−1)C_i = P_i \oplus E_K(J_0 + i-1) for i=1i = 1 to mm, where EKE_K is the block cipher encryption and mm is the number of 128-bit blocks in PP. Authentication is computed via GHASH, where the hash subkey H=EK(0128)H = E_K(0^{128}), and the input string is A∣∣0v∣∣C∣∣0u∣∣[∣A∣]64∣∣[∣C∣]64A || 0^{v} || C || 0^{u} || [|A|]_{64} || [|C|]_{64}, with v=(−∣A∣mod  128)v = (-|A| \mod 128), u=(−∣C∣mod  128)u = (-|C| \mod 128), and [⋅]64[ \cdot ]_{64} denoting the 64-bit binary representation of the bit length. The GHASH value S=GHASHH(⋅)S = \mathrm{GHASH}_H(\cdot) is then combined with the counter mode to form the tag: T=MSBt(EK(J0)⊕S)T = \mathrm{MSB}_t( E_K(J_0) \oplus S ), where tt is the tag length. This construction ensures the tag authenticates both the ciphertext and AAD without requiring a separate MAC pass. GCM recommends a 96-bit nonce for optimal performance, though lengths from 1 to 264−12^{64}-1 bits are supported by or derivation, and a 128-bit tag length (with 96, 104, 112, or 120 bits also allowed). The mode is highly parallelizable, as both CTR and GHASH computations can be distributed across multiple blocks independently, enabling high-throughput implementations. In hardware, GCM benefits from dedicated instructions like Intel's AES-NI and PCLMULQDQ, which accelerate AES and Galois field multiplications, achieving speeds exceeding 10 Gbps on modern processors. GCM provides IND-CCA security under the concrete security model when nonces are unique per key, with the adversary's advantage bounded by terms involving the number of blocks processed and nonce length. However, nonce reuse under the same key severely compromises security: it allows recovery of plaintext differences via P1⊕P2=C1⊕C2P_1 \oplus P_2 = C_1 \oplus C_2 from CTR, and enables forgery attacks by exposing the hash key HH or counter collisions. GCM is standardized in protocols such as TLS 1.3, where AES-128-GCM and AES-256-GCM are mandatory-to-implement cipher suites, and IPsec ESP via RFC 4106.

Counter with CBC-MAC (CCM)

Counter with CBC-MAC (CCM) is an authenticated encryption with associated (AEAD) mode of operation for block ciphers, combining the Counter (CTR) mode for confidentiality with (CBC-MAC) for integrity and authenticity. It processes both the plaintext and any associated (AAD) using a single secret key, producing a ciphertext and an authentication tag that verifies both the ciphertext and the AAD. CCM is designed specifically for 128-bit block ciphers, such as AES, and is particularly suited for resource-constrained environments due to its reliance on a single . The operation of CCM involves two main phases: followed by . First, a is computed over the AAD and the padded . The input to the is formatted as a sequence of blocks: the first block includes a Flags octet (indicating AAD presence and lengths), followed by the nonce (7 to 13 octets), length fields for AAD and , the AAD itself (padded if necessary), and the padded to a multiple of the block size. The value, denoted as TT, is the first MM octets (where MM is 4, 6, 8, 10, 12, 14, or 16) of the of the final input block under the key KK. The CC is then generated by XORing the PP with the keystream generated in CTR mode using the same nonce concatenated with an incrementing counter starting from 1. Finally, the tag is U=T⊕U = T \oplus the first MM octets of the CTR keystream for counter value 0 (i.e., CTRK(nonce∥0)\text{CTR}_K(\text{nonce} \| 0)). Decryption reverses this , recomputing the MAC and verifying the tag before releasing the . All operations use the same key KK, ensuring . Key parameters in CCM include the nonce length NN, which ranges from 7 to 13 octets (with the total length field LL from 2 to 8 octets to fit within 128 bits alongside the nonce), and the Flags field, which encodes whether AAD is present, the tag length MM, and the value of LL. The must be unique for each key usage to prevent attacks, as reuse can compromise security. Unlike some modes, the computation is sequential and cannot be parallelized, which may limit performance in high-throughput scenarios but simplifies implementation. CCM's primary advantages stem from its use of a single primitive and key for both and , making it compact and lightweight for devices with limited resources, such as those in protocols. It avoids the need for separate hash functions or multiple primitives, reducing code size and potential vulnerabilities from key separation. Security analyses confirm that CCM provides IND-CCA2 (indistinguishability under ) when the nonce is unique per key and the is secure; the mode is proven secure in the assuming the underlying cipher's pseudorandomness. However, nonce reuse can lead to forgery attacks, emphasizing the need for careful nonce management. CCM does not support longer than 264−12^{64} - 1 octets due to counter overflow risks. CCM is standardized in RFC 3610 and widely adopted in protocols requiring efficient AEAD, including for link-layer security using AES-CCM, IEEE 802.11w for protected management frames via the CCMP protocol, and ESP for .

Synthetic Initialization Vector (SIV)

The Synthetic Initialization Vector (SIV) mode is a block cipher mode of operation designed for authenticated encryption with associated data (AEAD) that provides resistance to nonce misuse, allowing secure operation even when the same nonce is reused across multiple encryptions. It achieves this through a deterministic process that derives a synthetic initialization vector (SIV) from the plaintext and associated data, eliminating the need for a random or unique nonce while maintaining both confidentiality and authenticity. SIV operates in two passes: first computing the synthetic IV using a pseudorandom function on the inputs, then performing encryption in counter (CTR) mode using that IV. The operation begins with the derivation of the synthetic IV, denoted as V=S2VK1(AAD1,…,AADt,P)V = \text{S2V}_{K_1}(\text{AAD}_1, \dots, \text{AAD}_t, P), where S2V is a specific construction based on CMAC (Cipher-based ) applied to the associated data (AAD) strings and PP, using key K1K_1. S2V processes the inputs by iteratively applying the in CMAC mode, incorporating doubling and XOR operations to handle variable-length strings, ensuring the output VV is a 128-bit value for AES. In the second pass, the is encrypted in CTR mode: the counter block is formed as Q=V∧(2128−264)Q = V \land (2^{128} - 2^{64}), and the keystream is generated as Xi=EK2(Q+i)X_i = E_{K_2}(Q + i) for i=0,1,…i = 0, 1, \dots, where EE is the encryption. The ciphertext is then C=P⊕pad(X,∣P∣)C = P \oplus \text{pad}(X, |P|), with to match the length, and the final output is C∣∣VC || V, where VV serves dual roles as the for CTR and the authentication tag. Decryption reverses this process, recomputing VV from the purported and verifying it against the provided tag before applying CTR decryption. SIV's key advantages stem from its deterministic nature and misuse resistance: it produces the same for identical inputs without requiring a random IV or nonce, making it suitable for applications like key wrapping where predictability is needed, and it preserves security even if the same synthetic IV is reused, as long as the total number of encryptions remains bounded. This contrasts with nonce-based modes, where reuse typically compromises security. Security is formalized as a misuse-resistant AEAD (MRAE) scheme, with security that falls off approximately as σ² / 2^n (where σ is the total number of blocks processed and n=128 is the block size), allowing up to 2^{48} encryptions or 2^{64} blocks per key with negligible risk (advantage ≤2^{-56}). However, SIV incurs drawbacks, including the computational overhead of two passes—which requires roughly twice the block cipher invocations of a single-pass mode—and fixed 128-bit tags, which are larger than some alternatives. SIV was standardized in RFC 5297 (2011) for use with AES (in 128-, 192-, and 256-bit key variants, denoted AEAD_AES_SIV_CMAC_256, etc.), and it finds primary application in file encryption and deterministic scenarios where nonce management is impractical, such as secure storage systems.

AES-GCM-SIV

AES-GCM-SIV is a nonce-misuse-resistant authenticated encryption with associated data (AEAD) mode of operation for the (AES) block cipher, providing both confidentiality and authenticity while tolerating nonce reuse without catastrophic security degradation. Developed by researchers including Adam Langley at , it was proposed in 2017 and standardized in RFC 8452 in 2019, building on the efficiency of Galois/Counter Mode (GCM) but incorporating synthetic initialization vector (SIV)-like properties for enhanced robustness. The mode supports AES-128 and AES-256, using a 96-bit nonce and producing a 128-bit authentication tag, with ciphertext length equal to the plaintext plus the tag. The operation of AES-GCM-SIV involves key derivation from the master key and nonce, followed by authentication and encryption using POLYVAL (a polynomial evaluation function over GF(2^{128})) and AES in counter (CTR) mode. For encryption, subkeys are first derived: an authentication key K1K_1 and an encryption key K2K_2 are generated by encrypting the nonce concatenated with small counter values (0 to 3 for AES-128 or 0 to 5 for AES-256) under the master key, using four or six AES block encryptions respectively. A value TT is then computed as the POLYVAL output over the associated data (AAD), padded plaintext PP, and length blocks: T=POLYVALK1(A∗∣∣0∣P∣∣∣P∣∣len(A)∣∣len(P))T = \text{POLYVAL}_{K_1}(A^* || 0^{|P|} || P || \text{len}(A) || \text{len}(P)) where A∗A^* is the padded AAD and lengths are encoded in little-endian blocks. This TT is XORed with the nonce NN (padded to 128 bits), masked by clearing the least significant bit, and encrypted under K2K_2 with an all-zero block (except the final bit set to 1) to produce the authentication tag TAG\text{TAG}: TAG=AESK2(0127∣∣1∣∣((T⊕N~)[127:1]))\text{TAG} = \text{AES}_{K_2} \left( 0^{127} || 1 || ((T \oplus \tilde{N})[127:1]) \right) The is encrypted in CTR mode starting from an initial counter block derived from the TAG (incremented and segmented for parallelization), yielding the CC. Decryption reverses this: CTR decryption produces , POLYVAL is recomputed on AAD and the , and the tag is verified in constant time; rejection occurs if mismatched. This two-pass design for (authentication first, then ) enables parallelism in CTR but requires sequential POLYVAL. Key advantages of AES-GCM-SIV include its balance of performance and security: encryption is approximately 50% slower than AES-GCM due to the extra pass, but decryption achieves speeds within 5% of AES-GCM for messages over a few kilobytes, leveraging hardware-accelerated AES-CTR. POLYVAL offers about 1.2 times the speed of GHASH on modern hardware, and the mode supports up to 2642^{64} messages per key with random nonces. Compared to pure SIV modes, it maintains nonce-based operation for efficiency while deriving per-message subkeys and a synthetic counter from message contents, preventing plaintext recovery on nonce reuse. In terms of security, AES-GCM-SIV achieves indistinguishability under (IND-CCA) even if the same nonce is reused up to 256 times across 2292^{29} messages of 1 GiB each, with an adversary advantage bounded by roughly 3Q2/296+Q⋅B2/21293Q^2 / 2^{96} + Q \cdot B^2 / 2^{129}, where QQ is the number of encryptions and BB the total bits (with Q≤264Q \leq 2^{64}). reuse leaks only equality, not full contents, unlike GCM's total compromise. The resists standard attacks like bit-flipping or oracles through CTR's malleability via the synthetic tag. Adoption of AES-GCM-SIV has grown since its integration into BoringSSL in 2017, powering applications in for secure browsing and protocol source-address token protection. By 2025, it is used in systems (e.g., via Google's Tink library) and messaging platforms like LINE for nonce-vulnerable environments, with IANA registry support (AEAD IDs 30 and 31) facilitating broader protocol integration.

Security Properties and Analysis

Error Propagation

Error propagation refers to the extent to which a bit error in the transmitted affects the decrypted in modes of operation, a critical consideration for applications over unreliable channels such as or links. In noisy environments, where bit error rates (BER) can reach 10^{-6}—meaning one error per million bits transmitted—the choice of mode influences both data usability and . Modes with limited , like stream-cipher emulations, are preferred for such scenarios to minimize data loss beyond the erroneous bits. In Electronic Codebook (ECB) mode, a bit in a block corrupts only the corresponding block, with no to subsequent blocks, as each block is encrypted independently. This isolated impact makes ECB suitable for error-prone channels but vulnerable to pattern analysis, though its handling is straightforward. Similarly, in Counter (CTR) mode, a bit flip affects only the matching bit, exhibiting no due to the independent keystream generation; this property aligns CTR well with high-BER environments like wireless networks. Output Feedback (OFB) mode behaves analogously, where an in the ciphertext keystream segment flips solely the corresponding bit without affecting later blocks, avoiding the seen in chaining modes. Cipher Block Chaining (CBC) mode, by contrast, exhibits more extensive propagation: a single bit error in block CiC_i garbles the entire block PiP_i (due to the block decryption) and flips the corresponding bit in Pi+1P_{i+1} via the XOR chaining, but resynchronizes thereafter, limiting impact to two blocks. In Cipher Feedback (CFB) mode—typically analyzed for s-bit segments—a bit error corrupts the current s-bit segment and injects erroneous feedback into the , garbling the next s bits as well, though it self-heals after one full block as the register shifts out the error. These chaining effects in CBC and CFB can amplify risks in channels with BER around 10^{-6}, potentially corrupting multiple bytes per error event. For with Associated Data (AEAD) modes like Galois/Counter Mode (GCM) and Counter with (CCM), error propagation mirrors the underlying confidentiality component but extends to authentication failure. In GCM, based on CTR encryption, a ciphertext bit error flips only the corresponding bit with no further propagation, yet alters the Galois Hash (GHASH) computation over the , likely causing the authentication tag to mismatch and triggering total message rejection to preserve integrity. CCM combines CTR encryption with , so a bit error affects the current block and the subsequent MAC-chained block (impacting two blocks total), but again, the modified typically invalidates the tag, resulting in outright discard of the message rather than partial decryption. This all-or-nothing rejection in AEAD modes enhances security against tampering but can exacerbate in high-BER settings compared to confidentiality-only modes. Mitigations for error propagation include selecting modes with minimal spread, such as CTR or OFB for noisy channels, and integrating (FEC) techniques that add redundancy to detect and repair bit errors before decryption, reducing effective BER without altering the cipher mode. For instance, FEC can correct errors at rates up to 10^{-6} BER in optical or wireless systems, ensuring reliable propagation even in chaining modes like CBC.

Nonce and IV Security

In block cipher modes of operation, the (IV) or nonce plays a critical role in ensuring by providing uniqueness and unpredictability to each invocation under a given key. Reuse or predictability of these values can lead to severe vulnerabilities, including recovery and forgery attacks, across various modes. NIST Special Publication 800-38A emphasizes that IVs must be unpredictable and unique per key to maintain and prevent such compromises. In Cipher Block Chaining (CBC) mode, reusing the same IV with the same key enables chosen-plaintext attacks where an adversary can recover information about prefixes by comparing ciphertexts, as the XOR operation with the IV chains subsequent blocks predictably. This leakage occurs because the first ciphertext block is effectively the encryption of the XORed with the reused IV, allowing pattern detection without key knowledge. While CBC is more resilient than stream-like modes to single reuses, repeated misuse amplifies risks, underscoring the need for random, unique IVs of at least 128 bits. Counter (CTR) and Galois/Counter (GCM) modes are particularly vulnerable to nonce reuse, as they generate a keystream from the nonce and counter; repetition exposes plaintext via simple XOR of corresponding ciphertexts. In CTR, nonce reuse produces identical keystreams, enabling direct recovery of plaintext XOR differences and trivial data forgery, as demonstrated in contexts where attackers can manipulate packets without . GCM exacerbates this by also compromising authentication: a single reuse allows reconstruction of the authentication key through factorization, enabling precise message forgeries in protocols like TLS, where scans revealed over 184 vulnerable servers. Nonce predictability in CTR mode arises from counter exhaustion, where incrementing the counter beyond its range (typically 32 or 64 bits) under a fixed nonce leads to keystream repetition, effectively reducing to preimage attacks after 2^{n/2} blocks for an n-bit block size. This risk is mitigated by ensuring the full nonce-counter pair spans at least 128 bits without wraparound, but poor can cause unintended reuse in high-volume scenarios. Best practices for nonce and IV management include using 96-bit nonces for GCM to balance efficiency and , with a recommended limit of 2^{32} invocations per key to avoid reuse probabilities exceeding 50% under random generation. For general modes, IVs or nonces should be at least 64 bits and randomly generated or derived protocol-wide for , as in TLS where numbers ensure per-session distinctness. NIST SP 800-38A further advises against predictable constructions, favoring FIPS-approved random number generators. A notable historical incident occurred in 2017 with the (Key Reinstallation Attack) on WPA2, where attackers forced nonce reuse during the 4-way handshake, reinstalling keys and enabling packet decryption, replay, and injection across all Wi-Fi devices, including severe impacts on Android implementations. To address these risks, misuse-resistant modes like Synthetic Initialization Vector (SIV) have been developed, which treat the IV as a synthetic construct from the message and header, preserving security even under full nonce reuse by deriving unique values deterministically without relying on nonce uniqueness. Standardized in RFC 5297, SIV ensures privacy and authenticity unless identical (header, ) pairs are repeated. Variants like AES-GCM-SIV extend this to high-performance . As of 2025, NIST Special Publication 800-38D is under revision to enhance GCM nonce management, proposing variants for larger block ciphers (e.g., 256-bit) to expand nonce spaces to 2^{64} and endorsing derivation methods like DNDK-GCM for rapid deployment against in high-throughput applications. These updates aim to reduce rekeying frequency while maintaining forgery resistance.

Other Cryptographic Considerations

modes without , such as CBC and CFB, exhibit malleability, allowing an adversary to predictably alter by modifying blocks—for instance, flipping a bit in a ciphertext block can cause a corresponding predictable change in the decrypted plaintext of the subsequent block. This property enables attacks like chosen-ciphertext manipulations without detection, as the decryption process chains dependencies that propagate alterations in a controllable manner. In contrast, modes like GCM incorporate an authentication tag that verifies both and , rendering such malleability attacks infeasible since any ciphertext modification invalidates the tag. Side-channel attacks pose significant risks to implementations of various modes, exploiting unintended information leakage through timing, power, or cache access patterns. In CBC mode, padding oracle attacks leverage timing differences during decryption and padding validation to recover byte-by-byte, as originally demonstrated against padding schemes. For instance, the refines this by exploiting subtle timing variations in TLS implementations using CBC, even with countermeasures. GCM is susceptible to cache-timing attacks on its GHASH authentication component due to table lookups dependent on secret data, potentially leaking the hash key through cache contention. Mitigations for these vulnerabilities include constant-time implementations that avoid conditional branches and data-dependent accesses, ensuring uniform execution regardless of input. Quantum computing introduces threats to the long-term security of modes via algorithms like Grover's, which provides a quadratic for brute-force key searches, effectively halving the security level of symmetric keys—for example, reducing AES-128's 128-bit security to 64 bits. To counter this, modes employing larger keys, such as AES-256 in CTR or GCM, maintain adequate post-quantum security levels around 128 bits, as recommended for symmetric primitives. While quantum threats primarily target asymmetric , NIST's 2024 post-quantum standards (FIPS 203, 204, and 205) emphasize hybrid approaches, but symmetric modes remain viable with adjustments up to 2025 guidelines. Performance trade-offs among modes influence their suitability for different hardware and workloads, particularly regarding parallelism. CTR and GCM support full of encryption and decryption across blocks, enabling efficient utilization of multi-core processors and hardware accelerators, which is critical for high-throughput applications. Conversely, CBC requires sequential processing due to its dependency, limiting scalability on parallel architectures and increasing latency for large data. These differences can result in GCM outperforming CBC by factors of 2-10x in parallel environments, though CBC may suffice for simpler, serial-bound scenarios. Selecting a mode depends on the , prioritizing alone with CTR for scenarios without needs, or opting for AEAD modes like GCM when both and are required to resist active adversaries. NIST guidelines advocate AEAD modes for new protocols to address comprehensive security, balancing computational overhead against protection levels.

Additional Modes and Primitives

Stream Cipher Emulation

Block cipher modes such as Cipher Feedback (CFB), Output Feedback (OFB), and Counter (CTR) transform a into a , enabling of variable-length data without requiring , which is essential for processing byte streams or arbitrary data sizes. In CFB and OFB modes, the generates a keystream that is XORed with segments, allowing operation on sub-block sizes; for instance, CFB supports segment sizes ss from 1 to the full block length bb (e.g., 8 bits for byte-oriented streams), while OFB uses the most significant uu bits of the output for partial blocks. These modes emulate asynchronous (OFB) or self-synchronizing (CFB) , where CFB feeds back to recover from after a limited number of blocks, unlike OFB's across the entire stream. Among these, CTR mode has become the preferred method for modern stream emulation due to its lack of synchronization dependencies and support for parallel processing, avoiding the sequential feedback in CFB and OFB that can introduce latency or . In CTR, a unique counter block is incremented for each position and encrypted to produce the keystream, enabling independent block computations without reliance on prior ciphertext or outputs. This design parallels the keystream generation in native ciphers like , but leverages the block cipher's for stronger guarantees, provided counter blocks remain unique across all encryptions under the same key to prevent keystream reuse and potential disclosure of XOR differences. These emulation modes find applications in real-time communications, such as (VoIP), where is undesirable due to latency constraints and variable packet sizes; for example, the (SRTP) employs AES in a variant of CTR mode to encrypt RTP packets efficiently without block alignment issues. In such scenarios, the stream-like behavior ensures low-overhead processing of continuous data flows, maintaining synchronization only through the initial vector or counter. Despite these advantages, block cipher emulation incurs overhead from full-block operations, making it less efficient in software compared to native stream ciphers like ChaCha20, which achieves higher throughput on general-purpose processors without hardware acceleration. This performance gap is particularly evident in resource-constrained environments, where ChaCha20's ARX-based design avoids the substitution-permutation complexities of block ciphers, reducing implementation time and side-channel vulnerabilities. Over time, there has been a shift toward native with associated data (AEAD) stream ciphers, exemplified by ChaCha20 combined with Poly1305, which provides both and in a single primitive suitable for protocols like TLS and , addressing the limitations of unauthenticated block emulations. This evolution, formalized in RFC 7539, prioritizes software efficiency and nonce-based security for high-speed networks, marking a departure from traditional block-based streams in favor of dedicated designs.

Disk Encryption Modes

Disk encryption modes are specialized block cipher constructions designed for protecting data at rest on storage devices, such as hard drives or solid-state drives, where to sectors is essential and performance overhead must be minimized. These modes address unique challenges in storage environments, including the need to encrypt fixed-size sectors (typically 512 bytes or 4 KB) without requiring initialization vectors per block, while supporting partial overwrites and maintaining against attacks like copy-paste manipulation. Unlike transmission-oriented modes, they incorporate tweaks derived from sector addresses to ensure position-dependent encryption, preventing identical blocks in different locations from producing the same . The predominant mode in this domain is XTS-AES, standardized in IEEE Std 1619-2007 and revised in subsequent standards, including IEEE Std 1619-2025, and approved by NIST in Special Publication 800-38E for on block-oriented storage devices. XTS-AES, an instantiation of the XEX (XOR-encrypt-XOR) tweakable with , uses two AES keys: one for data (K1) and one for generating tweaks (K2). For a sector identified by tweak T (a 128-bit representation of the sector number), each 128-bit block j within the sector is processed as follows:
  • Compute the sector tweak: α\alpha is a primitive element in GF(2^{128}), and the block tweak is I=AES-EncK2(T)⊗αjI = \text{AES-Enc}_{K_2}(T) \otimes \alpha^j, where ⊗\otimes denotes in GF(2^{128}).
  • Encrypt the block: Cj=AES-EncK1(Pj⊕I)⊕IC_j = \text{AES-Enc}_{K_1}(P_j \oplus I) \oplus I.
For sectors not aligned to full 128-bit blocks, allows the final partial block to be handled by swapping and encrypting with the preceding block's tweak, preserving data length without . This construction enables parallel processing and pipelining, making it suitable for high-throughput storage encryption. Key advantages of XTS-AES include its ability to operate without per-block IVs, reducing metadata overhead, and its resilience to partial sector writes common in operations. It provides strong confidentiality for data units up to 2202^{20} AES blocks (approximately 16 MiB per data unit) while avoiding the malleability issues in earlier modes. However, XTS-AES offers no built-in , relying on higher-layer filesystem checks to detect tampering; it is vulnerable to chosen-plaintext attacks if misused beyond storage contexts. analyses confirm its provable as a tweakable strong under assumptions, with a security bound of roughly q2/2nq^2 / 2^n for q queries and n-bit blocks, where identical subkeys degrade it to this level. Prior to XTS-AES, alternatives included the XE(S)CK modes proposed by Halevi and Rogaway in , which extend XEX with for handling non-multiples of block size but lack the refined tweakable security proofs of XTS. The LRW (Liskov-Rivest-Wagner) mode from 2002, an early tweakable construction using a single-key XOR-encrypt-XOR approach, was widely implemented but deprecated due to vulnerabilities like weak diffusion against certain attacks and incompatibility with modern standards; it is now considered legacy in tools like cryptsetup. XTS-AES has seen broad adoption in production systems. BitLocker employs XTS-AES 128-bit by default for operating system and fixed drives, with 256-bit support for enhanced . The Linux kernel's subsystem integrates XTS-AES as the recommended mode for LUKS-based full-disk , leveraging kernel crypto APIs for efficient performance. In mobile environments, Android's File-Based Encryption (FBE), introduced in Android 7.0 and standard through 2025, uses AES-256-XTS to independently encrypt file contents, enabling granular key management without full-disk unlocks.

References

  1. https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-38a.pdf
  2. https://web.cs.ucdavis.edu/~rogaway/papers/modes.pdf
  3. https://nvlpubs.nist.gov/nistpubs/ir/2024/NIST.IR.8459.pdf
  4. https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.197-upd1.pdf
  5. https://www.nccoe.nist.gov/news-insights/cornerstone-cybersecurity-cryptographic-standards-and-50-year-evolution
  6. https://intronetworks.cs.luc.edu/current1/mob2/security.html
  7. https://csrc.nist.gov/projects/block-cipher-techniques/BCM
  8. https://www.cs.cornell.edu/courses/cs5430/2017sp/l/07-asymm-enc/notes.html
  9. https://datatracker.ietf.org/doc/html/rfc5246
  10. https://datatracker.ietf.org/doc/html/rfc5652#section-6.3
  11. https://learn.microsoft.com/en-us/dotnet/api/system.security.cryptography.paddingmode
  12. https://crypto.stackexchange.com/questions/1922/why-was-iso10126-padding-withdrawn
  13. https://www.torsten-schuetze.de/sommerakademie2009/papers-sekundaer/Vaudenay-CBC-Padding-Flaws-2002.pdf
  14. https://patents.google.com/patent/US4074066A/en
  15. https://csrc.nist.gov/projects/cryptographic-standards-and-guidelines/archived-crypto-projects/aes-development
  16. https://csrc.nist.gov/pubs/sp/800/38/a/final
  17. https://datatracker.ietf.org/doc/html/rfc3610
  18. https://csrc.nist.gov/pubs/sp/800/38/d/final
  19. https://blog.cloudflare.com/padding-oracles-and-the-decline-of-cbc-mode-ciphersuites/
  20. https://datatracker.ietf.org/doc/html/rfc8446
  21. https://csrc.nist.gov/pubs/fips/140-3/final
  22. https://www.portnox.com/cybersecurity-102/wpa3/
  23. https://datatracker.ietf.org/doc/html/rfc8452
  24. https://eprint.iacr.org/2023/218.pdf
  25. https://csrc.nist.gov/news/2024/nist-to-revise-sp-800-38d-gcm-and-gmac-modes
  26. https://csrc.nist.gov/News/2025/decision-to-revise-sp-800-38b-and-38c
  27. https://csrc.nist.gov/News/2025/nist-launches-development-cryptographic-accordions
  28. https://nvlpubs.nist.gov/nistpubs/Legacy/FIPS/fipspub81.pdf
  29. https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-57pt1r5.pdf
  30. https://doi.org/10.6028/NIST.SP.800-38A
  31. https://csrc.nist.gov/pubs/fips/81/final
  32. https://csrc.nist.gov/publications/detail/sp/800-38a/final
  33. https://crypto.stackexchange.com/questions/98376/who-is-the-inventor-of-the-ofb-block-cipher-mode-of-operation
  34. http://koclab.cs.ucsb.edu/teaching/cs178/docx/d-modes2.pdf
  35. https://www.cs.ucdavis.edu/~rogaway/papers/ctr.pdf
  36. https://web.mit.edu/tlyu/papers/krb4peril-ndss04.pdf
  37. https://www.sciencedirect.com/science/article/abs/pii/S0167739X03002401
  38. http://www.contrib.andrew.cmu.edu/~shadow/crypt/Cryptography_FAQ_%2805_10:_Product_Ciphers%29
  39. https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-38d.pdf
  40. https://eprint.iacr.org/2004/193
  41. https://datatracker.ietf.org/doc/html/rfc4106
  42. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-121r2.pdf
  43. https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-97.pdf
  44. https://web.cs.ucdavis.edu/~rogaway/papers/siv.pdf
  45. https://datatracker.ietf.org/doc/html/rfc5297
  46. https://eprint.iacr.org/2017/168
  47. https://datatracker.ietf.org/doc/html/rfc8452#section-4
  48. https://eprint.iacr.org/2017/168.pdf
  49. https://datatracker.ietf.org/doc/html/rfc8452#section-5
  50. https://datatracker.ietf.org/doc/html/rfc8452#section-5.2
  51. https://datatracker.ietf.org/doc/html/rfc8452#section-2
  52. https://datatracker.ietf.org/doc/html/rfc8452#section-7
  53. https://datatracker.ietf.org/doc/html/rfc8452#section-7.1
  54. https://datatracker.ietf.org/doc/html/rfc8452#section-10
  55. https://engineering.linecorp.com/en/blog/AES-GCM-SIV-optimization
  56. https://ib-lenhardt.com/kb/glossary/bit-error-rate
  57. https://www.cs.columbia.edu/~smb/classes/f20/l_crypto-3-modes.pdf
  58. https://www.utdallas.edu/~muratk/courses/crypto09s_files/modes.pdf
  59. https://www.cs.purdue.edu/homes/ninghui/courses/Fall05/lectures/355_Fall05_lect16.pdf
  60. https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38d.pdf
  61. https://pmc.ncbi.nlm.nih.gov/articles/PMC12158371/
  62. https://datatracker.ietf.org/doc/html/rfc3686
  63. https://www.usenix.org/system/files/conference/woot16/woot16-paper-bock.pdf
  64. https://papers.mathyvanhoef.com/ccs2017.pdf
  65. https://csrc.nist.gov/pubs/sp/800/38/d/r1/iprd
  66. https://www.bearssl.org/constanttime.html
  67. https://csrc.nist.gov/projects/post-quantum-cryptography/faqs
  68. https://www.nist.gov/news-events/news/2024/08/nist-releases-first-3-finalized-post-quantum-encryption-standards
  69. https://cr.yp.to/bib/2002/mcgrew.pdf
  70. https://www.rfc-editor.org/rfc/rfc3711.html
  71. https://blog.cloudflare.com/do-the-chacha-better-mobile-performance-with-cryptography/
  72. https://www.rfc-editor.org/rfc/rfc7539.html
  73. https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38e.pdf
  74. https://standards.ieee.org/ieee/1619/11552/
  75. https://luca-giuzzi.unibs.it/corsi/Support/papers-cryptography/1619-2007-NIST-Submission.pdf
  76. https://csrc.nist.gov/CSRC/media/Projects/Block-Cipher-Techniques/documents/BCM/Comments/XTS//XTS_comments-Liskov_Minematsu.pdf
  77. https://learn.microsoft.com/en-us/windows/security/operating-system-security/data-protection/bitlocker/
  78. https://docs.kernel.org/admin-guide/device-mapper/dm-crypt.html
  79. https://source.android.com/docs/security/features/encryption/file-based
Add your contribution
Related Hubs
Contribute something
User Avatar
No comments yet.