Block and stream ciphers↑

Symmetric encryption uses two main types of algorithms: block ciphers and stream ciphers. Although both are used for symmetric encryption, they operate differently. A block cipher maps a fixed length data string—a block—to a string of the same length, such as the 128-bit blocks in AES, using a secret key. A stream cipher, in contrast, gradually encrypts data often byte-by-byte.

To turn a block cipher into an encryption algorithm, it must use a mode of operation.¹ A mode of operation specifies how a block cipher encrypts and decrypts data. Common modes include GCM, CCM, and CBC. For example, AES256-GCM uses the AES block cipher with 256-bit secret keys in GCM mode. Each mode has distinct security properties, trade-offs, and usage requirements. For instance, GCM is insecure if initialization vectors (IVs) are ever repeated. Since stream ciphers are already encryption algorithms, no mode of operation is required.

Introduction to symmetric encryption↑

Symmetric encryption, which uses the same key for both encryption and decryption, relies on two main types of categories: block ciphers and stream ciphers.

Block ciphers operate on fixed-size data blocks and require a mode of operation to encrypt data. The mode impacts properties like security guarantees, efficiency, and ability to process data in parallel. Stream ciphers, on the other hand, encrypt data continuously, making them ideal for real-time applications where minimal latency and flexibility are essential.

The Advanced Encryption Standard (AES), defined in FIPS 197, is the most common block cipher and is widely deployed across various applications, with most modern devices supporting hardware acceleration. In the context of lightweight cryptography, recent efforts have explored alternatives optimized for resource-constrained environments. Notably, NIST SP 800-232 (IPD) proposes a series of constructions based on Ascon, a family of lightweight cryptographic primitives designed for efficiency, security, and adaptability in constrained settings, with authenticated encryption as a key use case.

Now that we’ve outlined the key characteristics of block and stream ciphers, we’ll examine block ciphers in detail, followed by stream ciphers.

Block ciphers↑

Block ciphers transform fixed-size data units known as blocks. The input and output blocks have the same length, or block size. For example, AES, as defined in FIPS 197, uses 128-bit blocks, while the obsolete DES (Data Encryption Standard), previously specified in FIPS 46-3 (withdrawn), used 64-bit blocks.

The block size is one of many factors that affect security. In general, larger block sizes provide stronger security by reducing attack risks. A 128-bit block size is currently considered sufficient for modern encryption.

Block ciphers require a secret key to operate, and can support different key lengths to provide varying levels of security. Key length is not necessarily related to the block size. AES, for example, uses 128-bit blocks, but supports 128-, 192-, and 256-bit secret keys but always operates on 128-bit blocks. In AES, the key length determines the number of encryption rounds:

• AES-128 has 10 rounds
• AES-192 has 12 rounds
• AES-256 has 14 rounds

A round refers to a series of cryptographic transformations applied to the input data (at the first round, this data would be the block cipher’s input) to progressively convert it into the output, as defined by the cipher’s design. More rounds (which basically repeat the same round) generally improve resistance to attacks.

Block cipher modes of operation↑

A block cipher mode of operation, often referred to as a mode, turns a block cipher into an actual encryption scheme that handles variable-length data and, critically, provides security assurances expected from an encryption scheme. However, modes vary in security, and choosing the appropriate mode for the application is crucial. For example, the Electronic Code Book (ECB) mode, which simply uses the block cipher to encrypt data in chunks of length of the block size, is generally considered insecure.

Overview of existing modes↑

Table 1 summarizes the modes specified in NIST SP 800-38, which spans eight parts (SP 800-38A to SP 800-38G).

Each entry includes:

1. The mode’s acronym.
2. The mode’s full name.
3. Whether it supports encryption and/or authentication.
4. The required additional input such as Initialization Vector (IV), nonce, or tweak.
5. Padding requirements.
6. A brief description.
7. A reference to the corresponding publication.

Table 1. Listing of the block cipher modes of operation specified in NIST 800-38 series.

Different modes combine the block cipher in different ways, balancing security, efficiency, and functional properties. For example, Cipher Block Chaining (CBC) chains ciphertext blocks, requiring sequential processing. Counter (CTR) mode, on the other hand, generates a keystream from a nonce and counter, enabling parallelism and precomputation.

Some modes, including CBC, require adding extra bytes, also known as padding, to align the input data with the block size. One common padding scheme is PKCS#7 (refer to RFC 5652). However, padding can introduce vulnerabilities, such as “padding oracle” attacks on CBC.

For general applications, authenticated encryption modes, such as GCM, are recommended. These modes provide both confidentiality and integrity, protecting data from eavesdropping and unauthorized modifications. Preventing unauthorized modification also defends against attacks that try to break confidentiality by modifying ciphertexts during transmission.

Using encryption without authentication, such as CBC without a message authentication code, can leave data vulnerable to devastating attacks, like the padding-related vulnerabilities mentioned above. Therefore, authenticated encryption modes should be used unless separate authentication mechanisms are specifically required.

IVs, nonces, tweaks, and vulnerabilities↑

Symmetric encryption requires additional inputs, such as initialization vectors (IVs), nonces, or tweaks to ensure security. These inputs prevent identical plaintexts from producing identical ciphertexts. Their exact size varies depending on the encryption mode, but they’re typically around 128 bits for AES. For instance, AES-GCM IVs are commonly 96 bits, while other AES-based modes such as CBC typically use 128-bit IVs.

To ensure security in some cases, these inputs must be unpredictable (for example, not deterministically guessable by an attacker)⁶ and/or unique (which means they must never be reused with the same secret key). In general, IVs, nonces, or tweaks are publicly transmitted or stored alongside ciphertexts, as their secrecy isn’t required for security.

Improper usage however can lead to critical security vulnerabilities. Some important highlights are:

• AES-GCM IVs must never be reused with the same key, as doing so would allow attackers to recover authentication keys and forge ciphertexts.
• In AES-CTR and AES-OFB, IV reuse is a critical vulnerability because it causes keystream reuse, allowing attackers to recover the relation (such as the XOR) between two plaintexts by relating (XORing) their ciphertexts.
• In AES-CBC, IV reuse makes ciphertexts more susceptible to cryptanalysis and inference attacks by revealing patterns across messages.

This discussion emphasizes the need for careful consideration when making decisions about IVs, nonces, or tweaks. The relevant documentation should always be consulted to ensure compliance with requirements. For example:

• NIST SP 800-38A provides guidance on IV generation in Appendix C, “Generation of Initialization Vectors”. It also includes considerations applicable to nonces for the CTR mode in Appendix B, “Appendix B: Generation of Counter Blocks”.
• NIST SP 800-38D discusses GCM IV constructions in section 8.2. Additionally, section 8.3 highlights an important point: “The total number of invocations of the authenticated encryption function shall not exceed 232** ” when non-96-bit deterministic IVs or random IVs are used.
• NIST SP 800-38G discusses tweaks in Appendix C, “Tweaks”, in the context of format-preserving encryption. It also provides useful considerations in Appendix A, “Parameter Choices and Security”.

Stream ciphers↑

Stream ciphers encrypt data by processing it as a continuous stream of bits or bytes, unlike block ciphers which operate on fixed-size blocks. They generate a keystream—a pseudorandom sequence of bits that is XORed with the plaintext to produce ciphertext.⁷ This approach allows for high-speed encryption, making stream ciphers well-suited for real-time communications, such as secure network protocols, voice and video transmissions, and embedded systems.

One of the main advantages of stream ciphers is their efficiency. Since they don’t require buffering an entire block before encryption, they can operate with low latency and minimal memory usage. This makes them ideal for environments where computational resources are limited, such as IoT devices and wireless communications.

However, stream ciphers also have disadvantages—the most critical being that they require a truly unique keystream for each encryption session. Reusing the same keystream for multiple messages results in loss of confidentiality because attackers can recover non-trivial relations between plaintexts by XORing the corresponding ciphertexts encrypted with the same keystream. Also, some older stream ciphers, like RC4, have known weaknesses, making them unsuitable for modern applications.

Notable stream ciphers↑

ChaCha20 is a modern stream cipher that improves upon the Salsa20 family. It uses a simple but highly efficient structure based on add-rotate-xor (ARX) operations, making it resistant to cryptanalysis while performing well on a variety of hardware architectures. Unlike RC4, ChaCha20 is secure against known attacks and has been standardized in RFC 8439 for use in TLS and other security protocols. However, ChaCha20 requires an additional authentication mechanism, such as Poly1305.

RC4 (Rivest Cipher 4) was one of the most widely used stream ciphers, employed in protocols like SSL/TLS, WEP, and WPA. Designed by Ron Rivest in 1987, RC4 generates a keystream using a permutation-based approach. Although initially considered secure, vulnerabilities were later discovered, including output biases that allowed plaintext recovery under certain conditions. These weaknesses led to RC4’s deprecation for use in cryptographic applications.

Other stream ciphers↑

In addition to RC4 and ChaCha20, several other stream ciphers have been designed for specific security and performance needs. The eSTREAM portfolio, which was developed as part of the ECRYPT project, features ciphers like HC-128, Rabbit, and Grain, which were designed to provide strong security with efficient performance on resource-constrained devices.

Sources↑

• NIST SP 800-38A: Recommendation for Block Cipher Modes of Operation: Methods and Techniques
• NIST SP 800-38B: Recommendation for Block Cipher Modes of Operation: the CMAC Mode for Authentication
• NIST SP 800-38C: Recommendation for Block Cipher Modes of Operation: the CCM Mode for Authentication and Confidentiality
• NIST SP 800-38D: Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC
• NIST SP 800-38E: Recommendation for Block Cipher Modes of Operation: the XTS-AES Mode for Confidentiality on Storage Devices
• NIST SP 800-38F: Recommendation for Block Cipher Modes of Operation: Methods for Key Wrapping
• NIST SP 800-38G: Recommendation for Block Cipher Modes of Operation: Methods for Format-Preserving Encryption
• FIPS 197: Advanced Encryption Standard (AES)
• FIPS 46-3 (Withdrawn on May 19, 2005) Data Encryption Standard (DES)
• 1619-2007 - IEEE Standard for Cryptographic Protection of Data on Block-Oriented Storage Devices
• RFC 5652 - Cryptographic Message Syntax (CMS)
• RFC 8439 - ChaCha20 and Poly1305 for IETF Protocols
• Knowledge base: Message Authentication Codes (MACs)
• Knowledge base: Chosen ciphertext attacks