2 Symmetric Encryption and Authenticated Encryption

How symmetric encryption works

Symmetric encryption uses the same secret key to encrypt and decrypt data. Both sender and receiver need access to that key, and they must protect it from others.

A widely used block cipher is AES. It transforms fixed-size blocks under a key, while a mode of operation specifies how to apply the cipher to messages of varying length. Using a secure cipher does not by itself make every mode secure.

Confidentiality and traditional modes

The goal of encryption is confidentiality: someone without the key should not be able to learn the plaintext. Basic encryption modes generally do not establish that a message is unchanged or that it came from someone holding the key. Those protections require authenticated encryption or, for a non-authenticated mode, a separate authentication mechanism.

NIST SP 800-38A defines five traditional modes for confidentiality: ECB, CBC, CFB, OFB, and CTR. They differ in how they handle blocks, initialization values, and message sequences.

ECB, CBC, CTR, CFB, and OFB

ECB encrypts each block independently. Under the same key, identical plaintext blocks produce identical ciphertext blocks, revealing patterns. ECB is generally unsuitable for encrypting ordinary messages or files.

CBC combines each plaintext block with the preceding ciphertext block before encryption. It requires an initialization vector (IV) and typically padding. CBC provides confidentiality only, not authentication. A legacy system using CBC needs a separate, correctly designed authentication mechanism.

CTR encrypts successive counter values to produce a keystream, then combines that stream with the plaintext. It does not require padding and supports parallel processing. Counter inputs must never repeat under the same key. CTR alone, like CBC, does not authenticate data.

CFB and OFB turn a block cipher into stream-like modes. They can be useful in specific legacy or protocol contexts, but neither provides authentication by itself.

Authenticated encryption and associated data

Authenticated encryption with associated data (AEAD) combines encryption with an authentication check. It protects plaintext confidentiality and detects attempts to alter ciphertext. It can also authenticate associated data (AAD), which is information that must remain visible but must not be changed, such as a protocol version, record number, or message header.

Common AEAD choices include AES-GCM and AES-CCM. A typical operation takes a secret key, a nonce, plaintext, and optional AAD as inputs, and produces ciphertext and an authentication tag. AAD is authenticated, not encrypted.

During decryption, verify the tag before accepting or acting on the plaintext. If verification fails, reject the message; do not treat its contents as trustworthy.

What authentication establishes

AEAD authentication indicates that data has not been modified without detection and was produced by someone with the key. With a shared key, it does not identify which key holder created the data. It also does not provide public-key nonrepudiation.

Nonce and IV management

A nonce is a value used once within the relevant key context. An IV is a related initialization value, but its precise requirements depend on the mode. A nonce or IV usually does not need to be secret; it must be generated and managed according to the algorithm’s rules.

For common AEAD constructions, including GCM, the same nonce must not be reused with the same key. Reuse can severely undermine security, including confidentiality and authentication. A common GCM nonce length is 96 bits. Follow the cryptographic library’s documented requirements and recommended nonce-generation strategy.

Track nonce use across every device or process sharing a key, not just within one local call sequence.

Safe implementation practices

Prefer a well-reviewed cryptographic library’s AEAD interface rather than assembling encryption and authentication yourself. Use a fresh, correctly generated key, and never reuse a nonce with that key when the algorithm requires unique nonces.

Authenticate relevant visible metadata as AAD, and reject any decryption result whose tag does not verify. If compatibility requires a non-AEAD mode, pair it with a sound authentication construction rather than relying on encryption alone.