Symmetric Encryption

Introduction

Symmetric encryption is a foundational technique for protecting information. It uses the same secret key, or closely related secret keys, to transform readable plaintext into ciphertext and to recover the plaintext. Because symmetric algorithms are generally much faster than public-key algorithms, they protect most of the data transmitted and stored in modern systems. Web connections, virtual private networks, encrypted disks, databases, messaging applications, and cloud services all depend heavily on symmetric encryption.

Encryption does not by itself solve every security problem. A secure system must also protect keys, authenticate messages, select safe algorithm modes, manage nonces and initialization vectors correctly, and resist implementation errors. This chapter explains stream and block ciphers, the Advanced Encryption Standard (AES), modes of operation, initialization vectors, padding, authenticated encryption, appropriate use cases, obsolete algorithms, and common failures.

Learning Objectives

By the end of this chapter, you should be able to:

• distinguish stream ciphers from block ciphers;
• describe the structure and security purpose of AES;
• explain why block-cipher modes of operation are required;
• distinguish initialization vectors, nonces, keys, and salts;
• explain padding and identify padding-related weaknesses;
• describe authenticated encryption and associated data;
• recognize obsolete algorithms and unsafe configurations;
• select suitable symmetric-encryption approaches for common security scenarios.

1. The Symmetric-Encryption Model

In a symmetric system, sender and receiver share a secret key K. Encryption transforms plaintext P into ciphertext C:

Decryption reverses this transformation:

Here, E_K is the encryption function under key K, and D_K is the corresponding decryption function. The functions are inverses for valid keys and ciphertexts. The model assumes that the algorithm is publicly known and that the key remains secret. This principle, associated with Kerckhoffs’s principle, is essential: security should depend on the secrecy of the key, not on hiding the algorithm.

Symmetric encryption primarily provides confidentiality. It does not automatically provide integrity, authenticity, freshness, or protection against replay. For example, an attacker who cannot read an encrypted message may still modify, delete, duplicate, or reorder it unless an integrity mechanism is included.

Key distribution is a central challenge. If two parties have never communicated, securely giving them a shared secret may be difficult. Public-key cryptography commonly solves this initial key-establishment problem; after a session key is negotiated, symmetric encryption protects the bulk data efficiently.

2. Stream Ciphers and Block Ciphers

Stream ciphers

A stream cipher encrypts data as a sequence of bits or bytes. It generates a pseudorandom keystream from a key and usually a nonce. The plaintext is combined with the keystream using exclusive OR (XOR):

where P_i is a plaintext unit, S_i is the corresponding keystream unit, C_i is ciphertext, and XOR is applied bit by bit. Decryption uses the same operation:

The keystream must never be reused with the same key and nonce. If two plaintexts use the same keystream, then:

This can reveal relationships between the plaintexts and may enable recovery of both messages when some content is known or predictable. Modern examples include ChaCha20 and the stream-cipher component of ChaCha20-Poly1305.

Stream ciphers are useful for variable-length data and applications requiring low latency. They do not require padding. However, encryption alone does not detect modifications; a message-authentication mechanism is still needed.

Block ciphers

A block cipher transforms fixed-size blocks under a secret key. AES, for example, processes 128-bit blocks. A block cipher alone cannot directly encrypt an arbitrary-length file or message safely. A mode of operation specifies how blocks are linked, how an IV or nonce is used, and how errors behave.

Block ciphers are valuable because one well-studied primitive can support many applications. Poor mode selection, however, can eliminate the security of the underlying cipher. Electronic Codebook (ECB), for example, encrypts each block independently and reveals repeated patterns; it should not be used for ordinary confidential data.

3. AES: The Modern Block-Cipher Standard

The Advanced Encryption Standard is specified in FIPS 197. AES has a block size of 128 bits and supports key sizes of 128, 192, and 256 bits. The key size affects the number of rounds:

AES represents a 128-bit block as a 4 × 4 array of bytes called the state. Each round combines substitution, permutation, and key-dependent operations. AES-128 includes an initial AddRoundKey operation, followed by nine full rounds and a final round. The final round omits MixColumns.

The principal transformations are:

• SubBytes: replaces each byte using a nonlinear substitution box (S-box), helping resist linear and differential cryptanalysis.
• ShiftRows: cyclically shifts rows of the state, spreading bytes across columns.
• MixColumns: combines bytes within each column to provide diffusion.
• AddRoundKey: XORs the state with a round key derived from the original key.

The key schedule expands the original key into round keys. AES is designed to resist known practical cryptanalytic attacks when correctly implemented and used with a secure mode. AES-256 is not automatically “twice as secure” as AES-128; both provide very strong security against conventional brute force, while AES-256 offers a larger key space and a margin against certain future developments.

AES is not a password-hashing algorithm. Passwords should not be used directly as AES keys. A password-derived key should be produced using a password-based key-derivation function such as Argon2id, scrypt, or PBKDF2, with a unique salt and appropriate work factor.

4. Modes of Operation

A mode of operation adapts a block cipher to messages longer than one block and defines how blocks, nonces, and authentication are handled.

ECB: Electronic Codebook

ECB encrypts each plaintext block independently:

Identical plaintext blocks produce identical ciphertext blocks under the same key. Thus, structure and patterns remain visible. ECB may be acceptable for specialized, independently random blocks in narrowly defined protocols, but it is inappropriate for general files, images, documents, or network messages.

CBC: Cipher Block Chaining

CBC combines each plaintext block with the preceding ciphertext block. For the first block, an initialization vector is used:

Decryption is:

The IV should be unpredictable and must not be reused with the same key in contexts requiring semantic security. CBC provides confidentiality only. It requires padding when the plaintext length is not a multiple of the block size, and unauthenticated CBC is vulnerable to ciphertext manipulation and padding-oracle attacks.

CTR: Counter mode

CTR turns a block cipher into a stream-like construction. It encrypts successive counter inputs and XORs the resulting keystream with plaintext:

Here, N is a nonce or unique initial value, counter_i is a distinct counter value, and || denotes concatenation. The nonce-counter input must never repeat under the same key. CTR does not require padding, but it provides no integrity by itself. Bit changes in ciphertext produce corresponding changes in plaintext after decryption.

GCM: Galois/Counter Mode

GCM combines counter-mode encryption with authentication. It produces ciphertext and an authentication tag. It can also authenticate unencrypted associated data, such as a protocol version, record number, or message header.

GCM requires a unique nonce for every encryption under a given key. Nonce reuse is a serious failure: it can reveal relationships between plaintexts and may compromise authentication. Many implementations use a 96-bit nonce, but the precise requirements of the implementation and standard must be followed. A random nonce can be suitable when collision risk is controlled; a counter or carefully managed sequence is often easier to guarantee.

ChaCha20-Poly1305

ChaCha20-Poly1305 is an authenticated-encryption construction using the ChaCha20 stream cipher and Poly1305 authenticator. It is widely used in TLS, virtual private networks, and mobile or software environments. It is often attractive where software performance is important or hardware AES acceleration is unavailable. As with GCM, nonce uniqueness is mandatory.

5. Initialization Vectors, Nonces, and Related Values

An initialization vector (IV) is an input that ensures that encrypting the same plaintext does not necessarily produce the same ciphertext. A nonce is a “number used once.” The terms overlap in practice, but their required properties depend on the construction.

An IV or nonce normally travels with the ciphertext because it need not be secret. A common record format is:

version || algorithm identifier || nonce/IV || ciphertext || authentication tag

The exact format should be specified and parsed unambiguously. A nonce does not replace a key, and a random IV does not make an insecure mode secure.

6. Padding

A block cipher processes complete blocks. If a message is not an exact multiple of the block size, padding adds structured bytes before encryption. PKCS#7-style padding for a block size of B bytes adds r bytes, where:

L is the plaintext length in bytes. If L is already a multiple of B, a complete block of padding is added, so that padding can be unambiguously removed. Every added byte has the value r. For example, with a 16-byte block size and a 13-byte message, three bytes with value 03 are appended.

Padding must be checked strictly during decryption. An error message, timing difference, or other observable distinction between valid and invalid padding can create a padding oracle. An attacker may then manipulate ciphertext and gradually infer plaintext. The strongest general remedy is authenticated encryption, in which the tag is verified before decryption results are accepted.

Modes such as CTR, GCM, and ChaCha20-Poly1305 operate on arbitrary-length byte strings and do not require block padding. Padding may still be used for traffic-analysis resistance in specialized protocols, but that is a separate design decision.

7. Authenticated Encryption

Authenticated encryption with associated data (AEAD) provides confidentiality and integrity together. It encrypts plaintext while producing an authentication tag, and it authenticates additional data that remains visible.

Conceptually:

(ciphertext, tag) = Encrypt(key, nonce, plaintext, associated_data)
plaintext = Decrypt(key, nonce, ciphertext, associated_data, tag)

Decryption must fail if the key, nonce, ciphertext, tag, or associated data is incorrect. Applications must not release or process unauthenticated plaintext. This is sometimes called “decrypt then verify” misuse when plaintext is acted upon before verification. Correct implementations verify the tag before treating the message as valid.

AEAD protects against accidental and malicious modification, but it does not automatically prevent replay. Protocols should include sequence numbers, timestamps, counters, or application-level freshness controls in authenticated data and enforce them.

A secure design should:

1. use a standard AEAD construction such as AES-GCM or ChaCha20-Poly1305;
2. guarantee nonce uniqueness under each key;
3. use a sufficiently large and verified authentication tag;
4. authenticate relevant headers and context as associated data;
5. rotate keys according to protocol and operational requirements;
6. fail safely without revealing whether a key, nonce, or plaintext detail was wrong.

8. Common Failures and Obsolete Algorithms

Frequent implementation failures include:

• using ECB for structured data;
• reusing a nonce with GCM or ChaCha20-Poly1305;
• using a predictable or repeated IV where unpredictability is required;
• encrypting without authentication;
• accepting unauthenticated plaintext before tag verification;
• deriving keys directly from passwords;
• storing keys in source code or public configuration;
• using a constant or hard-coded key;
• inventing a proprietary encryption algorithm;
• exposing detailed decryption errors;
• truncating authentication tags without careful risk analysis;
• failing to bind ciphertext to its intended user, record, or protocol context.

DES is obsolete because its effective 56-bit key is vulnerable to exhaustive search. Triple DES (3DES) has a larger effective security margin than DES but is slow, has a 64-bit block size, and has been deprecated or disallowed in many modern applications. RC4 is obsolete because of serious statistical weaknesses and keystream biases. SSLv3 and older TLS configurations are not suitable modern protections. AES in ECB mode is not equivalent to secure AES-based encryption.

The security of an algorithm also depends on implementation. Side-channel attacks can exploit timing, cache behavior, power consumption, or electromagnetic emissions. Libraries should use constant-time primitives where appropriate and should be maintained, tested, and configured according to current standards.

9. Practical Selection Guidance

For new application data encryption, prefer a well-supported AEAD construction. AES-GCM is an appropriate choice when reliable AES acceleration and nonce management are available. ChaCha20-Poly1305 is a strong alternative, particularly in software-focused or mobile environments. Use a library’s high-level authenticated-encryption interface rather than assembling encryption and authentication manually.

For disk or database encryption, confidentiality requirements differ from network-record encryption. Full-disk encryption protects data when a device is powered off, but it may not protect data after a user has logged in or malware has access to the running system. Database field encryption requires careful decisions about searchable fields, deterministic encryption, access control, backups, and key separation.

For password storage, do not encrypt passwords for later recovery. Store password verifiers produced by a password-hashing or password-based key-derivation function with a unique salt. Symmetric encryption is appropriate when an authorized service must recover the original secret, such as an API credential stored in a secrets manager.

Keys should be generated using a cryptographically secure random-number generator, stored in a key-management system or hardware security module where justified, restricted by role, rotated according to risk, and backed up securely. Key destruction should be considered: encrypted data may become inaccessible if the only key is lost.

10. Illustrative Case: Protecting API Records in a Cloud Service

Background. A small health-technology service stores appointment records in a cloud database. The development team proposes AES-256-CBC with a fixed IV and a key stored in the application source code.

Problem. The proposal has several weaknesses. A fixed IV can reveal relationships between records, CBC does not authenticate modifications, and a source-code key may be exposed through repositories, logs, or deployment artifacts. Health information also requires strong access control, auditing, retention, and breach-response procedures.

Analysis. The data requires confidentiality and integrity. Records may be copied, reordered, or altered by an attacker who gains database access. Therefore, confidentiality-only encryption is insufficient. The service also needs key separation between environments, controlled access, and protection of backups.

Approach. The team replaces the design with an established AEAD library using AES-GCM or ChaCha20-Poly1305. Each record receives a unique nonce generated by a tested nonce-management component. The record identifier, tenant identifier, schema version, and purpose are included as associated data where appropriate. The ciphertext, nonce, tag, and version are stored together, while keys are held by a managed key-management service. Access is audited, key permissions are minimized, and failed authentication is handled without exposing detailed information.

Outcome. Database readers without key-management permission cannot produce valid modified records. The design provides confidentiality and tamper detection, although it still requires secure application hosts, identity management, backups, monitoring, and replay controls.

Learning points. Choosing AES is only one part of secure encryption. Mode, nonce management, key storage, authentication, operational controls, and recovery planning are equally important.

11. Governance, Ethics, and Contemporary Practice

Encryption supports privacy, safety, intellectual property protection, and compliance obligations. Organizations should document what is encrypted, which keys protect it, who can access keys, how long data is retained, and how incidents are handled. Encryption should not be presented as a substitute for lawful access control, secure coding, monitoring, or data minimization.

Security teams must balance confidentiality with availability and recoverability. Lost keys can permanently destroy access to legitimate records; uncontrolled key escrow can undermine confidentiality. Governance should therefore define separation of duties, approval processes, audit trails, rotation, backup, revocation, and emergency recovery.

Contemporary systems increasingly use envelope encryption: a data-encryption key encrypts the data, and a key-encryption key protects the data-encryption key. This limits the amount of data directly handled by a long-term master key and supports controlled rotation. Hardware acceleration, hardware security modules, and cloud key-management services can improve performance and administration, but they do not remove the need for sound protocol design.

Future cryptographic transitions may require replacing algorithms or key-establishment mechanisms threatened by quantum computing. Symmetric algorithms are generally affected less dramatically than public-key systems, but organizations should maintain algorithm agility and avoid formats that permanently prevent migration.

Chapter Summary

Symmetric encryption uses a shared secret key and is the principal method for efficiently protecting bulk data. Stream ciphers generate a keystream and require strict nonce discipline; block ciphers process fixed-size blocks and require a secure mode of operation. AES is a modern, widely standardized block cipher with a 128-bit block size and 128-, 192-, and 256-bit keys.

Modes determine how AES handles messages. ECB reveals patterns and should generally be avoided. CBC requires careful IV and padding management and does not authenticate data. CTR avoids padding but must never reuse its nonce-counter input. AEAD constructions such as AES-GCM and ChaCha20-Poly1305 provide confidentiality and integrity, provided nonce uniqueness and tag verification are correctly implemented.

IVs and nonces are usually not secret, but their required properties are construction-dependent. Padding must be unambiguous and must not create padding oracles. DES, RC4, and many legacy configurations are obsolete. Secure practice requires standard libraries, strong random keys, protected key-management systems, authenticated encryption, careful error handling, and operational governance.

Key Terms

Symmetric encryption: Encryption and decryption using a shared secret key.

Plaintext: Readable or original data before encryption.

Ciphertext: Transformed data produced by encryption.

Key: Secret value controlling a cryptographic operation.

Stream cipher: Cipher that encrypts sequential bits or bytes using a keystream.

Block cipher: Cipher that transforms fixed-size blocks of data.

AES: Advanced Encryption Standard, a standardized 128-bit-block cipher.

Mode of operation: Method for applying a block cipher to messages and data streams.

ECB: A mode encrypting blocks independently; generally unsuitable for structured data.

CBC: Cipher Block Chaining mode, which combines each block with the previous ciphertext block.

CTR: Counter mode, which converts a block cipher into a stream-like construction.

IV: Initialization vector used to initialize certain encryption modes.

Nonce: A value intended to be used once, especially important in AEAD systems.

Padding: Extra structured data added to complete a block.

AEAD: Authenticated encryption with associated data.

Authentication tag: Value used to detect unauthorized modification.

Associated data: Unencrypted data authenticated together with ciphertext.

Key derivation: Process of producing cryptographic keys from passwords or other secret material.

Key management: Generation, storage, use, rotation, recovery, and destruction of keys.

Nonce reuse: Repeating a nonce with the same key, a potentially catastrophic error.

Review Questions

Short Answer Questions

1. What is the primary difference between a stream cipher and a block cipher?
2. Why is ECB generally unsuitable for encrypting images or documents?
3. What is the purpose of an initialization vector or nonce?
4. Why does AES-CBC require padding for many messages?
5. What additional security property does AEAD provide beyond confidentiality?

Long Answer Questions

1. Explain the structure and main transformations of AES, including the role of the S-box, diffusion, and round keys.
2. Compare CBC, CTR, GCM, and ChaCha20-Poly1305 with respect to padding, nonce requirements, confidentiality, and integrity.
3. Explain how nonce reuse can compromise stream ciphers and AEAD constructions.
4. Describe a secure key-management lifecycle for a cloud application.
5. Explain how padding-oracle attacks arise and why authenticated encryption helps prevent them.

Analytical / Application Questions

1. A team encrypts every database record with AES-CBC using the same key and fixed IV, but adds no authentication. Identify the weaknesses and propose a replacement design.
2. A messaging service uses ChaCha20-Poly1305 and accidentally repeats a nonce for two messages. Analyze the likely security consequences and recommend operational controls.
3. Design a secure format for an encrypted API record. Specify which fields should be encrypted, which may be associated data, what metadata must accompany the ciphertext, and how keys should be protected.

Multiple Choice Questions with Answers

Question 1

Which statement best describes symmetric encryption?

A. It uses a shared secret key for encryption and decryption

B. It always uses two unrelated public keys

C. It provides authentication without any additional mechanism

D. It is used only for password storage

Correct Answer: A. It uses a shared secret key for encryption and decryption

Question 2

What is the AES block size?

A. 64 bits

B. 96 bits

C. 128 bits

D. 256 bits

Correct Answer: C. 128 bits

Question 3

Why is ECB generally unsuitable for structured data?

A. It requires a public key

B. It reveals repeated plaintext-block patterns

C. It cannot encrypt any complete block

D. It automatically authenticates ciphertext

Correct Answer: B. It reveals repeated plaintext-block patterns

Question 4

What is the most important nonce requirement for AES-GCM?

A. The nonce must always be secret

B. The nonce must be unique for each encryption under a key

C. The nonce must equal the encryption key

D. The nonce must contain only printable characters

Correct Answer: B. The nonce must be unique for each encryption under a key

Question 5

Which construction provides confidentiality and integrity together?

A. AES-ECB

B. AES-CBC without a tag

C. AES-GCM

D. Plain hashing

Correct Answer: C. AES-GCM

Question 6

What is the purpose of padding in a conventional block mode such as CBC?

A. To make the key public

B. To authenticate the sender

C. To complete a final fixed-size block

D. To eliminate the need for an IV

Correct Answer: C. To complete a final fixed-size block

Question 7

Which algorithm is considered obsolete because of its small effective key size?

A. AES-128

B. ChaCha20

C. DES

D. AES-256

Correct Answer: C. DES

Question 8

What can happen if two stream-cipher messages reuse the same keystream?

A. The ciphertexts reveal the XOR of the plaintexts

B. Both messages become longer automatically

C. The key becomes public immediately in every case

D. Padding is added to both messages

Correct Answer: A. The ciphertexts reveal the XOR of the plaintexts

Question 9

Which value normally does not need to be secret?

A. The encryption key

B. The password-derived secret

C. The authentication key

D. The nonce or IV

Correct Answer: D. The nonce or IV

Question 10

What should an application do before using decrypted AEAD plaintext?

A. Ignore the authentication tag

B. Verify the authentication tag successfully

C. Convert the plaintext to a public key

D. Reuse the nonce for the next message

Correct Answer: B. Verify the authentication tag successfully