Symmetric-Key Cryptography

Introduction and Context

Symmetric-key cryptography uses the same secret key, or closely related secret keys, to protect and recover information. It is the principal technology for high-volume encryption because it is substantially faster than public-key cryptography. Modern secure systems commonly use public-key methods to establish or transport a symmetric session key, and then use a symmetric authenticated-encryption algorithm to protect the actual data.

The central security requirement is that the key must remain secret. If an attacker obtains the key, confidentiality is lost and, depending on the algorithm, the attacker may also forge or modify protected messages. Symmetric cryptography therefore involves more than selecting an algorithm: key generation, distribution, storage, rotation, initialization values, authentication, error handling, and implementation discipline are equally important.

Learning Objectives

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

• distinguish block ciphers from stream ciphers;
• describe the structure and security goals of AES;
• explain common modes of operation, padding, IVs, and nonces;
• use authenticated encryption appropriately;
• select an algorithm and mode for a practical application;
• identify common implementation errors and propose controls.

1. Symmetric Encryption Fundamentals

A symmetric encryption system consists of a key-generation process, an encryption algorithm, and a decryption algorithm. Let K be a secret key, M a plaintext message, and C a ciphertext. Encryption is represented as:

Decryption must recover the original message:

The equations assume that the correct key, algorithm, parameters, and any required initialization value are available. In a secure design, knowing the algorithm and ciphertext should not allow an attacker to recover M without K. This is the principle of algorithm transparency associated with Kerckhoffs's principle: security should depend on the secrecy of the key, not on hiding the algorithm.

Encryption primarily provides confidentiality. It does not automatically provide integrity, authenticity, replay protection, or secure key management. A ciphertext can be confidential while still being maliciously modified. This is why modern applications normally use authenticated encryption rather than encryption alone.

Terminology

• Plaintext: Original readable or structured data.
• Ciphertext: Data produced by encryption.
• Key: Secret value controlling the cryptographic transformation.
• Key space: Set of all possible keys.
• Nonce: A value intended to be used once with a particular key.
• IV (initialization vector): An input that randomizes or initializes an encryption process; its secrecy requirements depend on the mode.
• Tag: An authentication value used to detect alteration.
• Key stream: Pseudorandom sequence XORed with plaintext in a stream cipher or counter-based mode.

A key with n bits has 2ⁿ possible values. The approximate work required for exhaustive search is 2^n-1 trials when keys are tested in a random order. This is an average-case estimate and assumes that the implementation does not leak information and that the key was selected uniformly. It does not mean that a 128-bit key provides exactly 128 bits of security against every possible attack.

2. Block Ciphers and Stream Ciphers

Block ciphers

A block cipher transforms fixed-size blocks under a secret key. For a block size of b bits, the basic transformation is:

where P_i and C_i are plaintext and ciphertext blocks of exactly b bits. Decryption applies the inverse transformation:

A block cipher is not, by itself, a complete way to encrypt an arbitrarily long message. A mode of operation specifies how blocks are linked and how repeated or partial data is handled. AES has a block size of 128 bits, regardless of whether its key is 128, 192, or 256 bits.

Stream ciphers

A stream cipher generates a pseudorandom key stream and combines it with plaintext, usually using exclusive OR (XOR):

where Z_i is the key-stream segment corresponding to position i. Decryption uses the same operation because XOR is its own inverse:

The key stream must never repeat for two different plaintexts under the same key. If the same stream is used twice, then:

This can reveal relationships between the two plaintexts and may permit recovery of both when messages are predictable. This failure is called key-stream reuse or two-time-pad misuse.

A stream cipher normally does not provide integrity. An attacker may flip selected ciphertext bits and cause corresponding plaintext bits to change. Modern stream-like constructions such as ChaCha20 are therefore commonly used through an authenticated-encryption construction such as ChaCha20-Poly1305.

Comparison

3. AES: The Modern Block-Cipher Standard

The Advanced Encryption Standard (AES), standardized as FIPS 197, is a substitution–permutation block cipher. It operates on 128-bit blocks and supports 128-, 192-, and 256-bit keys. The corresponding numbers of rounds are 10, 12, and 14.

AES represents a 128-bit block as a 4 × 4 array of bytes called the state. Each round, except for the final round, applies four conceptual transformations:

1. SubBytes: Each byte is replaced using a nonlinear substitution table (S-box). This supplies nonlinearity.
2. ShiftRows: Rows of the state are cyclically shifted by different offsets. This spreads relationships across columns.
3. MixColumns: Bytes within each column are combined using arithmetic in the finite field GF(2⁸). This provides diffusion.
4. AddRoundKey: The state is XORed with a round key derived from the original key.

The initial step includes AddRoundKey. The final round omits MixColumns. AES key expansion derives the required round keys. These details explain AES's design, but application developers should use a reviewed library rather than implement AES themselves.

AES has been extensively analyzed and is considered secure when used with appropriate key sizes and modes. AES-128 is generally adequate for ordinary contemporary applications; AES-256 can be selected where longer security margins, policy requirements, or future cryptanalytic concerns justify it. A longer key does not compensate for nonce reuse, poor randomness, exposed keys, or an unauthenticated mode.

AES is a block cipher, not an encryption format for files or network messages. The mode, nonce or IV, authentication method, serialization format, and key-management procedure determine whether an AES-based system is secure.

4. Modes of Operation

Electronic Codebook (ECB)

ECB independently encrypts each block:

Equal plaintext blocks produce equal ciphertext blocks. Consequently, patterns in images, databases, and structured records remain visible. ECB should not be used for general-purpose data encryption. It is useful only in narrow internal constructions where repeated blocks cannot disclose meaningful information.

Cipher Block Chaining (CBC)

CBC XORs each plaintext block with the previous ciphertext block before encryption:

For the first block, an IV serves as C₀. Decryption is:

A CBC IV should be unpredictable and, for a given key, should not be reused. It need not normally be secret, so it can be transmitted with the ciphertext. CBC provides confidentiality only. If used without a secure MAC, it is vulnerable to manipulation, including padding-oracle attacks. If CBC is required for compatibility, use encrypt-then-MAC with a strong independent authentication key, verify the tag before releasing plaintext, and use constant-time and uniform error handling.

Counter mode (CTR)

CTR encrypts successive counter values to produce a key stream:

and then:

Here N is a nonce or unique prefix, counter_i is a distinct counter value, and || denotes concatenation. CTR supports parallel processing and does not require padding. The nonce-counter input must never repeat under the same key. CTR alone provides no integrity.

Galois/Counter Mode (GCM)

GCM combines counter-mode confidentiality with authentication based on GHASH. It produces ciphertext and an authentication tag. It is an authenticated-encryption mode with associated data (AEAD): selected data such as headers can be authenticated without being encrypted.

GCM requires strict nonce uniqueness for each key. A commonly used nonce length is 96 bits. Other lengths are permitted by the standard, but they invoke additional processing and should be handled by a vetted library. A random 96-bit nonce has a small but nonzero collision probability; for large message populations, the birthday effect becomes relevant. Deterministic counters or centrally coordinated allocation can provide stronger uniqueness guarantees.

XTS and specialized modes

XTS-AES is designed mainly for storage-device sectors. It addresses some disk-encryption requirements but does not provide general message authentication. It should not be substituted for an AEAD mode in network protocols or application data formats.

5. Padding, IVs, and Nonces

Padding

Block modes that require complete blocks must represent a final partial block. PKCS#7-style padding for a block size of b bytes appends p bytes, where:

and 1 ≤ p ≤ b. Every padding byte has the value p. If the message length is already a multiple of b, a complete block of padding is added. For example, with a 16-byte block size, a 13-byte message receives three bytes, each equal to hexadecimal 03. A 16-byte message receives sixteen bytes equal to hexadecimal 10.

The receiver must verify every padding byte and reject invalid padding. However, exposing a distinct padding error can create a padding oracle. AEAD modes operate on arbitrary-length plaintext and normally remove the need for application-level padding.

IVs and nonces

The terms IV and nonce are sometimes used loosely, but their security conditions differ by construction:

An IV or nonce generally does not need to be secret. It must be transmitted or reconstructed correctly, and it must be bound to the ciphertext and key context. A common message format is a version, algorithm identifier, nonce, ciphertext, and authentication tag. The nonce should not be encrypted merely to conceal it.

6. Authenticated Encryption

Authenticated encryption with associated data protects confidentiality and integrity together. Given key K, plaintext M, associated data A, and nonce N, an AEAD operation can be expressed as:

Decryption verifies the tag before returning plaintext:

If verification fails, the result must be a failure, not partially decrypted data. Associated data is authenticated but remains visible; it can include a protocol version, record number, sender identifier, or message type. It must be supplied identically during decryption.

Common AEAD choices include AES-GCM, AES-CCM, and ChaCha20-Poly1305. AES-GCM benefits from hardware acceleration on many processors. ChaCha20-Poly1305 is often efficient where AES hardware acceleration is unavailable. The choice should follow platform support, protocol standards, performance requirements, and library quality rather than informal preference.

Authentication tags have a finite length. Shortening a tag increases the probability that a random forgery is accepted. Systems should use library defaults or an approved policy and should limit failed verification attempts where online attacks are possible.

Encrypt-then-MAC and legacy systems

If AEAD is unavailable, a carefully designed encrypt-then-MAC construction is preferable to MAC-then-encrypt or encrypt-and-MAC. Encryption and authentication keys should be independent, ciphertext should be authenticated, and the tag must be verified before decryption output is used. This approach is complex and should normally be replaced with standardized AEAD.

7. Selecting an Algorithm and Design

A practical selection process asks:

1. What property is required? Confidentiality alone is rarely sufficient; most applications require authenticity and integrity.
2. Is the data a message, a disk sector, a database field, or a live stream? Storage-sector requirements differ from network-record requirements.
3. Can the implementation guarantee nonce uniqueness? If not, redesign the key and nonce-management process before selecting GCM or ChaCha20-Poly1305.
4. What standards and libraries are approved? Prefer well-maintained, audited, interoperable libraries.
5. How will keys be generated, stored, rotated, revoked, and destroyed? These controls often dominate practical security.
6. What are the performance and hardware constraints? Consider throughput, latency, memory, parallelism, and hardware acceleration.
7. How will failures be handled? Authentication failure must not disclose whether a guessed field was almost correct.

A typical record format might contain:

version || algorithm_id || key_id || nonce || ciphertext || tag

The key identifier supports rotation, while the version supports future migration. The format should be unambiguous and authenticated, either as associated data or as part of the protected plaintext where appropriate.

8. Common Implementation Errors

Reusing a nonce

Nonce reuse under the same key can reveal relationships between plaintexts in counter-based encryption and can catastrophically undermine GCM authentication. Use a monotonic message counter, a carefully designed random-nonce strategy, or a library that manages nonces safely. Distributed systems require coordination or partitioned counter spaces.

Using ECB

ECB leaks repeated-block patterns. Replacing ECB with CBC without adding authentication is not a complete fix; AEAD is usually the correct solution.

Treating encryption as authentication

An attacker can modify unauthenticated ciphertext. Never assume that encrypted data is trustworthy merely because it cannot be read.

Hard-coded or weak keys

Keys embedded in source code, configuration repositories, mobile applications, or container images can be extracted. Generate keys with a cryptographically secure random generator and protect them with a key-management service, hardware security module, or equivalent control.

Predictable randomness

General-purpose pseudo-random functions are unsuitable for keys, IVs, and nonces. Use an operating-system or library cryptographic random source.

Revealing errors and timing information

Different messages for “bad padding,” “unknown user,” and “invalid tag” can assist attackers. Return appropriately uniform external errors and avoid unnecessary timing differences. Authentication comparisons should be constant-time where the library requires it.

Ignoring key separation and context

The same key should not be reused for unrelated algorithms or purposes. Derive independent subkeys using an approved key-derivation function and bind protocol context, version, and purpose to the derivation or associated data.

Failing to authenticate metadata

An attacker may alter an unprotected algorithm identifier, account number, role, or record version. Authenticate security-relevant metadata and reject unsupported algorithm identifiers safely.

Misusing passwords as keys

Human passwords have insufficient entropy for direct use as encryption keys. Use a password-based key-derivation function such as Argon2id, scrypt, or PBKDF2 with a unique salt and an institutionally approved cost setting. A salt need not be secret, but it must be stored with the derived ciphertext metadata.

9. Worked Example: CTR Nonce Reuse

Suppose two messages are encrypted under the same key and the same nonce. At a particular position, both use the same stream value Z. The ciphertexts are:

XORing them cancels the stream because Z ⊕ Z = 0:

The attacker does not immediately obtain both plaintexts, but the result exposes their relationship. If one plaintext is guessed or partly known, the corresponding portion of the other can be recovered. In GCM, nonce reuse can additionally enable authentication forgeries. Thus, “the nonce is public” does not mean “the nonce may be reused.” Publicity and uniqueness are separate requirements.

10. Applied Case: Protecting Customer Records

This is an illustrative case.

Background

A retail company stores customer contact details in a cloud database and transmits updates between regional services. An initial design uses AES-256-CBC with a fixed IV and stores the key in application source code.

Problem

The fixed IV reveals equality and patterns at the beginning of records. The database API exposes different errors for invalid padding and malformed records. There is no authentication tag, and anyone with repository access can obtain the encryption key.

Analysis

The design has failures in confidentiality, integrity, key management, and error handling. Increasing the AES key size would not correct any of these weaknesses. The system also has no rotation strategy or way to identify which key encrypted a record.

Approach and solution

The company migrates to an approved AEAD library using AES-GCM or ChaCha20-Poly1305. Each record receives a unique nonce, a version, and a key identifier. The record identifier and schema version are included as associated data. Keys are generated by a cryptographically secure service and stored in a key-management system. Access is controlled by service identity, keys are rotated according to policy, and old keys are retained only as long as needed for controlled decryption and migration.

The database stores the version, key identifier, nonce, ciphertext, and tag. Decryption returns data only after successful tag verification. All authentication failures produce a consistent external error and are logged without exposing plaintext or key material. A migration process reads legacy records, verifies them under controlled conditions, encrypts them with the new format, and records migration status.

Outcome

The revised system provides confidentiality and tamper detection, supports controlled rotation, and removes the fixed-IV and repository-key risks. It still requires operational monitoring, backup protection, access review, and secure deletion of obsolete keys.

Learning points

Cryptographic strength is a system property. A strong primitive cannot rescue a reused nonce, exposed key, unauthenticated format, or unsafe error channel. Design reviews must therefore examine the complete data lifecycle.

11. Limitations, Governance, and Contemporary Practice

Symmetric encryption does not solve identity management, authorization, endpoint compromise, traffic analysis, metadata exposure, or data deletion from backups. Encryption can also create governance obligations: organizations must document key ownership, access authority, retention, incident response, recovery procedures, and legal requirements for protected personal or financial data.

Standards-based implementations should follow current guidance from relevant national and sector authorities. Deprecated algorithms such as DES and commonly misused constructions such as unauthenticated RC4 should not be selected for new systems. Cryptographic agility is valuable, but allowing an attacker to negotiate a weak algorithm is not; supported algorithms must be constrained by policy and authenticated negotiation.

Hardware acceleration, secure enclaves, and managed key services can improve performance or key protection, but they do not eliminate configuration risk. Automated code generation and AI-assisted programming may help produce integration code, yet generated cryptographic code requires expert review, dependency analysis, test vectors, misuse testing, and verification of nonce and key-management logic. Developers should call established primitives rather than ask an AI system to invent cryptography.

Best-Practice Checklist

• Prefer AEAD, normally AES-GCM or ChaCha20-Poly1305, for application messages.
• Use cryptographically secure key generation and protected key storage.
• Guarantee nonce uniqueness for every key; document how this is achieved.
• Treat IVs and nonces as protocol fields, not optional decorations.
• Authenticate headers, versions, identifiers, and other security-relevant metadata.
• Never use ECB for ordinary data encryption.
• Avoid custom cryptographic algorithms and custom modes.
• Verify tags before using decrypted data.
• Separate keys by purpose and support rotation and revocation.
• Test failure paths, malformed inputs, replay behavior, and boundary lengths.
• Maintain an inventory of algorithms, key owners, dependencies, and migration plans.

Chapter Summary

Symmetric-key cryptography efficiently protects data using secret keys. Block ciphers operate on fixed-size blocks and require modes of operation for longer messages; stream ciphers and stream modes generate a key stream that must never be reused. AES is a standardized 128-bit-block cipher with 128-, 192-, and 256-bit keys, but AES alone is not a complete data-protection protocol. ECB leaks patterns, CBC requires careful IV and padding handling and separate authentication, and CTR requires a never-repeated nonce-counter input. AEAD modes such as AES-GCM and ChaCha20-Poly1305 combine confidentiality with integrity and support authenticated, visible metadata. Secure implementation depends on key generation and storage, nonce management, tag verification, error handling, key separation, algorithm selection, governance, and migration planning.

Key Terms

Symmetric-key cryptography: Cryptography using a shared secret key for encryption and decryption.

Plaintext: Original data before encryption.

Ciphertext: Data produced by encryption.

Block cipher: A cipher that transforms fixed-size blocks.

Stream cipher: A cipher that combines plaintext with a generated key stream.

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

Mode of operation: A method for applying a block cipher to messages longer than one block.

ECB: A mode that independently encrypts blocks and exposes repeated patterns.

CBC: A chaining mode in which each plaintext block is combined with the previous ciphertext block.

CTR: A counter mode that encrypts counter inputs to create a key stream.

AEAD: Authenticated encryption with associated data.

Authentication tag: Value used to detect modification and forgery.

IV: Initialization vector used to initialize or randomize a construction.

Nonce: Value intended for one-time use with a particular key.

Padding: Extra data added to complete a required block length.

Key rotation: Controlled replacement of an encryption key.

Key separation: Use of independent keys for different purposes.

Padding oracle: An information leak caused by distinguishable padding-validation behavior.

Key-stream reuse: Reusing the same stream with different plaintexts, compromising security.

Associated data: Visible data authenticated by an AEAD operation.

Review Questions

Short Answer Questions

1. What is the difference between a block cipher and a stream cipher?
2. Why does AES require a mode of operation for most application messages?
3. State the principal nonce requirement for AES-GCM.
4. What security property does an authentication tag provide?
5. Why is ECB unsuitable for ordinary record or image encryption?

Long Answer Questions

1. Explain AES's main round transformations and the role of substitution and diffusion.
2. Compare CBC, CTR, and GCM in terms of confidentiality, integrity, IV or nonce requirements, and padding.
3. Explain how PKCS#7-style padding works, including the case where the message already fills a complete block.
4. Describe a secure key-management lifecycle for an organization using symmetric encryption.
5. Discuss how implementation errors can undermine a mathematically strong cipher.

Analytical / Application Questions

1. A service encrypts two records with AES-GCM under one key and accidentally repeats a nonce. Analyze the risks and recommend corrective actions.
2. Design a protected database-record format containing a version, key identifier, record identifier, nonce, ciphertext, and tag. Explain which fields should be authenticated and why.
3. A legacy system uses AES-CBC with a random IV but no MAC and returns separate errors for invalid padding and invalid records. Identify the vulnerabilities and propose a migration plan.

Multiple Choice Questions with Answers

Question 1

Which statement best describes AES?

A. A stream cipher with a variable block size

B. A 128-bit-block cipher supporting 128-, 192-, and 256-bit keys

C. A hashing algorithm with no secret key

D. A public-key algorithm for digital signatures

Correct Answer: B. A 128-bit-block cipher supporting 128-, 192-, and 256-bit keys

Question 2

What is the most important requirement for a GCM nonce under one key?

A. It must be kept confidential

B. It must contain only alphabetic characters

C. It must never be reused

D. It must always be exactly 16 bytes

Correct Answer: C. It must never be reused

Question 3

Which mode directly exposes repeated plaintext-block patterns?

A. ECB

B. GCM

C. CTR

D. ChaCha20-Poly1305

Correct Answer: A. ECB

Question 4

What does AEAD provide in addition to confidentiality?

A. Guaranteed key recovery

B. Integrity and authentication, including for associated data

C. Automatic user authorization

D. Compression of plaintext

Correct Answer: B. Integrity and authentication, including for associated data

Question 5

In CTR mode, what can happen if the same key-stream input is reused for two messages?

A. The block size automatically increases

B. The plaintexts become independently authenticated

C. XORing ciphertexts reveals the XOR of the plaintexts

D. The key is automatically rotated

Correct Answer: C. XORing ciphertexts reveals the XOR of the plaintexts

Question 6

For a 16-byte block size, how many padding bytes are added to a 13-byte message using PKCS#7-style padding?

A. 1

B. 3

C. 13

D. 16

Correct Answer: B. 3

Question 7

Which statement about a typical CBC IV is correct?

A. It must normally be secret and permanently fixed

B. It should be unpredictable and fresh, but may generally be transmitted

C. It can safely be reused with every message

D. It replaces the encryption key

Correct Answer: B. It should be unpredictable and fresh, but may generally be transmitted

Question 8

What should an AEAD decryption routine do when tag verification fails?

A. Return the unauthenticated plaintext

B. Retry with ECB mode

C. Return failure and not release the plaintext

D. Ignore the tag if the ciphertext has the expected length

Correct Answer: C. Return failure and not release the plaintext

Question 9

Which is the best general choice for protecting ordinary application messages?

A. AES-ECB without a tag

B. AES-CBC with a fixed IV

C. A standardized AEAD construction from a vetted library

D. A custom cipher designed by the application team

Correct Answer: C. A standardized AEAD construction from a vetted library

Question 10

Why should encryption keys not normally be hard-coded in application source code?

A. Source code cannot contain hexadecimal values

B. Hard-coded keys can be extracted and are difficult to rotate securely

C. Hard-coded keys make AES operate as a hash

D. Keys must always be publicly available

Correct Answer: B. Hard-coded keys can be extracted and are difficult to rotate securely