Symmetric Cryptography, Hashing and Message Authentication

Introduction and Context

Symmetric cryptography uses the same secret key, or closely related secret keys, for protecting and recovering information. It is the principal mechanism for high-volume confidentiality because it is substantially faster than public-key cryptography. Hash functions and message-authentication codes complement encryption: encryption addresses confidentiality, whereas authentication mechanisms address integrity, authenticity, and—in some designs—replay resistance.

Modern security engineering rarely treats these mechanisms independently. A secure protocol must select an appropriate primitive, manage keys safely, authenticate data, generate unpredictable nonces and keys, resist implementation attacks, and define failure behaviour. This chapter therefore considers cryptographic algorithms as components of a larger system rather than as isolated mathematical objects.

Learning Objectives

After studying this chapter, a student should be able to:

1. Distinguish block ciphers, stream ciphers, hashes, MACs, and authenticated-encryption schemes.
2. Explain AES structure, security properties, and key sizes.
3. Select and evaluate modes of operation, including authenticated modes.
4. Describe cryptographic hash security properties and practical uses.
5. Compare MACs, HMAC, password hashing, and key-derivation functions.
6. Explain secure random-number generation and nonce management.
7. Analyse common cryptanalytic and implementation failures.
8. Apply these principles to the design and review of a secure application.

1. Symmetric Cryptography as a Security Service

A symmetric encryption scheme consists of an encryption algorithm E_K(M) = C and a decryption algorithm D_K(C) = M, where M is plaintext, C is ciphertext, and K is a secret key. Correctness requires D_K(E_K(M)) = M for valid keys and inputs. Confidentiality is not guaranteed merely because decryption is possible: a modern scheme should withstand practical attempts to infer plaintext without the key.

Security depends on key secrecy, algorithm design, correct mode selection, nonce or initialization-vector (IV) handling, and implementation quality. The algorithm may be public; secrecy should reside in the key. This is the principle behind open cryptographic evaluation and Kerckhoffs’s principle.

Block and Stream Ciphers

A block cipher maps fixed-length blocks to blocks of equal length under a key. AES processes 128-bit blocks and supports 128-, 192-, and 256-bit keys. Since real messages are usually longer than one block, a mode of operation specifies how blocks are chained, randomized, authenticated, or transformed into a stream.

A stream cipher generates a keystream and combines it with plaintext, commonly using exclusive OR:

Here P_i is a plaintext unit, C_i is the corresponding ciphertext unit, and Z_i is a keystream unit. Decryption uses the same operation: P_i = C_i ⊕ Z_i. The keystream must never be reused with the same key and nonce. If two plaintexts use the same keystream, then C₁ ⊕ C₂ = P₁ ⊕ P₂, exposing relationships between the plaintexts.

Block ciphers are general-purpose primitives; stream ciphers can be efficient for continuous data and environments where padding is undesirable. Neither provides integrity by itself. Encryption-only designs are therefore inadequate for most network protocols.

2. AES: Design and Operation

The Advanced Encryption Standard (AES) is a substitution–permutation network standardized as FIPS 197. Its block size is always 128 bits. The supported key sizes and number of rounds are:

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

• SubBytes: each byte is replaced through a nonlinear substitution box (S-box).
• ShiftRows: rows are cyclically shifted by different offsets.
• MixColumns: bytes in each column are linearly mixed over a finite field.
• AddRoundKey: the state is XORed with a round key derived from the master key.

The final round omits MixColumns. The S-box supplies nonlinearity, while the linear transformations spread local changes across the state. This supports confusion and diffusion: a small input or key change should affect many output bits.

AES-256 does not have a 256-bit block; it has a 256-bit key and a 128-bit block. Larger keys increase resistance to exhaustive key search, but security also depends on mode, implementation, and the amount of data encrypted under a key. AES hardware acceleration, such as AES-NI, can improve performance and reduce some timing risks, but it does not correct unsafe protocol design.

Security Boundaries and Limits

A key of n bits has a nominal exhaustive-search space of 2ⁿ keys. An ideal brute-force attack therefore has an expected work factor of approximately 2^n-1 trials, assuming each trial is equally likely and verification is available. This is a theoretical estimate, not a complete security assessment. Weak passwords, leaked keys, poor random numbers, side channels, and nonce reuse can reduce security far more than the nominal key length suggests.

3. Modes of Operation

Electronic Codebook (ECB)

ECB encrypts each block independently. Equal plaintext blocks produce equal ciphertext blocks under the same key, revealing structural patterns. ECB is unsuitable for general messages and images, although it may be used internally for limited, carefully analysed block transformations.

CBC

Cipher Block Chaining encrypts each plaintext block after XORing it with the previous ciphertext block:

For the first block, C_0 is an unpredictable, non-repeating IV. CBC requires padding when the plaintext length is not a multiple of the block size. It provides confidentiality only. If padding errors are exposed through distinguishable responses, a padding-oracle attack may recover plaintext. CBC should not be selected for new application protocols unless encryption and authentication are designed together with great care.

CTR

Counter mode turns a block cipher into a stream-like construction:

N is a nonce, ctr_i is a unique counter value, and || denotes concatenation. Counter inputs must never repeat for the same key. CTR supports parallel processing and does not require padding, but it provides no integrity and is vulnerable to deliberate ciphertext modification.

GCM and Authenticated Encryption

Galois/Counter Mode (GCM) combines counter-mode encryption with a polynomial authentication calculation. It is an authenticated-encryption with associated data (AEAD) mode. It protects plaintext and authenticates additional authenticated data (AAD), such as protocol headers that must remain visible but must not be altered.

An AEAD interface can be represented as:

and

K is the secret key, N the nonce, P the plaintext, A the associated data, C the ciphertext, and T the authentication tag. Decryption must return plaintext only after tag verification succeeds. A failure must not expose unauthenticated plaintext to application logic.

GCM commonly uses a 96-bit nonce, but the decisive rule is uniqueness under a key. Nonce reuse can catastrophically compromise confidentiality and authentication. Random nonces require collision analysis and reliable randomness; counters or protocol-managed sequence numbers often provide stronger uniqueness guarantees. Implementations must also respect the chosen library’s limits on message length, tag length, and total invocations per key.

ChaCha20-Poly1305 is another widely deployed AEAD construction. ChaCha20 is a stream cipher and Poly1305 is a one-time authenticator used in the combined construction. It is valuable on systems without dedicated AES hardware and, when correctly implemented, can offer resistance to certain classes of timing leakage.

Mode Selection Principles

For new designs, use a standardized AEAD construction such as AES-GCM, AES-GCM-SIV where misuse resistance is required and supported, or ChaCha20-Poly1305. Avoid designing a new mode, combining encryption with a separately invented MAC, truncating tags without analysis, or accepting unauthenticated plaintext. “Encrypt then authenticate” can be secure when precisely specified, but AEAD is generally easier to use safely.

4. Cryptographic Hash Functions

A cryptographic hash function maps an arbitrary-length input to a fixed-length digest:

A secure hash is deterministic and efficient, but its important properties are security properties:

• Preimage resistance: given h, it should be computationally infeasible to find M such that H(M) = h.
• Second-preimage resistance: given M₁, it should be infeasible to find M₂ ≠ M₁ with H(M₂) = H(M₁).
• Collision resistance: it should be infeasible to find any distinct pair M₁ and M₂ with equal hashes.
• Avalanche behaviour: a small input change should produce an apparently unrelated digest.

For an ideal n-bit hash, generic collision search requires approximately 2^n/2 evaluations because of the birthday effect, whereas generic preimage search requires approximately 2ⁿ. Thus SHA-256 offers approximately 128-bit generic collision security and 256-bit generic preimage security, subject to the absence of better attacks.

SHA-2 and SHA-3 are approved modern hash families. MD5 and SHA-1 should not be used for collision-sensitive security applications. A hash is not an encryption function: it is not reversible, does not use a secret key, and does not authenticate a message against an active attacker.

Applications include file integrity identifiers, digital-signature preprocessing, content addressing, transcript binding, commitment constructions, and the internal design of MACs and key-derivation functions. A plain hash of a password is not an acceptable password-storage scheme because passwords have low entropy and attackers can perform massive offline guessing.

5. Message Authentication Codes and HMAC

A MAC is a keyed algorithm that produces an authentication tag:

A verifier possessing K recomputes or verifies T. A secure MAC provides computational integrity and source authentication to parties sharing the key. It does not provide non-repudiation, because either party holding the key could have generated the tag.

HMAC uses a cryptographic hash with an inner and outer keyed construction:

K′ is K normalized to the hash’s block size; ipad and opad are fixed, distinct padding constants; || denotes concatenation. HMAC is specified for hash functions with an appropriate block structure and remains widely used in protocols and key derivation.

MAC verification should be constant-time with respect to the compared tag, and the expected tag length should be validated. A MAC key must be separate from encryption keys unless a construction explicitly defines safe key separation. The verifier should avoid error messages that reveal whether a key, message format, or tag failed.

6. Key Derivation and Password Protection

A key-derivation function (KDF) derives one or more keys from keying material. A secure KDF supports domain separation, context binding, and, where appropriate, salt and work-factor parameters. HKDF is a common extract-and-expand design:

IKM is input keying material, PRK is a pseudorandom key, info identifies the purpose or context, and L is the requested output length. Salt need not always be secret, but it should normally be independent and application-specific.

Password storage requires a deliberately expensive, memory-hard password-hashing function such as Argon2id, or an appropriately configured scrypt or bcrypt implementation. Each password receives a unique random salt. The stored record normally includes the algorithm identifier, parameters, salt, and resulting verifier. During login, the server recomputes the verifier and compares it safely.

A simplified password-verification model is:

The parameters must be selected through benchmarking on production-like systems. They should make legitimate authentication tolerable while increasing the cost of mass offline guessing. A server-side pepper can add protection if stored separately, for example in a hardware security module, but it does not replace salts or a memory-hard function.

Passwords should not be encrypted for storage when the system needs only to verify them. Encryption is appropriate when the original secret must later be recovered, but then key protection becomes critical.

7. Randomness, Nonces, and Key Lifecycle

Cryptographic systems require unpredictable keys, salts, IVs where randomness is required, and tokens. Operating-system cryptographic random-number generators (CSPRNGs) should be used. Application-level pseudorandom functions, timestamps, process identifiers, or predictable counters are not substitutes for a CSPRNG when unpredictability is required.

A secure random generator is normally seeded from an operating-system entropy source and maintains internal state that prevents practical prediction. A random value’s security depends on both its length and the generator’s unpredictability. A 128-bit random token has a large nominal space, but poor generation can reduce effective security to that of a predictable timestamp.

Nonce requirements differ by construction:

Key lifecycle includes generation, distribution, activation, rotation, backup, revocation, destruction, and audit. Rotation does not repair a compromised key unless old ciphertext and future use are handled deliberately. Key separation should assign distinct derived keys to encryption, authentication, export, and different protocol directions.

8. Cryptanalysis and Secure Implementation

Cryptanalysis examines weaknesses in algorithms, constructions, protocols, and implementations. Relevant attack categories include:

• Brute force: systematic key search.
• Differential and linear cryptanalysis: statistical analysis of how input differences or linear approximations propagate; modern ciphers are designed to resist these attacks.
• Related-key attacks: analysis under structured relationships between keys.
• Meet-in-the-middle attacks: reducing work against multiple-stage constructions.
• Collision attacks: finding two inputs with the same hash.
• Padding and format oracles: exploiting distinguishable decryption errors.
• Replay attacks: reusing valid ciphertext and tags in a new context.
• Side-channel attacks: extracting information from timing, cache behaviour, power, electromagnetic emissions, or faults.

Secure implementation requires authenticated decryption, constant-time operations where secrets influence control flow or memory access, safe memory handling, strict input limits, secure error handling, dependency updates, and independent testing. Secrets should not appear in logs, crash reports, URLs, or analytics. Key material should be cleared when practical, although compiler optimizations and managed runtimes complicate guaranteed erasure.

Tag comparison must be performed in constant time. A conceptual comparison of two equal-length byte strings a and b can accumulate differences:

where ∨ is bitwise OR and n is the tag length. The tag is accepted only when r = 0. Production systems should use a vetted constant-time library routine rather than implementing this casually.

Security also depends on protocol state. An application should bind ciphertext to its intended context through AAD, version identifiers, user or channel identifiers, and sequence numbers where appropriate. It should reject duplicate or out-of-order messages when the protocol requires freshness.

9. Illustrative Case: Protecting an Internal File-Exchange Service

Background

A university research service allows laboratories to exchange reports and datasets. Its first version encrypted files with AES-CBC, stored passwords as SHA-256 digests, used a timestamp as an IV seed, and returned separate errors for invalid padding and invalid file metadata.

Problem

The design had four major weaknesses. CBC encryption did not authenticate files; timestamp-derived IVs could repeat or be predictable; fast password hashing enabled offline guessing; and distinguishable errors created an oracle. An attacker who obtained ciphertexts could modify them, probe the service, and attempt password recovery.

Analysis

The security objective required confidentiality, integrity, authenticated users, replay control, and operational recoverability. File names, laboratory identifiers, and protocol versions also needed protection from modification even when not encrypted in the file body.

Approach and Solution

The redesigned service used an approved AEAD library with AES-GCM or ChaCha20-Poly1305, selected according to platform support. Each record contained a version, algorithm identifier, key identifier, nonce, ciphertext, and tag. The version, file identifier, sender identifier, and sequence number were supplied as AAD. Nonces were generated through a protocol-managed counter that never repeated under a key; keys were rotated before defined usage limits were reached.

Passwords were stored using Argon2id with a unique random salt and benchmarked memory and time parameters. Account recovery used separately generated, expiring tokens from the CSPRNG. Encryption keys were held by a key-management service, while application instances received only the permissions required for their role. Decryption returned data only after successful tag verification, and all failure paths exposed a generic external error while recording carefully controlled internal audit events.

Outcome

The redesign removed unauthenticated decryption, made tampering detectable, raised the cost of password guessing, prevented nonce reuse by construction, and improved auditability. It also clarified the distinction between confidentiality, integrity, authentication, and authorization.

Learning Points

1. A strong cipher cannot compensate for a weak mode or unsafe nonce policy.
2. Password hashing and encryption solve different problems.
3. Metadata and protocol context should be authenticated, not merely assumed trustworthy.
4. Security controls must be enforceable through interfaces and key-management policy, not only developer guidance.
5. Failure handling is part of the cryptographic design.

10. Governance, Ethics, and Contemporary Practice

Cryptographic deployment must satisfy organizational policy, data-protection obligations, audit requirements, and sometimes national controls on cryptographic products. Governance should define approved algorithms, minimum key sizes, cryptoperiods, ownership, incident response, and evidence of secure configuration. Personal data should be protected according to its sensitivity and retention period.

Ethically, cryptography protects privacy, safety, intellectual property, and democratic participation. At the same time, poor key custody can obstruct legitimate investigations or expose users through preventable breaches. Security professionals should avoid backdoors and undocumented exceptional access: such mechanisms enlarge the attack surface and weaken assurance for all users. Lawful access, where required, should be addressed through transparent governance and narrowly scoped operational processes rather than deliberate cryptographic weakness.

Contemporary practice increasingly emphasizes misuse-resistant APIs, formally analysed protocols, memory-safe implementation languages, hardware-backed keys, confidential-computing support, and cryptographic agility. Post-quantum transition planning is relevant because some public-key systems face major quantum threats; symmetric primitives are affected differently. Grover’s algorithm gives a theoretical quadratic speedup for exhaustive search, so longer symmetric keys may be selected for long-term protection, but practical risk assessment remains necessary. Hash and MAC choices should be documented so that systems can migrate without ambiguous data formats.

Best-Practice Checklist

• Prefer AEAD rather than encryption without authentication.
• Use AES-GCM, ChaCha20-Poly1305, or another reviewed construction through a vetted library.
• Never reuse a nonce with a key where the mode forbids reuse.
• Use SHA-256, SHA-3, or another currently approved hash; do not use MD5 or SHA-1 for new security purposes.
• Store passwords with Argon2id, scrypt, or bcrypt and unique salts.
• Generate secrets with the operating-system CSPRNG.
• Separate keys by purpose and protocol direction.
• Verify tags before releasing plaintext.
• Use constant-time comparisons and reduce side-channel leakage.
• Authenticate relevant metadata and context as AAD.
• Specify limits, rotation, revocation, backup, and destruction procedures.
• Test error paths, replay handling, boundary conditions, and dependency updates.

Chapter Summary

Symmetric cryptography provides efficient confidentiality, but secure systems require more than selecting AES. Block ciphers need modes of operation; stream-like modes require strict nonce uniqueness; and encryption should normally be combined with authentication through AEAD. AES uses a 128-bit block and supports 128-, 192-, and 256-bit keys, while GCM and ChaCha20-Poly1305 provide practical authenticated encryption.

Cryptographic hashes provide fixed-length digests and support integrity-related constructions, but they are neither encryption nor authentication. Collision, preimage, and second-preimage resistance are distinct properties. MACs authenticate messages for parties sharing a secret, and HMAC is a robust keyed-hash construction. HKDF derives context-specific keys, whereas password-hashing functions such as Argon2id deliberately increase the cost of guessing.

Secure random generation, nonce discipline, key separation, constant-time verification, safe error handling, and lifecycle governance are essential implementation requirements. Cryptanalysis must consider algorithms, protocols, and side channels. The central professional lesson is that cryptographic assurance emerges from the interaction of sound primitives, correct composition, disciplined key management, and secure operational practice.

Key Terms

Authenticated encryption: Encryption that also provides integrity and authenticity, normally through an authentication tag.

Associated authenticated data (AAD): Unencrypted data that is nevertheless authenticated by an AEAD scheme.

AES: A standardized symmetric block cipher with a 128-bit block and three supported key sizes.

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

Collision resistance: The difficulty of finding two distinct inputs with the same hash output.

CSPRNG: A cryptographically secure pseudorandom number generator.

Hash function: A deterministic function mapping arbitrary-length input to a fixed-length digest.

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

Initialization vector (IV): An input used to randomize or diversify certain encryption modes.

Key derivation function (KDF): A construction that derives cryptographic keys from existing keying material.

MAC: A keyed tag used to detect message modification and authenticate a shared-key sender.

Nonce: A value intended to be used once within a specified cryptographic context.

Password hashing: Deliberately costly processing used to store password verifiers safely.

Preimage resistance: Difficulty of finding an input corresponding to a specified hash output.

Salt: Public, independently generated data that makes derived values unique, especially password hashes.

Side channel: An unintended information channel such as timing, cache use, power, or electromagnetic leakage.

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

Tag: Authentication output used to verify integrity and authenticity.

Key separation: Deriving or assigning distinct keys for distinct purposes.

Review Questions

Short Answer Questions

1. Why is ECB unsuitable for encrypting general structured data?
2. Distinguish a nonce from a password salt.
3. What security property does HMAC provide?
4. Why should a password not normally be stored using a fast hash such as SHA-256 alone?
5. What is the difference between collision resistance and preimage resistance?

Long Answer Questions

1. Explain AES structure, including its state representation, round transformations, key sizes, and round counts.
2. Compare CBC, CTR, and AEAD modes with respect to confidentiality, integrity, IV or nonce requirements, and implementation risk.
3. Explain HMAC and discuss how MAC keys should be managed in a multi-service application.
4. Describe password hashing, salts, peppers, work factors, and the role of memory hardness.
5. Discuss how side channels, error handling, nonce management, and key lifecycle practices affect real-world cryptographic security.

Analytical / Application Questions

1. A service encrypts two messages with AES-CTR using the same key and counter start. Explain what an attacker can compute from the ciphertexts and propose a redesign.
2. Design an AEAD record format for a multi-tenant file service. Identify the encrypted fields, AAD fields, nonce strategy, key-separation plan, replay controls, and failure behaviour.
3. An organization stores passwords with unsalted SHA-256 and reports slow login performance after replacing it with Argon2id. Analyse the security improvement and propose a method for selecting acceptable Argon2id parameters without making the service unusable.

Multiple Choice Questions with Answers

Question 1

Which property is specifically associated with an ideal n-bit hash function's generic collision resistance?

A. Approximately 2^n evaluations

B. Approximately 2^(n/2) evaluations

C. Exactly n evaluations

D. A single evaluation

Correct Answer: B. Approximately 2^(n/2) evaluations

Question 2

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

A. The nonce must always be secret

B. The nonce must be reused to support decryption

C. The nonce must never be reused

D. The nonce must be derived from the password

Correct Answer: C. The nonce must never be reused

Question 3

Which AES statement is correct?

A. AES-256 uses a 256-bit block

B. AES always uses a 64-bit block

C. AES-128 has 12 rounds

D. AES has a 128-bit block and AES-256 has 14 rounds

Correct Answer: D. AES has a 128-bit block and AES-256 has 14 rounds

Question 4

What does authenticated encryption with associated data provide?

A. Confidentiality for plaintext and authentication for plaintext and associated data

B. Only confidentiality for the ciphertext

C. Password recovery without a key

D. Public-key digital signatures

Correct Answer: A. Confidentiality for plaintext and authentication for plaintext and associated data

Question 5

Why are unique salts used in password hashing?

A. To make passwords reversible

B. To ensure identical passwords do not produce identical stored values

C. To replace the password-hashing work factor

D. To make the salt itself confidential

Correct Answer: B. To ensure identical passwords do not produce identical stored values

Question 6

Which construction is a keyed message-authentication mechanism based on a hash function?

A. ECB

B. SHA-256 used without a key

C. HMAC

D. CBC padding

Correct Answer: C. HMAC

Question 7

What is the principal danger of reusing a keystream in a stream cipher?

A. The block size becomes larger

B. The key automatically rotates

C. The cipher becomes a hash function

D. XORing ciphertexts reveals the XOR of the corresponding plaintexts

Correct Answer: D. XORing ciphertexts reveals the XOR of the corresponding plaintexts

Question 8

Which mechanism is most appropriate for storing user passwords?

A. Argon2id with a unique salt

B. AES encryption with a key stored beside the database

C. Plain SHA-256 without a salt

D. Base64 encoding

Correct Answer: A. Argon2id with a unique salt

Question 9

What should an AEAD implementation do when tag verification fails?

A. Return the plaintext and log a warning

B. Return unauthenticated plaintext only to administrators

C. Reject the ciphertext and do not release plaintext

D. Retry with a different key automatically

Correct Answer: C. Reject the ciphertext and do not release plaintext

Question 10

What is the purpose of key separation?

A. To make one key serve every protocol function

B. To assign or derive distinct keys for different purposes

C. To eliminate the need for nonce management

D. To convert a hash into a block cipher

Correct Answer: B. To assign or derive distinct keys for different purposes