Authenticated Encryption: An Explainer

Authenticated encryption protects encrypted data in two ways: it keeps the plaintext confidential and lets the recipient detect whether the ciphertext or protected metadata has been altered. Modern applications should generally use a standard authenticated-encryption construction instead of encryption alone.

The common form is authenticated encryption with associated data, or AEAD. AEAD protects the confidentiality and integrity of the plaintext while also authenticating selected metadata that remains visible.

Why encryption alone is not enough

Encryption transforms plaintext into ciphertext using a key. A correctly designed encryption scheme prevents someone without the key from learning the original value.

Confidentiality does not automatically provide integrity. Some confidentiality-only modes allow an attacker to change ciphertext without knowing the key. The altered ciphertext may decrypt to corrupted or attacker-influenced plaintext unless a separate mechanism detects the change.

Consider encrypted transaction instructions. An attacker might not be able to read the account numbers or amount, but a malleable encryption scheme could still allow changes to selected bits. Whether the resulting plaintext is predictable depends on the mode and message format, but the security requirement is straightforward: modified ciphertext must be rejected before the application acts on it.

What authenticated encryption adds

An authenticated-encryption operation produces ciphertext and an authentication tag. During decryption, the recipient recomputes and verifies the tag. If the ciphertext, nonce, associated data, tag, or relevant key material does not match, verification fails and the plaintext must not be released.

This provides three related properties:

• Confidentiality: unauthorized parties cannot read the protected plaintext.
• Integrity: unauthorized modification is detected.
• Data-origin authentication: a valid tag shows that the protected input was created by a party holding the appropriate key, within the limits of the scheme and key-sharing model.

Authenticated encryption does not identify a human user by itself. If many services share the same symmetric key, a valid tag proves possession of that key, not which person or service performed the operation. Identity and authorization controls remain separate requirements.

What is associated data?

AEAD can authenticate metadata without encrypting it. This metadata is called associated data or additional authenticated data.

Examples include a record identifier, protocol version, content type, tenant identifier, timestamp, or message header. The recipient can read this metadata, but any unauthorized change causes tag verification to fail.

Associated data must be reproduced exactly during decryption. Changing its encoding, order, normalization, or representation can cause legitimate verification failures. Applications should define a stable serialization format rather than assembling associated data inconsistently.

How an AEAD operation works

1. The application selects the encryption key and generates or obtains a nonce according to the algorithm’s requirements.
2. The application provides the plaintext and any associated data.
3. The AEAD algorithm returns ciphertext and an authentication tag.
4. The application stores or transmits the nonce, associated data, ciphertext, tag, and a key or version identifier as required by the design.
5. During decryption, the algorithm verifies the tag before releasing plaintext.
6. If verification fails, the application rejects the data without processing partial plaintext or exposing detailed cryptographic errors.

Common authenticated-encryption options

NIST recommends integrated authenticated encryption as the default choice wherever feasible. Approved general-purpose AEAD techniques include GCM and CCM.

• AES-GCM combines counter-mode encryption with a polynomial authentication function. It is widely supported and can perform well in hardware and software. Nonce uniqueness under a given key is critical.
• AES-CCM combines counter-mode encryption with CBC-MAC authentication. It is used in several constrained and wireless environments and also requires correct nonce and message-length handling.
• ChaCha20-Poly1305 combines the ChaCha20 stream cipher with the Poly1305 authenticator. It is standardized by the IETF and is often useful where AES hardware acceleration is unavailable. Poly1305 by itself is an authenticator, not an encryption mode.
• Ascon-AEAD128 is a NIST-standardized option for constrained devices.

The best choice depends on the protocol, platform, validation requirements, available libraries, performance profile, and the application’s ability to manage nonces correctly.

Nonce and authentication-tag rules

Authenticated encryption is safer than composing confidentiality and authentication manually, but parameters still matter.

Nonce uniqueness

A nonce is usually public, but it must follow the uniqueness or unpredictability rules of the selected algorithm. Reusing a nonce with AES-GCM under the same key can reveal relationships between plaintexts and undermine authentication. Libraries can generate or manage nonces, but the overall system must prevent reuse across processes, restarts, replicas, and restored backups.

Tag length

Shortening an authentication tag increases the probability that a forged tag will be accepted. Follow the algorithm, protocol, and library guidance rather than truncating tags solely to save storage or bandwidth.

Fail closed

An authentication failure must stop processing. Do not return partial plaintext, distinguish detailed failure causes to an untrusted caller, or continue with corrupted data. Error behavior should avoid becoming an oracle that reveals information about keys, padding, plaintext, or tag validity.

Encrypt-then-MAC and AEAD are related, but not identical

Legacy systems sometimes combine a confidentiality-only mode such as CBC with a separate message authentication code. Of the common generic composition patterns, Encrypt-then-MAC is the preferred construction because the receiver authenticates the ciphertext before decrypting it.

A standardized AEAD mode should not be described as merely “Encrypt-then-MAC.” GCM, CCM, and other AEAD schemes have their own integrated specifications, security assumptions, and parameter rules. Use the complete construction provided by a maintained library rather than recreating its components.

Authenticated encryption implementation checklist

• Use a maintained cryptographic library and a standardized AEAD construction.
• Generate keys with a cryptographically secure random-number generator.
• Keep keys separate across environments, tenants, purposes, and algorithms where the design requires separation.
• Guarantee nonce uniqueness or unpredictability according to the selected algorithm.
• Use stable serialization for associated data.
• Store the nonce, tag, key identifier, algorithm version, and any required metadata with the ciphertext.
• Verify the authentication tag before releasing or processing plaintext.
• Plan key rotation and cryptographic migration before a compromise or standards change forces an emergency update.
• Apply authorization separately. Successful decryption does not prove the requester should receive cleartext.

The bottom line

Encryption without authentication can leave applications unable to detect malicious changes. For new general-purpose systems, use a standard AEAD construction and treat nonce management, tag verification, key lifecycle, and fail-closed behavior as part of the security boundary.

Authenticated encryption protects the data object. Runtime authorization determines which identity is allowed to receive cleartext or a protected representation. See how Ubiq combines protection methods with identity and policy in Runtime Data Protection.

Sources

• NIST: Authentication for Confidentiality Modes
• NIST SP 800-38D: GCM and GMAC
• NIST SP 800-38C: CCM
• NIST SP 800-232: Ascon-Based Lightweight Cryptography Standards
• OWASP Cryptographic Storage Cheat Sheet