3. Symmetric Cryptography and Authenticated Encryption

Introduction and Context

Symmetric cryptography uses a shared secret key for both encryption and decryption. Although public-key cryptography is essential for identity, key exchange, and digital signatures, symmetric cryptography performs most of the high-volume protection of data because it is substantially faster and requires fewer computational resources. Secure web sessions, virtual private networks, disk encryption, database protection, wireless protocols, and backup systems all depend heavily on symmetric algorithms.

Confidentiality alone, however, is not sufficient. An attacker may be unable to read an encrypted message but may still alter, replay, truncate, or reorder it. Modern security engineering therefore treats encryption and integrity as related requirements. Authenticated encryption combines confidentiality, integrity, and authenticity in a single carefully designed construction. This chapter examines block and stream ciphers, the Advanced Encryption Standard (AES), modes of operation, message authentication codes, authenticated-encryption schemes, nonce management, key selection, implementation risks, and relevant cryptanalytic attacks.

Learning Objectives

After studying this chapter, the reader should be able to:

• distinguish block ciphers from stream ciphers and explain their security assumptions;
• describe AES structure, key sizes, and round transformations;
• select and evaluate appropriate modes of operation;
• explain the purpose and operation of message authentication codes;
• distinguish encryption, authentication, and authenticated encryption;
• manage nonces, initialization vectors, keys, and authentication tags safely;
• identify implementation weaknesses and common cryptanalytic attacks; and
• evaluate symmetric-cryptography choices in professional and organizational settings.

The Symmetric-Cryptography Model

A symmetric encryption scheme consists of an encryption algorithm, a decryption algorithm, and a secret key. If plaintext is represented by P, ciphertext by C, and key by K, encryption is written as C = E(K, P), while decryption is P = D(K, C). Correctness requires that D(K, E(K, P)) = P.

This notation describes functionality, not security. A secure scheme must resist an adversary who can observe ciphertexts and, in many realistic models, request encryptions of selected plaintexts. Modern designs are evaluated under notions such as indistinguishability under chosen-plaintext attack (IND-CPA). When authenticity is included, the adversary should also be unable to produce a valid ciphertext and tag for a message that was not legitimately generated. This stronger goal is commonly associated with authenticated encryption security.

The shared-key model creates an operational challenge: communicating parties must obtain the same secret without exposing it. Key establishment is often solved using public-key mechanisms, while symmetric keys are then used for the data session. Consequently, symmetric and asymmetric cryptography are complementary rather than competing technologies.

Block Ciphers and Stream Ciphers

A block cipher transforms fixed-length blocks of plaintext into ciphertext blocks under a secret key. AES operates on 128-bit blocks. A block cipher is not normally used by itself to encrypt arbitrary messages; it is combined with a mode of operation that determines how blocks are processed, how initialization values are used, and whether authentication is provided.

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

C = P XOR S(K, N, counter)

where S is the keystream-generation function. Decryption repeats the XOR operation. Stream encryption does not require padding and can be efficient for continuous data. However, reusing the same keystream for two plaintexts is disastrous, because XORing the ciphertexts cancels the keystream and exposes the XOR of the plaintexts.

Some systems use a dedicated stream cipher, such as ChaCha20. Other systems use a block cipher in a stream-like mode, such as AES in counter mode. In both cases, the central operational rule is that a given key and nonce combination must not generate the same keystream twice.

A block cipher is expected to behave like a pseudorandom permutation: for a fixed key, it maps each block uniquely to another block. Its security depends on the secrecy of the key and the absence of exploitable structural weaknesses. It does not, by itself, hide message length, prevent replay, or detect modification.

AES: Design and Security Parameters

AES is a standardized symmetric block cipher based on the Rijndael design. It has a 128-bit block size and supports 128-, 192-, and 256-bit keys. The number of rounds is 10, 12, and 14 respectively. AES processes its 128-bit block as a 4 × 4 array of bytes called the state.

The principal transformations are:

• SubBytes: each byte is replaced using a nonlinear substitution box (S-box), providing confusion;
• ShiftRows: rows of the state are cyclically shifted, spreading byte relationships;
• MixColumns: bytes within each column are combined through a mathematical transformation, providing diffusion; and
• AddRoundKey: the state is XORed with a round key derived from the original key.

The initial stage applies a round key, followed by repeated transformations. The final round omits MixColumns. AES security does not depend on keeping the algorithm secret; its design is public and security depends on the key.

AES-128 is generally considered adequate for most commercial confidentiality requirements, while AES-256 offers a larger security margin and may be required by policy or high-assurance environments. A longer key does not correct poor nonce management, weak passwords, insecure modes, or implementation leakage. AES-256 can also involve modestly different performance and key-schedule characteristics. Key selection should therefore reflect threat models, standards, interoperability, and lifecycle requirements rather than an assumption that the largest number is always best.

Modes of Operation: From Confidentiality to Integrity

Electronic Codebook Mode

Electronic Codebook (ECB) encrypts each block independently. Identical plaintext blocks under the same key produce identical ciphertext blocks. Consequently, patterns in images, structured records, or repeated messages may remain visible. ECB should not be used for general-purpose data encryption.

Cipher Block Chaining

Cipher Block Chaining (CBC) XORs each plaintext block with the preceding ciphertext block before encryption. The first block uses an initialization vector (IV). With a properly unpredictable and nonrepeating IV, CBC can provide confidentiality. It does not provide integrity. If ciphertext is modified, decryption produces altered plaintext, and carefully crafted modifications can have predictable effects in some positions.

CBC implementations also require correct padding. Padding-oracle vulnerabilities arise when systems reveal, directly or indirectly, whether padding was valid. Timing differences, error messages, or different response behavior can allow an attacker to recover plaintext. Encrypt-then-MAC can protect CBC ciphertext when implemented correctly, but modern systems generally prefer integrated authenticated-encryption modes.

Counter Mode

Counter (CTR) mode encrypts successive counter values and XORs the resulting keystream with plaintext. It supports parallel processing and does not require padding. Its critical requirement is uniqueness of the nonce and counter sequence for every encryption under a key. Reusing a nonce repeats the keystream and can reveal relationships between plaintexts. CTR also provides no integrity.

Galois/Counter Mode

Galois/Counter Mode (GCM) combines counter-mode encryption with a polynomial-based authentication mechanism called GHASH. It provides authenticated encryption with associated data (AEAD). Associated data, such as a protocol version, record identifier, or routing header, is authenticated but not encrypted.

GCM is efficient and widely supported, particularly with hardware acceleration. Nonce uniqueness is essential. The conventional nonce length is 96 bits, for which the construction has a well-defined and efficient processing path. If nonce generation is random, the probability of collision must be considered; if uniqueness is mandatory, a counter or carefully designed allocation scheme is safer. Excessive data encrypted under one key and repeated nonce failures can substantially weaken authentication security.

Counter with CBC-MAC and ChaCha20-Poly1305

Counter with CBC-MAC (CCM) combines counter-mode encryption with CBC-MAC and is used in several constrained and wireless environments. It can provide strong AEAD security but may be less flexible or efficient than GCM in some platforms.

ChaCha20-Poly1305 combines the ChaCha20 stream cipher with the Poly1305 authenticator. It is useful where AES hardware acceleration is unavailable and is widely deployed in contemporary secure protocols. Like GCM, it requires strict nonce uniqueness and authenticates both ciphertext and associated data.

The General AEAD Interface

An AEAD interface can be represented as:

C, T = Encrypt(K, N, P, A)

P = Decrypt(K, N, C, T, A), or failure

Here K is the key, N the nonce, P the plaintext, A the associated data, C the ciphertext, and T the authentication tag. Decryption must verify the tag before releasing plaintext to the application. Treating an invalid tag as an ordinary warning, or exposing unauthenticated plaintext, can create serious vulnerabilities.

Message Authentication Codes

A message authentication code (MAC) is a keyed integrity mechanism. It produces a tag from a message and secret key:

T = MAC(K, M)

A recipient possessing K recomputes the tag and compares it with the received value. A secure MAC provides integrity and source authentication to parties sharing the key, but it does not provide confidentiality. HMAC, commonly constructed from a cryptographic hash function, is a widely used MAC. CMAC uses a block cipher, such as AES, in a standardized MAC construction. Poly1305 is a one-time authenticator normally paired with a stream cipher.

MAC verification must use constant-time comparison where feasible. A byte-by-byte comparison that stops at the first mismatch may disclose information through timing measurements. MAC keys should be distinct from encryption keys unless a rigorously analyzed construction explicitly permits their relationship. Key separation reduces cross-protocol and cross-purpose risks.

There are several ways to combine encryption and authentication. Encrypt-and-MAC authenticates plaintext separately, but can reveal information through the authentication channel and is difficult to design safely. MAC-then-encrypt authenticates first and encrypts the result; historical protocol failures show that error handling and padding can make this approach vulnerable. Encrypt-then-MAC encrypts the plaintext and then authenticates the ciphertext, generally providing a robust composition when carefully implemented. AEAD modes integrate the operations and are preferred for new designs.

Nonces, IVs, Keys, and Tags

A nonce is a value intended to be used once within a defined cryptographic context. It need not always be secret, but it must satisfy the algorithm’s uniqueness or unpredictability requirement. The terms nonce and IV are sometimes used interchangeably, although their required properties differ by construction. Engineers should follow the exact algorithm specification rather than rely on terminology.

Nonce management is an architectural responsibility. A safe design may use a persistent counter, a per-device identifier combined with a local counter, or a centrally allocated sequence. Random nonces can be appropriate when the collision probability is negligible, but random generation must be assessed across restarts, devices, threads, and distributed services. A counter that resets after reboot can repeat values unless its state is persisted or combined with a fresh, unique boot or session component.

Keys require similar lifecycle controls. Secure systems generate keys with a cryptographically secure random-number generator, restrict access, rotate keys according to risk and policy, record key versions, and destroy obsolete material when no longer needed. Password-derived keys require a memory-hard password-based key derivation function and a unique salt; a password should never be used directly as an AES key.

Authentication tags balance security and overhead. Short tags reduce bandwidth but make successful forgery more likely after repeated attempts. Tag truncation should be governed by the protocol’s threat model and standards. Systems must also define maximum messages, maximum plaintext volume, and maximum failed verification attempts per key.

Threats and Cryptanalytic Attacks

A brute-force attack tests possible keys. The effective security of an ideal n-bit key is approximately 2^n operations for exhaustive search, with an average successful search requiring about half that number. Key length must be considered alongside computational developments, quantum-threat assumptions, regulatory requirements, and the quality of key generation.

Cryptanalysis seeks exploitable structure rather than testing every key. Differential cryptanalysis studies how input differences influence output differences; linear cryptanalysis uses approximate linear relationships. Modern AES has withstood extensive public analysis, and practical attacks against properly implemented AES generally target incorrect use, weak keys, leakage, or surrounding protocols rather than the core permutation.

Important implementation and protocol attacks include:

• Nonce-reuse attacks: repeated nonces in CTR, GCM, or ChaCha20-Poly1305 can reveal plaintext relationships and may enable authentication forgery;
• Padding oracles: observable padding-validation behavior can disclose CBC plaintext;
• Replay attacks: valid old ciphertexts may be resent unless sequence numbers, freshness values, or application state are authenticated;
• Chosen-ciphertext attacks: an attacker submits crafted ciphertexts and observes decryption behavior;
• Side-channel attacks: timing, cache behavior, power consumption, electromagnetic emissions, or faults reveal secret-dependent information;
• Randomness failures: predictable keys, IVs, or nonces undermine otherwise strong algorithms; and
• Downgrade and algorithm-confusion attacks: negotiation or parsing weaknesses force use of weaker or unintended cryptographic choices.

Constant-time implementations, hardened libraries, secure hardware where justified, uniform error handling, strict input validation, and authenticated protocol state are central defenses.

Applied Scenario: Protecting Records in a Distributed Service

Background

Consider an illustrative online health-services platform that stores appointment records and transmits them between regional application services. The organization must protect confidentiality while ensuring that records cannot be altered or replayed. Services scale horizontally and may restart during maintenance.

Problem

An initial design used AES-CTR with a randomly generated nonce. A service restart occasionally repeated the random-number-generator state, and the same encryption key was shared across all service instances. The design also authenticated only the record body, not the tenant identifier and record version. An attacker who obtained a valid old message could replay it to another service.

Analysis

CTR provides no integrity, so a modified ciphertext could be accepted as altered plaintext. Nonce repetition could expose XOR relationships between records. Shared keys increased the effect of one compromised service. Omitting tenant and version data from authentication permitted context substitution and replay ambiguity.

Approach

The security team replaced the construction with an approved AEAD scheme, such as AES-GCM or ChaCha20-Poly1305, through a maintained cryptographic library. Each encryption receives a nonce generated by a design that guarantees uniqueness per key, using a service-specific identifier and persistent counter. The tenant identifier, record identifier, protocol version, and sequence number are included as associated data. Keys are separated by environment and service role, stored in a managed key service, versioned, and rotated. Decryption verifies the tag before returning data, while sequence checks reject replays.

The team also defined per-key usage limits, monitored authentication failures, tested restart and failover behavior, and documented key and nonce ownership. Security testing included concurrency tests, fault injection, dependency updates, and review of logs to ensure that plaintext and key material were not exposed.

Outcome

The revised design protects both record contents and protocol context, detects modification, and makes replay an explicit application-level concern rather than assuming encryption prevents it. The most important improvement was not simply changing an algorithm; it was establishing ownership and lifecycle controls for keys, nonces, versions, and verification failures.

Learning Points

The scenario demonstrates that cryptographic security is a system property. A strong primitive can be defeated by nonce reuse, weak separation of contexts, insecure failure handling, or absent replay protection. Distributed systems require particular attention to uniqueness across machines, restarts, backups, and concurrent requests.

Professional and Governance Considerations

Organizations should standardize approved algorithms and modes, prohibit custom cryptographic designs except under expert review, and maintain inventories of keys and cryptographic dependencies. Security architecture should document what is encrypted, what is authenticated, the trust boundaries, nonce ownership, rotation policy, recovery procedures, and consequences of verification failure.

Compliance requirements may specify minimum key sizes, approved modules, logging, retention, or validated implementations. Compliance does not replace engineering judgment: a formally approved algorithm can still be misused. Privacy principles also require data minimization and controlled access; encryption is not a justification for retaining unnecessary sensitive information.

Cryptographic libraries should be patched and obtained from trusted sources. Hardware acceleration can improve performance, but it should not be assumed to eliminate all side channels. Hardware security modules, trusted execution environments, and automated key-management services can reduce exposure, but they introduce availability, configuration, and vendor-dependency considerations.

Current Developments and Best Practices

Current secure-protocol design increasingly favors AEAD, explicit algorithm identifiers, key separation, and automated lifecycle management. High-speed networking and cloud services make hardware acceleration and distributed nonce allocation important engineering topics. Privacy-enhancing systems also combine encryption with access control, tokenization, and selective disclosure rather than treating encryption as a complete data-governance solution.

Post-quantum developments are particularly relevant to long-lived confidentiality. Large-scale quantum computing could weaken widely used public-key mechanisms through Shor’s algorithm; symmetric primitives are affected differently, with Grover’s algorithm providing a theoretical quadratic search advantage. This motivates appropriate security margins and migration planning, but it does not remove the need for correct nonce and key management today.

A practical design review should ask:

1. Is an established AEAD construction used through a reputable library?

2. Is nonce uniqueness guaranteed across devices, processes, restarts, and failover?

3. Are keys generated, stored, rotated, separated, and destroyed appropriately?

4. Are all security-relevant headers and context values authenticated?

5. Are tags verified before plaintext is released?

6. Are replay, downgrade, side-channel, and error-oracle risks addressed?

7. Are usage limits, monitoring, testing, and incident-recovery procedures defined?

Chapter Summary

Symmetric cryptography provides efficient protection for data at rest and in transit, but encryption alone does not guarantee integrity or freshness. Block ciphers such as AES operate on fixed-size blocks and require secure modes of operation; stream ciphers and counter-based modes require strict non-reuse of keystream inputs. ECB exposes patterns, CBC requires careful padding and authentication, and CTR provides confidentiality without integrity. AEAD constructions such as AES-GCM, CCM, and ChaCha20-Poly1305 combine encryption with authentication and can protect associated, unencrypted protocol data.

MACs provide integrity and shared-key authentication but not confidentiality. Secure deployments depend on key generation, separation, rotation, nonce uniqueness, tag verification, constant-time operations, replay controls, and resilient failure handling. Most practical failures arise not from breaking AES mathematically but from misuse, weak randomness, side channels, protocol errors, or poor lifecycle governance. Cryptographic selection must therefore be evaluated as part of a complete system and organizational process.

Key Terms

Authenticated encryption: An encryption method that provides confidentiality and integrity, commonly including authenticated associated data.

Associated data: Information authenticated by an AEAD scheme but transmitted without encryption.

Block cipher: A keyed permutation operating on fixed-size blocks of data.

CBC: A block-cipher mode that chains each plaintext block with the previous ciphertext block.

Ciphertext: The transformed output produced by encryption.

CTR mode: A mode that encrypts counters to create a keystream for XOR with plaintext.

ECB: A mode that independently encrypts each block and may reveal repeated patterns.

GCM: An AEAD mode combining counter-mode encryption with GHASH authentication.

HMAC: A keyed message-authentication construction based on a cryptographic hash function.

Initialization vector: An input used to initialize certain cryptographic modes; required properties depend on the mode.

Key separation: Use of distinct cryptographic keys for different purposes or contexts.

MAC: A keyed tag used to verify message integrity and authenticity between key holders.

Nonce: A value intended for one-time use within a cryptographic context.

Padding oracle: A leakage channel revealing whether decrypted padding is valid.

Plaintext: Data in its original, unencrypted form.

Replay attack: Resubmission of a previously valid message to produce an unauthorized effect.

Side-channel attack: An attack using indirect leakage such as timing, power, cache activity, or emissions.

Stream cipher: A cipher that combines plaintext with a generated pseudorandom keystream.

Tag: An authentication value used to detect modification or forgery.

Review Questions

Short Answer Questions

1. Why does a block cipher require a mode of operation for messages longer than one block?

2. What is the principal security danger of reusing a nonce in CTR mode?

3. How does a MAC differ from encryption?

4. What information can be included as associated data in an AEAD scheme?

5. Why should authentication tags be verified before plaintext is released?

Long Answer Questions

1. Explain AES structure, including its state representation, major transformations, key sizes, and rounds.

2. Compare ECB, CBC, CTR, and GCM with respect to confidentiality, integrity, parallelism, padding, and nonce or IV requirements.

3. Explain the differences among encrypt-and-MAC, MAC-then-encrypt, encrypt-then-MAC, and AEAD.

4. Discuss the key-management and nonce-management requirements of a distributed application.

5. Examine how side channels, padding oracles, weak randomness, and replay attacks affect otherwise strong cryptographic algorithms.

Analytical / Application Questions

1. A service uses AES-GCM with a counter that resets after every reboot. Analyze the vulnerability and propose a safe redesign.

2. A protocol authenticates only an encrypted record body, not its tenant identifier or sequence number. Explain possible attacks and identify the data that should be authenticated.

3. An organization is choosing between AES-GCM and ChaCha20-Poly1305 for mobile devices with inconsistent hardware acceleration. Develop a decision framework addressing performance, implementation support, nonce management, and operational risk.

22. Multiple Choice Questions with Answers

Question 1

Which property is provided by authenticated encryption but not by confidentiality-only CTR mode?

A. Integrity and detection of unauthorized modification

B. Perfect secrecy for every key size

C. Protection against all replay attacks automatically

D. Elimination of the need for key management

Correct Answer: A. Integrity and detection of unauthorized modification

Question 2

Why is ECB unsuitable for general-purpose encryption?

A. It cannot encrypt any binary data

B. It uses a key shorter than AES-128

C. Identical plaintext blocks produce identical ciphertext blocks

D. It always requires a random nonce

Correct Answer: C. Identical plaintext blocks produce identical ciphertext blocks

Question 3

A system encrypts two plaintexts with the same key and nonce in CTR mode. What is the principal consequence?

A. The ciphertexts become independently secure

B. The repeated keystream can expose relationships between plaintexts

C. The key automatically rotates

D. Only the authentication tag is affected

Correct Answer: B. The repeated keystream can expose relationships between plaintexts

Question 4

Which item is authenticated but normally not encrypted as AEAD associated data?

A. The secret encryption key

B. A protocol version or record identifier

C. The authentication tag key schedule

D. The plaintext payload

Correct Answer: B. A protocol version or record identifier

Question 5

What does a MAC primarily provide?

A. Confidentiality without shared secrets

B. Integrity and authentication for parties sharing a key

C. Forward secrecy automatically

D. Compression of the message

Correct Answer: B. Integrity and authentication for parties sharing a key

Question 6

Which AES transformation introduces nonlinear substitution?

A. ShiftRows

B. MixColumns

C. AddRoundKey

D. SubBytes

Correct Answer: D. SubBytes

Question 7

A CBC implementation returns different errors for invalid padding and invalid authentication. What vulnerability may result?

A. A padding oracle

B. A collision-free hash

C. A stronger key schedule

D. Nonce independence

Correct Answer: A. A padding oracle

Question 8

Which design decision best prevents nonce collisions across distributed service instances?

A. Use an unsynchronized counter that resets on reboot

B. Use a unique instance component combined with controlled persistent counters

C. Use the same nonce for all records to simplify debugging

D. Keep nonces secret instead of ensuring uniqueness

Correct Answer: B. Use a unique instance component combined with controlled persistent counters

Question 9

Why is constant-time tag comparison recommended?

A. To increase plaintext length

B. To prevent timing leakage about the location of mismatches

C. To make tags publicly readable

D. To replace authenticated encryption

Correct Answer: B. To prevent timing leakage about the location of mismatches

Question 10

Which statement about AES-256 is most accurate?

A. It eliminates the need for secure nonce management

B. It guarantees protection against implementation attacks

C. It provides a larger key space, but does not correct misuse of the algorithm

D. It is a stream cipher with variable block size

Correct Answer: C. It provides a larger key space, but does not correct misuse of the algorithm