Symmetric Cryptography and Secure Communication

Introduction

Symmetric cryptography protects information by using the same secret key, or closely related secret material, for encryption and decryption. It is the principal mechanism used to protect high-volume data in applications such as blockchain wallets, payment systems, virtual private networks, cloud storage, messaging platforms, and database encryption.

Symmetric cryptography is fast and comparatively efficient, but its security depends critically on key management, correct parameter selection, secure randomness, authenticated encryption, and careful implementation. A mathematically strong cipher can become insecure when a nonce is reused, a weak mode is selected, ciphertext is modified without detection, or decryption errors are handled incorrectly.

In blockchain systems, symmetric cryptography is commonly used to protect wallet files, backup phrases stored in encrypted containers, private data exchanged between nodes, and application-level information. It is important to distinguish this role from the role of public-key cryptography. Public-key systems help establish identity and exchange keys, whereas symmetric systems usually protect the actual data stream because they are much faster.

Learning Objectives

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

• explain the purpose and operation of symmetric encryption;
• distinguish block ciphers from stream ciphers;
• describe common modes of operation and identify weak modes;
• explain initialization vectors, nonces, salts, and authentication tags;
• compare MAC-then-encrypt, encrypt-then-MAC, and authenticated encryption;
• identify the dangers of nonce reuse and predictable randomness;
• apply practical rules for selecting and implementing secure symmetric encryption;
• analyse a realistic failure involving encryption without authentication.

1. Foundations of Symmetric Encryption

A symmetric encryption system consists of a plaintext message, a secret key, an encryption algorithm, and a decryption algorithm. Encryption transforms readable plaintext into ciphertext. Decryption reverses this transformation only for a party possessing the correct key.

Conceptually, encryption can be represented as:

where P is plaintext, K is the secret key, C is ciphertext, and Enc_K is the encryption algorithm parameterised by K. Decryption is:

The equations describe the intended relationship, not a recommendation to design a new cipher. For a correct implementation, decryption of a valid ciphertext produced under the same key and required parameters must recover the original plaintext.

A secure symmetric scheme should provide confidentiality: an attacker should not learn the plaintext from ciphertext. Modern systems should also provide integrity and authenticity: an attacker should not be able to alter the ciphertext undetected, and the recipient should be able to determine whether the ciphertext was produced using the appropriate secret key.

Kerckhoffs’s Principle

A cryptosystem should remain secure even when its algorithms are public. The secret should be the key, not a hidden algorithm. This principle supports peer review, standardisation, interoperability, and timely discovery of weaknesses. Proprietary or obscure algorithms are not automatically secure.

Security Goals

The main goals relevant to symmetric communication are:

Encryption alone normally addresses only confidentiality. It does not automatically provide integrity, authenticity, or replay protection.

2. Keys, Entropy, Salts, and Nonces

Keys and Entropy

A key must be generated from a cryptographically secure random number generator or derived using a secure key-derivation function. Human-chosen passwords are not keys: they often have insufficient entropy and may be guessed using dictionaries, leaked password databases, or specialised hardware.

Key length is expressed in bits. The nominal brute-force search space for a uniformly random n-bit key contains 2ⁿ possibilities. This relationship assumes that keys are uniformly random and that no attack substantially reduces the search effort. It does not mean that doubling a cipher’s key length always doubles every security property.

Salts

A salt is a non-secret, independently generated value used mainly in password-based key derivation. It ensures that the same password does not produce the same derived key across records and prevents effective reuse of precomputed tables. A salt is normally stored with the ciphertext or password record. A salt is not a replacement for a key and does not need to be confidential.

Initialization Vectors and Nonces

An initialization vector (IV) or nonce is an additional input used by many encryption modes. A nonce is intended to be used once with a particular key; the word is derived from “number used once.” An IV may have a mode-specific requirement such as unpredictability, uniqueness, or both. These terms are sometimes used interchangeably in practice, but their security requirements must be taken from the specification of the chosen algorithm and mode.

A nonce is not normally secret. Its purpose is to prevent repeated encryption under identical internal conditions. It is usually transmitted alongside the ciphertext, but it must never be reused when the selected construction forbids reuse.

3. Block Ciphers

A block cipher is a keyed permutation that processes fixed-size blocks. For a block size of b bits, encryption maps each b-bit plaintext block to a b-bit ciphertext block under a key. A block cipher by itself does not specify how messages longer than one block are handled. That responsibility belongs to a mode of operation.

AES is the most widely deployed modern block cipher. AES has a 128-bit block size and supports 128-, 192-, and 256-bit keys. AES-128, AES-192, and AES-256 differ in key length and internal rounds, but all use the same 128-bit block size. AES is not the same thing as AES-CBC or AES-GCM: the latter names include a mode of operation.

A block cipher should exhibit confusion and diffusion. Confusion makes the relationship between key and ciphertext complex; diffusion spreads the influence of each plaintext bit across many ciphertext bits. These properties support resistance to statistical and structural attacks, but they do not by themselves guarantee secure application-level use.

Padding

Some block modes require plaintext to be an exact multiple of the block size. Padding adds extra bytes before encryption. A common scheme is PKCS#7-style padding, in which each added byte has a value equal to the number of added bytes. If 3 bytes are required, three bytes with value 0x03 are appended. Even a message already aligned to the block size receives a full padding block, allowing unambiguous removal.

Padding must be validated during decryption. However, exposing different padding errors, timing behaviour, or response messages can create a padding-oracle vulnerability. Authenticated encryption is generally preferable because authentication is checked before plaintext is accepted.

4. Stream Ciphers

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

where P_i is a plaintext bit or byte, S_i is the corresponding keystream value, C_i is ciphertext, and ⊕ denotes XOR. Decryption uses the same operation:

This follows because (P_i ⊕ S_i) ⊕ S_i = P_i, assuming the same keystream is regenerated correctly.

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

The keystream cancels. An attacker may then infer information about both plaintexts, especially when messages have predictable structure. This is the two-time-pad problem.

ChaCha20 is a widely used modern stream cipher. ChaCha20-Poly1305 combines the ChaCha20 cipher with the Poly1305 message authentication code to provide authenticated encryption. AES-GCM is a block-cipher-based authenticated-encryption construction with similar practical goals.

5. Modes of Operation and Their Security Properties

Electronic Codebook (ECB)

ECB encrypts each block independently. Identical plaintext blocks under the same key produce identical ciphertext blocks. Patterns in structured data can therefore remain visible. ECB should not be used for general message or file encryption.

Cipher Block Chaining (CBC)

CBC combines each plaintext block with the previous ciphertext block before block-cipher encryption. The first block uses an IV. In simplified form:

The IV must meet the mode’s requirements and must not be reused in ways that compromise security. CBC provides confidentiality but not authentication. It must therefore be combined with a secure MAC construction, preferably using encrypt-then-MAC, or replaced with an authenticated-encryption mode. Incorrect padding handling and unauthenticated CBC have historically caused serious vulnerabilities.

Counter Mode (CTR)

CTR encrypts a sequence of counter values to generate a keystream, then XORs that keystream with plaintext. The counter block must never repeat under the same key. CTR provides confidentiality but not integrity, so ciphertext modification may be possible without detection.

Galois/Counter Mode (GCM)

GCM combines counter-mode encryption with authentication. It produces ciphertext and an authentication tag. It can also authenticate associated data (AAD), such as a protocol version, message type, or sender identifier, without encrypting that data.

The central operational rule is strict nonce uniqueness for a given key. A common GCM nonce length is 96 bits, but implementations must follow the relevant specification. Random generation alone does not guarantee uniqueness over large numbers of messages; counters or carefully designed allocation systems may be safer.

Authenticated Encryption with Associated Data

AEAD provides confidentiality and integrity for plaintext while authenticating associated data that remains visible. A conceptual interface is:

Here K is the key, N is the nonce, P is plaintext, A is associated data, C is ciphertext, and T is the authentication tag. The operation Open must reject the message if the tag is invalid. The associated data is authenticated but not encrypted.

Common AEAD choices include AES-GCM and ChaCha20-Poly1305. A system should use a well-reviewed library interface rather than implementing these constructions independently.

6. Message Authentication Codes

A message authentication code (MAC) is a keyed integrity mechanism. It allows a verifier possessing the shared key to detect modification and to establish that the message was generated by someone possessing that key. A MAC does not provide confidentiality.

Conceptually:

where M is the message and T is the tag. Verification recomputes the tag and compares it using a constant-time comparison where appropriate. Ordinary string comparison may stop at the first mismatch and can create timing leakage in some contexts.

HMAC is a standard MAC construction based on a cryptographic hash function, such as HMAC-SHA-256. Poly1305 is a one-time or nonce-controlled authenticator commonly paired with ChaCha20. A MAC key must be independent of unrelated encryption keys unless a formally analysed construction specifies otherwise.

Composition Choices

Three historical composition patterns are important:

• Encrypt-then-MAC: encrypt the plaintext, then MAC the ciphertext and relevant context. This is generally the preferred generic composition when correctly specified.
• MAC-then-encrypt: compute a MAC on plaintext and then encrypt both. This can be safe in carefully designed protocols but has caused implementation and error-handling problems.
• Encrypt-and-MAC: encrypt plaintext and send a separate MAC over plaintext. Security depends strongly on the exact design and context.

Modern applications should normally use a standard AEAD construction rather than assembling encryption and authentication manually.

7. Nonce Reuse and Other Implementation Failures

Nonce Reuse

Nonce reuse is among the most damaging symmetric-cryptography errors. In CTR-like encryption, repeating a nonce under the same key repeats the keystream. In GCM, nonce reuse can reveal relationships between plaintexts and can undermine authentication, potentially enabling forged messages depending on the circumstances.

A robust design should define who allocates nonces, how uniqueness is enforced across processes and devices, what happens after a counter restart, and how keys are rotated. Random nonces require adequate randomness and an acceptably low collision probability; deterministic counters require durable state and protection against rollback.

Weak Randomness

Operating-system startup problems, incorrect library calls, predictable seeds, and ordinary pseudo-random generators can produce guessable keys or nonces. Cryptographic randomness must come from a cryptographically secure source provided by the operating system or a vetted hardware-backed service.

Hard-Coded and Reused Keys

Keys embedded in source code, mobile applications, firmware, or public repositories should be treated as compromised. Reusing one key across users or environments increases the impact of a single disclosure and may violate assumptions of the encryption mode.

Incorrect Tag Handling

The recipient must verify the authentication tag before releasing plaintext to application logic. The system should avoid revealing whether failure arose from an invalid tag, malformed padding, or another internal detail. Tags should not be truncated beyond the security level justified by the protocol.

Missing Context Binding

A ciphertext may be valid cryptographically but used in the wrong context. Including protocol version, record identifier, user identifier, or message type as authenticated associated data can prevent cross-protocol and substitution attacks.

Replay Attacks

Integrity does not automatically provide freshness. An attacker may capture a valid authenticated message and send it again. Applications requiring freshness should authenticate sequence numbers, timestamps, unique message identifiers, or state-dependent counters and reject duplicates or stale values.

8. A Secure Communication Workflow

A practical design process is:

1. Define the security goals and threat model.
2. Select a standard AEAD scheme supported by a maintained library.
3. Generate keys with a cryptographically secure source or an approved key-derivation process.
4. Allocate a unique nonce for every encryption under a given key.
5. Authenticate all security-relevant metadata as associated data.
6. Store or transmit the nonce with the ciphertext; secrecy is usually unnecessary.
7. Verify the tag before using decrypted plaintext.
8. Provide replay protection when messages have state-changing effects.
9. Rotate, revoke, and securely delete keys according to a documented lifecycle.
10. Test failure paths, concurrency, process restarts, backups, logging, and version upgrades.

A typical record may contain a version, algorithm identifier, key identifier, nonce, ciphertext, and tag. The format should be unambiguous and should authenticate the fields that influence interpretation.

9. Worked Example: Why Reusing a Stream-Cipher Keystream Fails

Suppose two short messages are encrypted with the same stream-cipher keystream. Let the plaintext bytes be represented symbolically as P₁ and P₂, and the common keystream be S. Then:

XORing the ciphertexts gives:

The secret keystream disappears. The attacker does not immediately obtain either plaintext in every case, but known words, predictable headers, language statistics, and guesses can reveal both messages. The example demonstrates why “different ciphertext” is not sufficient evidence of secure encryption: nonce and key management are part of the cryptographic design.

10. Illustrative Case Study: Blockchain Wallet Backup Service

Background

Consider a fictional blockchain wallet service that allows users to encrypt wallet backups before storing them in cloud storage. The engineering team selects AES-GCM, which is an appropriate general choice. Each backup record contains a nonce, ciphertext, and authentication tag.

Problem

To simplify deployment, the service generates a random 96-bit nonce using a general-purpose pseudo-random function. A virtual machine snapshot restores the process state, including the random-generator state. After restoration, some nonce values are repeated under the same encryption key. In addition, the service authenticates only the encrypted wallet data and not the wallet identifier or record version.

Analysis

The use of AES-GCM is not itself the failure. The failure is operational: nonce uniqueness is not guaranteed. Reuse can compromise confidentiality and authentication. Missing context binding creates a second problem: a valid encrypted record may be copied into a different logical location and still be accepted if the application does not authenticate the record identifier.

Approach and Solution

The service redesigns the format and process as follows:

• keys are generated and stored through a managed key-protection service;
• each key has a documented scope and rotation policy;
• nonces are allocated using a durable per-key counter with collision checks;
• VM restoration cannot roll the counter back without detection;
• the version, wallet identifier, algorithm identifier, and record sequence number are supplied as associated data;
• the library rejects invalid tags before returning plaintext;
• replay and replacement of old records are prevented using sequence numbers;
• tests deliberately simulate crashes, concurrent writers, snapshot restoration, malformed tags, and duplicate records.

Outcome

The revised system preserves confidentiality and integrity under the stated threat model and makes important failures visible. It also improves auditability because key identifiers, algorithm versions, and record counters are explicit rather than hidden in application assumptions.

Learning Points

The case illustrates that secure cryptography is a system property. Algorithm selection, randomness, storage, recovery procedures, metadata, error handling, and operational governance must all satisfy the assumptions of the construction.

11. Professional, Ethical, and Governance Considerations

Cryptographic failures can expose financial assets, identity information, health records, and confidential business data. Professionals should therefore document algorithms, key ownership, retention periods, access permissions, rotation procedures, incident response, and destruction methods.

Security controls should respect privacy and data-minimisation principles. Encryption does not remove legal obligations concerning personal data, breach reporting, access control, or retention. Key escrow and recovery mechanisms may support legitimate business continuity, but they also create high-value targets and must be governed carefully.

Developers should not log plaintext, keys, passwords, authentication tags, or complete ciphertext records when those records could assist an attacker. Debugging output must be reviewed before production deployment. Cryptographic libraries should be patched and selected from reputable, maintained projects.

Artificial intelligence tools may assist with code review, test generation, and documentation, but generated cryptographic code must not be trusted without expert review and test vectors. AI systems may produce plausible but unsafe nonce handling, obsolete algorithms, or incorrect interpretations of library APIs.

12. Contemporary Developments and Best Practice

Current practice increasingly favours AEAD designs such as AES-GCM and ChaCha20-Poly1305, standard container formats, hardware-backed key protection, automated key rotation, and formal or semi-formal protocol analysis. Misuse-resistant schemes are also important because they reduce the consequences of common nonce-management mistakes, although they do not remove the need for sound key management.

Best practice includes:

• prefer standard, reviewed AEAD constructions;
• never invent a cipher, mode, padding rule, or authentication format;
• treat nonce requirements as strict security requirements;
• use separate keys for separate purposes and environments;
• authenticate metadata and protocol context;
• reject invalid tags before releasing plaintext;
• use constant-time verification where the API and threat model require it;
• design for crashes, concurrency, rollback, backup restoration, and key rotation;
• keep cryptographic dependencies current;
• test with published vectors and negative cases;
• document assumptions so that future maintainers do not accidentally violate them.

Chapter Summary

Symmetric cryptography uses shared secret keys to provide efficient protection for data. Block ciphers process fixed-size blocks and require modes of operation for longer messages; stream ciphers generate keystreams that must never be reused with the same key. ECB exposes patterns, while CBC and CTR provide confidentiality without integrity. Modern systems should normally use authenticated encryption, particularly AEAD constructions such as AES-GCM or ChaCha20-Poly1305.

IVs and nonces are public inputs but have strict mode-specific requirements. Nonce reuse can reveal plaintext relationships and, for some authenticated modes, undermine authentication. MACs detect modification but do not encrypt. Secure systems authenticate ciphertext and relevant metadata, verify tags before releasing plaintext, address replay, use secure randomness, and manage keys throughout their lifecycle. Correct implementation and operational governance are as important as the underlying algorithm.

Key Terms

Symmetric cryptography: Cryptography in which communicating parties use shared secret key material.

Plaintext: Original readable data before encryption.

Ciphertext: Transformed data produced by encryption.

Key: Secret value controlling a cryptographic operation.

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

Stream cipher: A cipher that generates a keystream combined with plaintext, commonly using XOR.

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

Initialization vector (IV): An additional mode input whose security requirements depend on the construction.

Nonce: A value intended for one-time use with a particular key and construction.

Salt: A non-secret value used mainly in password-based key derivation.

MAC: A keyed mechanism for detecting message modification and authenticating its origin to key holders.

AEAD: Authenticated encryption with associated data.

Authentication tag: Verification value generated by an authenticated-encryption or MAC construction.

Associated data: Data authenticated but not encrypted.

Padding: Additional data added to meet a block-size requirement.

Keystream: Pseudorandom sequence combined with plaintext in a stream cipher or counter mode.

Nonce reuse: Reusing a nonce with the same key where uniqueness is required.

Replay attack: Re-sending a previously valid message to cause an unwanted repeated action.

Key rotation: Replacing an active cryptographic key according to a defined policy.

Review Questions

5 Short Answer Questions

1. What is the difference between confidentiality and integrity?
2. Why is a salt used in password-based key derivation?
3. Why should ECB generally not be used for file encryption?
4. What does associated data provide in an AEAD scheme?
5. Why must an authentication tag be verified before plaintext is accepted?

5 Long Answer Questions

1. Explain the differences between block ciphers and stream ciphers, including the security consequences of keystream reuse.
2. Compare ECB, CBC, CTR, and GCM with respect to confidentiality, integrity, and operational requirements.
3. Explain the role of keys, IVs, nonces, salts, and authentication tags in a secure encryption system.
4. Discuss encrypt-then-MAC, MAC-then-encrypt, and AEAD, and explain why modern systems generally prefer AEAD.
5. Describe a complete key and nonce-management lifecycle for a blockchain wallet backup service.

3 Analytical / Application Questions

1. A service encrypts messages using CTR mode but sends no MAC. Analyse at least two attacks that may be possible and propose a safer redesign.
2. A distributed application uses AES-GCM with random nonces generated independently by ten servers. Identify the risks and design a nonce-allocation strategy that remains safe after crashes and server restarts.
3. A wallet backup is authenticated but can be copied from one user record to another. Explain how authenticated associated data and replay controls could prevent this substitution attack.

Multiple Choice Questions with Answers

Question 1

Which property does symmetric encryption provide by itself most directly?

A. Confidentiality

B. Non-repudiation

C. Digital identity

D. Replay prevention

Correct Answer: A. Confidentiality

Question 2

Why is ECB unsuitable for general structured data encryption?

A. It cannot use a secret key

B. It reveals repeated plaintext-block patterns

C. It always requires a password

D. It provides authentication but not confidentiality

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

Question 3

What is the principal danger of reusing a nonce with the same key in CTR-like encryption?

A. The key becomes longer

B. The ciphertext becomes compressed

C. The keystream can repeat and reveal plaintext relationships

D. The algorithm automatically changes to ECB

Correct Answer: C. The keystream can repeat and reveal plaintext relationships

Question 4

Which construction provides confidentiality and integrity together?

A. AES-ECB

B. Plain SHA-256

C. AES-CBC without a MAC

D. AES-GCM

Correct Answer: D. AES-GCM

Question 5

What does a MAC primarily provide?

A. Integrity and authentication to parties holding the key

B. Confidentiality against all parties

C. Public verifiability without a secret

D. Automatic replay prevention

Correct Answer: A. Integrity and authentication to parties holding the key

Question 6

Which statement about associated data is correct?

A. It is encrypted but not authenticated

B. It is authenticated but remains unencrypted

C. It must always be secret

D. It replaces the encryption key

Correct Answer: B. It is authenticated but remains unencrypted

Question 7

A stream cipher uses C = P ⊕ S. If the same S is used for two messages, what can be obtained by XORing their ciphertexts?

A. P₁ ⊕ P₂

B. S alone in every case

C. The encryption key directly

D. A guaranteed plaintext for both messages

Correct Answer: A. P₁ ⊕ P₂

Question 8

Which practice best protects against timing leakage during tag verification?

A. Comparing tags as ordinary strings with early exit

B. Ignoring the tag when plaintext looks plausible

C. Using an appropriate constant-time comparison

D. Publishing the expected tag

Correct Answer: C. Using an appropriate constant-time comparison

Question 9

What is the main purpose of a salt in password-based key derivation?

A. To make ciphertext readable

B. To ensure identical passwords do not produce identical derived outputs across records

C. To authenticate network identity

D. To replace a cryptographically random key

Correct Answer: B. To ensure identical passwords do not produce identical derived outputs across records

Question 10

Which statement about encryption and replay protection is correct?

A. Confidentiality automatically prevents replay

B. A valid authentication tag automatically makes every message fresh

C. Replay protection may require sequence numbers, timestamps, or unique identifiers

D. Replay attacks occur only when ECB is used

Correct Answer: C. Replay protection may require sequence numbers, timestamps, or unique identifiers