Authenticated encryption
Authenticated encryption (AE) and authenticated encryption with associated data (AEAD) are forms of encryption which simultaneously assure the confidentiality and authenticity of data.

Security guarantees 
In addition to protecting message integrity and confidentiality, authenticated encryption can provide security against chosen ciphertext attack.  In these attacks, an adversary attempts to gain an advantage against a cryptosystem (e.g., information about the secret decryption key) by submitting carefully chosen ciphertexts to some "decryption oracle" and analyzing the decrypted results.  Authenticated encryption schemes can recognize improperly-constructed ciphertexts and refuse to decrypt them.  This, in turn, prevents the attacker from requesting the decryption of any ciphertext unless it was generated correctly using the encryption algorithm, thus implying that the plaintext is already known. Implemented correctly, authenticated encryption removes the usefulness of the decryption oracle, by preventing an attacker from gaining useful information that the attacker does not already possess.

Many specialized authenticated encryption modes have been developed for use with symmetric block ciphers.  However, authenticated encryption can be generically constructed by combining an encryption scheme and a message authentication code (MAC), provided that:

 The encryption scheme is semantically secure under a chosen plaintext attack.
 The MAC function is unforgeable under a chosen message attack.

Programming interface 
A typical programming interface for an AE implementation provides the following functions:

 Encryption
 Input: plaintext, key, and optionally a header in plaintext that will not be encrypted, but will be covered by authenticity protection.
 Output: ciphertext and authentication tag (message authentication code).
 Decryption
 Input: ciphertext, key, authentication tag, and optionally a header (if used during the encryption).
 Output: plaintext, or an error if the authentication tag does not match the supplied ciphertext or header.

The header part is intended to provide authenticity and integrity protection for networking or storage metadata for which confidentiality is unnecessary, but authenticity is desired.

History 
The need for authenticated encryption emerged from the observation that securely combining separate confidentiality and authentication block cipher operation modes could be error prone and difficult. This was confirmed by a number of practical attacks introduced into production protocols and applications by incorrect implementation, or lack of authentication (including SSL/TLS).

Around the year 2000, a number of efforts evolved around the notion of standardizing modes that ensured correct implementation. In particular, strong interest in possibly secure modes was sparked by the publication of Charanjit Jutla's integrity-aware CBC and integrity-aware parallelizable, IAPM, modes in 2000 (see OCB and chronology).
Six different authenticated encryption modes (namely offset codebook mode 2.0, OCB2.0; Key Wrap; counter with CBC-MAC, CCM; encrypt then authenticate then translate, EAX; encrypt-then-MAC, EtM; and Galois/counter mode, GCM) have been standardized in ISO/IEC 19772:2009. More authenticated encryption methods were developed in response to NIST solicitation. Sponge functions can be used in duplex mode to provide authenticated encryption.

Bellare and Namprempre (2000) analyzed three compositions of encryption and MAC primitives, and demonstrated that encrypting a message and subsequently applying a MAC to the ciphertext (the Encrypt-then-MAC approach) implies security against an adaptive chosen ciphertext attack, provided that both functions meet minimum required properties. Katz and Yung investigated the notion under the name "unforgeable encryption" and proved it implies security against chosen ciphertext attacks.

In 2013, the CAESAR competition was announced to encourage design of authenticated encryption modes.

In 2015, ChaCha20-Poly1305 is added as an alternative AE construction to GCM in IETF protocols.

Authenticated encryption with associated data (AEAD) 

AEAD is a variant of AE that allows a recipient to check the integrity of both the encrypted and unencrypted information in a message. AEAD binds associated data (AD) to the ciphertext and to the context where it is supposed to appear so that attempts to "cut-and-paste" a valid ciphertext into a different context are detected and rejected.

It is required, for example, by network packets or frames where the header needs visibility, the payload needs confidentiality, and both need integrity and authenticity.

Approaches to authenticated encryption

Encrypt-then-MAC (EtM) 

The plaintext is first encrypted, then a MAC is produced based on the resulting ciphertext. The ciphertext and its MAC are sent together. Used in, e.g., IPsec. The standard method according to ISO/IEC 19772:2009. This is the only method which can reach the highest definition of security in AE, but this can only be achieved when the MAC used is "strongly unforgeable". In November 2014, TLS and DTLS extension for EtM has been published as . Various EtM ciphersuites exist for SSHv2 as well (e.g., ).

Note that key separation is mandatory (distinct keys must be used for encryption and for the keyed hash), otherwise it is potentially insecure depending on the specific encryption method and hash function used.

Encrypt-and-MAC (E&M) 

A MAC is produced based on the plaintext, and the plaintext is encrypted without the MAC. The plaintext's MAC and the ciphertext are sent together. Used in, e.g., SSH. Even though the E&M approach has not been proved to be strongly unforgeable in itself, it is possible to apply some minor modifications to SSH to make it strongly unforgeable despite the approach.

MAC-then-Encrypt (MtE) 

A MAC is produced based on the plaintext, then the plaintext and MAC are together encrypted to produce a ciphertext based on both. The ciphertext (containing an encrypted MAC) is sent. Used in, e.g., SSL/TLS. Even though the MtE approach has not been proven to be strongly unforgeable in itself, the SSL/TLS implementation has been proven to be strongly unforgeable by Krawczyk who showed that SSL/TLS was, in fact, secure because of the encoding used alongside the MtE mechanism. Despite the theoretical security, deeper analysis of SSL/TLS modeled the protection as MAC-then-pad-then-encrypt, i.e. the plaintext is first padded to the block size of the encryption function. Padding errors often result in the detectable errors on the recipient's side, which in turn lead to padding oracle attacks, such as Lucky Thirteen.

See also
 Block cipher mode of operation
 CCM mode
 CWC mode
 OCB mode
 EAX mode
 GCM
 GCM-SIV
 ChaCha20-Poly1305
 SGCM
 Signcryption

References

General

External links
 NIST: Modes Development
 How to choose an Authenticated Encryption mode

Symmetric-key cryptography
Message authentication codes