Properties of AEAD Algorithms
Internet-Draft draft-irtf-cfrg-aead-properties-07
Andrey Bozhko, Ed.
CryptoPro
andbogc@gmail.com
2024
General
Crypto Forum
authenticated encryption, mode of operation, AEAD, properties
Authenticated Encryption with Associated Data (AEAD) algorithms provide both confidentiality and integrity of data. The widespread use of AEAD algorithms in various applications has led to an increased demand for AEAD algorithms with additional properties, driving research in the field. This document provides definitions for the most common of those properties, aiming to improve consistency in the terminology used in documentation. This document is a product of the Crypto Forum Research Group.
Introduction
An Authenticated Encryption with Associated Data (AEAD) algorithm provides confidentiality for the plaintext to be encrypted and integrity for the plaintext and some associated data (sometimes called Header). AEAD algorithms play a crucial role in various applications and have emerged as a significant focus in cryptographic research.
Background
AEAD algorithms are formally defined in [RFC5116]. The main benefit of AEAD algorithms is that they simultaneously provide data confidentiality and integrity and have a simple unified interface. In contrast to generic compositions of Message Authentication Code (MAC) and encryption algorithms, an AEAD algorithm allows for a reduction in key and state sizes, improving the data processing speed. Most AEAD algorithms come with security analysis, usage guidelines, and reference implementations. Consequently, their integration into high-level schemes and protocols is highly transparent. For instance, AEAD algorithms are mandatory in TLS 1.3 [RFC8446], IPsec ESP [RFC4303][RFC8221], and QUIC [RFC9000].
While confidentiality and data integrity, being the conventional properties of AEAD algorithms, suffice for many applications, some environments demand other uncommon cryptographic properties. These often require additional analysis and research. As the number of such properties and corresponding research papers grows, inevitable misunderstandings and confusion arise. It is a common situation when related but formally different properties are named identically, or some security properties only have folklore understanding and are not formally defined. Consequently, the risk of misusing AEAD algorithms increases, potentially resulting in security issues.
Scope
In this document, in Section 4, we provide the list of the most common additional properties of AEAD algorithms. The properties are divided into two categories, namely security properties (see Section 4.3) and implementation properties (see Section 4.4).
We provide a high-level definition for each property; for security properties, we also reference an informative source where a formal game-based security notion is defined. When possible, we offer additional information: synonymous names, examples of algorithms that provide the property, applications that might necessitate such property from an AEAD algorithm, references for further reading, and additional notes containing information outside these categories.
The objective of this document is to enhance clarity and establish a common language in the field. In particular, the primary application of the document lies in the following two use cases within the IRTF or the IETF documents development process:
- For an RFC or I-D that defines an AEAD algorithm, it is recommended to use the notations of Section 4 when listing additional properties of the algorithm.
- For an RFC or I-D that defines a generic protocol based on an AEAD algorithm, it is recommended to use the notations of Section 4 if any additional properties are required from the algorithm.
This document represents the consensus of the Crypto Forum Research Group (CFRG). This document is not an IETF product and is not a standard.
Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here.
AEAD Algorithms
This section gives a conventional definition of an AEAD algorithm following [RFC5116].
Definition: An AEAD algorithm is defined by two operations, which are authenticated encryption and authenticated decryption:
- A deterministic operation of authenticated encryption has four inputs, each a binary string: a secret key K of a fixed bit length, a nonce N, associated data A, and a plaintext P. The plaintext contains the data to be encrypted and authenticated, and the associated data contains the data to be authenticated only. Each nonce value MUST be unique in every distinct invocation of the operation for any particular value of the key. The authenticated encryption operation outputs a ciphertext C.
- A deterministic operation of authenticated decryption has four inputs, each a binary string: a secret key K of a fixed bit length, a nonce N, associated data A, and a ciphertext C. The operation verifies the integrity of the ciphertext and associated data and decrypts the ciphertext. It returns a special symbol FAIL if the inputs are not authentic; otherwise, the operation returns a plaintext P.
We note that specifications of AEAD algorithms that use authentication tags to ensure integrity MAY define it as an independent output of the encryption operation and as an independent input of the decryption operation. Throughout this document, by default, we will consider the authentication tag as part of the ciphertext unless stated otherwise.
For more details on the AEAD definition, please refer to [RFC5116].
Throughout this document, by default, we will consider nonce-based AEAD algorithms, which have an interface from the definition above, and give no other restrictions on their structure. However, some properties considered in the document apply only to particular classes of such algorithms, like block cipher-based AEAD algorithms (such algorithms use block cipher as a building block). If that is the case, we explicitly point that out in the corresponding section.
AEAD Properties
Classification of additional AEAD Properties
In this document, we employ a high-level classification of additional properties. This classification aims to provide insight into how one can benefit from each property. The additional properties in this section are categorized into one of these two groups:
- Security properties: We classify a property as a security property if it either takes into account new threats or extends adversarial capabilities, in addition to those posed by the typical nonce-respecting adversary whose goal is to compromise confidentiality or data integrity.
- Implementation properties: We classify a property as an implementation property if it enables more efficient implementations of the AEAD algorithm in specific cases or environments.
We note that some additional properties of AEAD algorithms found in the literature could not be allocated to either of these two groups. The observation is that such properties require an extension of the conventional AEAD interface. We refer to these properties as 'additional functionality properties' and define the corresponding group as follows:
- Additional functionality properties: We classify a property as an additional functionality property if it introduces new features in addition to the standard authenticated encryption with associated data.
With the extension of the conventional AEAD interface, each additional functionality property defines a new class of cryptographic algorithms. Consequently, the basic threats and adversarial capabilities must be redefined for each class. As a result, additional functionality properties consider the basic threats and adversarial capabilities for their class of algorithms, in contrast to security properties, which consider the extended ones. For this reason, we do not focus on additional functionality properties in this document. However, for the sake of completeness, in Appendix A, we briefly present two classes of AEAD algorithms with additional functionality.
Conventional Properties
In this section, we recall the conventional properties of an AEAD algorithm. Active nonce-respecting adversaries in a single-key setting are considered.
We say that an AEAD algorithm provides security if it provides conventional properties listed in this section.
Confidentiality
Definition: An AEAD algorithm guarantees that the plaintext is not available to an active, nonce-respecting adversary.
Security notion: IND-CCA [BN2000] (or IND-CCA2 [S04]).
Synonyms: Message privacy.
Notes: Confidentiality against passive adversaries can also be considered. The corresponding security notion is IND-CPA [BN2000][R02].
Further reading: [R02], [BN2000], [S04].
Data Integrity
Definition: An AEAD algorithm guarantees that the ciphertext and the associated data have not been changed or forged by an active, nonce-respecting adversary.
Security notion: IND-CTXT [BN2000] (or AUTH [R02]).
Synonyms: Message authentication, authenticity.
Further reading: [R02], [BN2000], [S04].
Authenticated Encryption Security
Definition: An AEAD algorithm provides confidentiality and data integrity against active, nonce-respecting adversaries.
Security notion: IND-CPA and IND-CTXT [BN2000][R02] (or equivalently IND-CCA3 [S04]).
Notes: Please refer to [I-D.irtf-cfrg-aead-limits] for usage limits on modern AEAD algorithms used in IETF protocols.
Further reading: [R02], [BN2000], [S04].
Security Properties
Blockwise Security
Definition: An AEAD algorithm provides security even if an adversary can adaptively choose the next part of the plaintext depending on already computed ciphertext parts during an encryption operation.
Security notion: D-LORS-BCPA for confidentiality against passive adversaries, B-INT-CTXT for integrity [EV16]; OAE1 [HRRV15] (stronger notion; originally, OAE in [FFL12]).
Examples: Deoxys [JNPS21], SAEF [ABV21].
Notes: Blockwise security is highly relevant for streamable AEAD algorithms (see Section 4.4.8). OAE1 (OAE) security notion [HRRV15], and OAE2 notion [HRRV15] are tailored for streamable AEAD algorithms. Blockwise security follows from security in the OAE notion [EV16]. For a discussion on security notions for streamable AEAD algorithms see [HRRV15].
Applications: Real-time streaming protocols, encryption on resource-constrained devices.
Further reading: [EV16], [JMV2002], [FJMV2004], [HRRV15].
Full Commitment
Definition: An AEAD algorithm guarantees that it is hard to find two or more different tuples of the key, nonce, associated data, and plaintext such that they encrypt to the same ciphertext. In other words, an AEAD scheme guarantees that a ciphertext is a commitment to all inputs of an authenticated encryption operation.
Security notion: CMT-4 [BH22], generalized CMT for a restricted setting (see the notes below) [MLGR23].
Examples: Ascon [DEMS21a][DEMS21b][YSS23], full committing versions of GCM and GCM-SIV [BH22], generic constructions [BH22][CR22].
Notes: Full commitment can be considered in a weaker setting, where certain restrictions on the tuples produced by an adversary are imposed [MLGR23]. For instance, an adversary must find tuples that all share the same associated data value. In such cases, an AEAD algorithm is said to provide full commitment in a restricted setting. The imposed restrictions MUST be listed.
Applications: Message franking [GLR17].
Further reading: [BH22], [CR22], [MLGR23].
Key Commitment
Definition: An AEAD algorithm guarantees that it is hard to find two or more different keys and the same number of potentially equal triples of nonce, associated data, and plaintext such that they encrypt to the same ciphertext under corresponding keys. In other words, an AEAD scheme guarantees that a ciphertext is a commitment to the key used for an authenticated encryption operation.
Security notion: CMT-1 [BH22].
Synonyms: Key-robustness, key collision resistance.
Examples: Ascon [DEMS21a][DEMS21b][YSS23], generic constructions from [BH22] [CR22].
Notes: Key commitment follows from full commitment. Full commitment does not follow from key commitment [BH22].
Applications: Password-Authenticated Key Exchange, password-based encryption [LGR21], key rotation, envelope encryption [ADGKLS22].
Further reading: [BH22],[CR22], [FOR17], [LGR21], [GLR17].
Leakage Resistance
Definition: An AEAD algorithm provides security even if some additional information about computations of an encryption (and possibly decryption) operation is obtained via side-channel leakages.
Security notion: CIL1 [GPPS19] (CIML2 [BPPS17] with leakages in decryption) for integrity, CCAL1 [GPPS19] (CCAmL2 [GPPS19] with leakages in decryption) for Authenticated Encryption security.
Examples: Ascon [DEMS21a][DEMS21b] (security under CIML2 and CCAL1 notions [B20]), TEDT [GPPS19].
Notes: Leakages during AEAD operation executions are implementation-dependent. It is possible to implement symmetric algorithms in a way that every possible physical leakage is entirely independent of the secret inputs of the algorithm (for example, with a masking technique [CJRR99]), meaning the adversary doesn't gain any additional information about the algorithm's computation via side-channel leakages. We say that an AEAD algorithm doesn't provide leakage resistance if it can achieve leakage resistance only with such an implementation. Leakage-resistant AEAD algorithms aim to place as mild requirements on implementation as possible to achieve leakage resistance. These requirements SHOULD be listed.
Confidentiality of plaintext in the presence of leakages in the encryption operation is unachievable if an adversary can repeat the nonce used to encrypt the plaintext in other encryption queries. Confidentiality can be achieved only for plaintexts encrypted with fresh nonces (analogously to nonce-misuse resilience, see Section 4.3.7). For further discussions, see [GPPS19] and [B20].
For primitive-based AEAD algorithms, key evolution (internal re-keying [RFC8645]) can contribute to achieving leakage resistance with leakages in encryption. Confidentiality in the presence of decryption leakages can be achieved by two-pass AEAD algorithms with key evolution, which compute independent ephemeral key values for encryption and tag generation, where the computation of these keys is implemented without any leakages. For more discussions on achieving leakage resistance see [B20].
A well-known weaker property, Leakage Resilience, introduced in [BMOS17], can also be considered. However, this document makes a conscious choice to focus on the stronger Leakage Resistance, following the framework established in [GPPS19], [B20], for its enhanced practicality and comprehensiveness.
Applications: Encryption on smart cards, Internet-of-things devices, or other constrained devices.
Further reading: [GPPS19], [B20], [BPPS17], [BMOS17].
Multi-User Security
Definition: An AEAD algorithm security degrades slower than linearly with an increase in the number of users.
Security notion: mu-ind [BT16].
Examples: AES-GCM [D07], ChaCha20-Poly1305 [RFC8439], AES-GCM-SIV [RFC8452], AEGIS [I-D.irtf-cfrg-aegis-aead].
Notes: It holds that for any AEAD algorithm security degrades no worse than linearly with an increase in the number of users [BT16]. However, for some applications with a significant number of users, better multi-user guarantees are required. For example, in the TLS 1.3 protocol, to address this issue, AEAD algorithms are used with a randomized nonce (deterministically derived from a traffic secret and a sequence number). Using nonce randomization in block cipher counter-based AEAD modes can contribute to multi-user security [BT16]. Multi-user usage limits for AES-GCM and ChaCha20-Poly1305 are provided in [I-D.irtf-cfrg-aead-limits].
A weaker security notion, multi-user key recovery, is also introduced and thoroughly studied in [BT16]. While this document focuses on indistinguishability for security notions, key recovery might be relevant and valuable to study alongside indistinguishability.
Applications: Data transmission layer of secure communication protocols (e.g., TLS, IPSec, SRTP, etc.)
Further reading: [BT16], [HTT18], [LMP17], [DGGP21], [BHT18].
Nonce-Hiding
Definition: An AEAD algorithm provides confidentiality for the nonce value used to encrypt plaintext. The algorithm includes information about the nonce in the ciphertext and doesn't require the nonce as input for the decryption operation.
Security notion: AE2 [BNT19].
Examples: Hide-Nonce (HN) transforms [BNT19].
Notes: As discussed in [BNT19], adversary-visible nonces might compromise message and user privacy, similar to the way any metadata might do. As pointed out in [B13], even using a counter as a nonce value might compromise privacy. Designing a privacy-preserving way to manage nonces might be a challenging problem for an application.
Applications: Any application that can't rely on a secure 'out-of-band' nonce communication.
Further reading: [BNT19].
Nonce Misuse
Definition: An AEAD algorithm provides security (resilience or resistance) even if an adversary can repeat nonces in its encryption queries. Nonce misuse resilience and resistance are defined as follows:
- Nonce misuse resilience: Security is provided only for messages encrypted with fresh nonces (correctly encrypted messages).
Security notion: CPA resilience (confidentiality), authenticity resilience (integrity), CCA resilience (authenticated encryption) [ADL17].
Examples: ChaCha20-Poly1305 [RFC8439], AES-GCM [D07] (only confidentiality).
- Nonce misuse resistance: Security is provided for all messages that were not encrypted with the same nonce value more than once.
Security notion: MRAE [RS06].
Examples: AES-GCM-SIV [RFC8452], Deoxys-II [JNPS21].
Notes: SIV construction [RS06] is a generic construction that provides nonce misuse resistance.
Notes: Nonce misuse resilience follows from nonce misuse resistance. Nonce misuse resistance does not follow from nonce misuse resilience.
Applications: Any application where nonce uniqueness can't be guaranteed, security against fault-injection attacks and malfunctions, processes parallelization, full disk encryption.
Further reading: [RS06], [ADL17].
Quantum Security
Definition: An AEAD algorithm provides security (in a Q1 or Q2 model) against a quantum adversary. Q1 and Q2 models are defined as follows:
- Q1 model: An adversary has access to local quantum computational power. It has classical access to encryption and decryption oracles.
Synonyms: Post-quantum security.
Examples: AES-GCM [D07], ChaCha20-Poly1305 [RFC8439], OCB [RFC7253], MGM [RFC9058], AES-GCM-SIV [RFC8452], AEGIS [I-D.irtf-cfrg-aegis-aead].
- Q2 model: An adversary has access to local quantum computational power. It has quantum access to encryption and decryption oracles, i.e., it can query encryption and decryption oracles with quantum superpositions of inputs to receive quantum superpositions of the outputs.
Synonyms: Superposition-based quantum security.
Examples: QCB [BBCLNSS21].
Notes: Most symmetric cryptographic algorithms that are secure in the classical model provide quantum security in the Q1 model, i.e., they are post-quantum secure. Security in the Q1 setting corresponds to security against "harvest now, decrypt later" attacks. Security in Q1 follows from security in Q2, the converse does not hold. For discussions on the relevance of the Q2 model please see [G17].
Further reading: [KLLNP16], [BBCLNSS21], [G17].
Reforgeability Resilience
Definition: An AEAD algorithm guarantees that once a successful forgery for the algorithm has been found, it is still hard to find any subsequent forgery.
Security notion: j-Int-CTXT [FLLW17].
Examples: Deoxys [JNPS21], AEGIS [I-D.irtf-cfrg-aegis-aead], Ascon [DEMS21a][DEMS21b].
Applications: VoIP, real-time streaming in a lightweight setting, applications that require small ciphertext expansion (i.e., short tags).
Further reading: [BC09], [FLLW17].
Release of Unverified Plaintext (RUP) Integrity
Definition: An AEAD algorithm provides data integrity even if plaintext is released for every ciphertext, including those with failed integrity verification.
Security notion: INT-RUP [A14].
Examples: GCM-RUP [ADL17].
Applications: Decryption with limited memory [FJMV2004], real-time streaming protocols.
Notes: In [ADL17] a generic approach to achieve INT-RUP security is introduced.
In the provided definition, we only consider integrity in the RUP setting, since confidentiality, in the usual sense, is unachievable under RUP. In [A14], the notion of 'Plaintext Awareness' is introduced, capturing the best possible confidentiality under RUP in the following sense: 'The adversary cannot gain any additional knowledge about the plaintext from decryption queries beyond what it can derive from encryption queries'.
Further reading: [A14], [ADL17].
Implementation Properties
Hardware efficient
Definition: An AEAD algorithm ensures optimal performance when operating on hardware that complies with the specified requirements.
Notes: Various classes of hardware may be taken into consideration. Certain algorithms are tailored to minimize the area of dedicated hardware implementations, while others are intended to capitalize on general-purpose CPUs, with or without specific instruction sets. It is RECOMMENDED to specify the minimum platform requirements for the AEAD to fulfill its intended purpose, as well as to match its performance and security claims.
Inverse-Free
Definition: An AEAD algorithm that is based on some primitive can be implemented without evaluating the inverse of that primitive.
Examples: AES-GCM [D07], ChaCha20-Poly1305 [RFC8439], OCB [RFC7253], MGM [RFC9058], AEGIS [I-D.irtf-cfrg-aegis-aead].
Notes: In a sponge-based AEAD algorithm, an underlying permutation is viewed as a primitive.
Lightweight
Definition: An AEAD algorithm can be efficiently and securely implemented on resource-constrained devices. In particular, it meets the criteria required in the NIST Lightweight Cryptography competition [MBTM17].
Examples: OCB [RFC7253], Ascon [DEMS21a][DEMS21b].
Further reading: [MBTM17].
Parallelizable
Definition: An AEAD algorithm can fully exploit the parallel computation infrastructure. In other words, a parallelizable AEAD algorithm allows for the computation of ciphertext segments (plaintext segments for decryption) in parallel, meaning that ciphertext segments are computed independently.
Synonyms: Pipelineable.
Examples: AES-GCM [D07], ChaCha20-Poly1305 [RFC8439], OCB [RFC7253], MGM [RFC9058], AEGIS [I-D.irtf-cfrg-aegis-aead].
Further reading: [C20].
Setup-Free
Definition: An AEAD algorithm's operations can be implemented in a way that using a new key incurs either no overhead or negligible overhead compared to the reuse of a previous key. Overhead may involve additional computations or increased storage space, such as precomputing a key schedule for a block cipher.
Examples: ChaCha20-Poly1305 [RFC8439], AEGIS [I-D.irtf-cfrg-aegis-aead], Ascon [DEMS21a][DEMS21b].
Single Pass
Definition: An AEAD algorithm encryption (decryption) operation can be implemented with a single pass over the plaintext (ciphertext).
Examples: AES-GCM [D07], ChaCha20-Poly1305 [RFC8439], OCB [RFC7253], MGM [RFC9058], AEGIS [I-D.irtf-cfrg-aegis-aead].
Static Associated Data Efficient
Definition: An AEAD algorithm allows pre-computation for static (or repeating) associated data so that static associated data doesn't significantly contribute to the computational cost of encryption.
Examples: AES-GCM [D07], ChaCha20-Poly1305 [RFC8439], OCB [RFC7253].
Streamable
Definition: An AEAD algorithm encryption (decryption) operation can be implemented with constant memory usage and a single one-direction pass over the plaintext (ciphertext), writing out the result during that pass.
Synonyms: Online.
Examples: AES-GCM [D07], ChaCha20-Poly1305 [RFC8439], OCB [RFC7253], MGM [RFC9058], AEGIS [I-D.irtf-cfrg-aegis-aead], Ascon [DEMS21a][DEMS21b].
Applications: Real-time streaming protocols, resource-constrained devices.
Notes: Blockwise security (see Section 4.3.1) and RUP integrity (see Section 4.3.10) might be relevant security properties for streamable AEAD algorithms in certain applications.
Further reading: [HRRV15], [FJMV2004].
Security Considerations
This document gives high-level definitions of AEAD properties. For each security property, we provide an informational reference to a game-based security notion (or security notions if there are separate notions for integrity and confidentiality) that formalizes the property. We only consider game-based notions and security properties that can be formalized using this approach. However, there are different approaches to formalizing AEAD security, like the indifferentiability framework [BM18]; security in such notions should be studied separately.
For some properties, examples of AEAD algorithms that provide them are given, with standardized AEAD algorithms preferred for commonly encountered properties. However, for certain properties, only non-standardized algorithms exist. Implementing such algorithms requires careful consideration, and it is advised to contact the algorithm designers for reference implementations and implementation guidelines.
Every claimed security property of an AEAD algorithm MUST undergo security analysis within a relevant notion. It's RECOMMENDED to use the security notions referenced in the document. If an alternative notion is used, there MUST exist proof of equivalence or it SHOULD be indicated that a non-equivalent notion is used. For security properties that extend adversarial capabilities, consideration of integrity and confidentiality separately may be relevant. If the algorithm provides only one of these, that SHOULD be indicated.
When specifying security requirements for an AEAD algorithm in an application, it SHOULD be indicated, for every required security property, whether only integrity or confidentiality is necessary. Additionally, for each security property, it SHOULD be specified whether an analysis in an alternative security notion is required. We also note that some additional properties come with trade-offs in terms of classical security and efficiency, and may only be supported in non-standardized or modified AEAD algorithms. This immediately implies challenges in deployment and interoperability. In an application, the requirements for additional AEAD properties SHOULD be highly motivated and justified, as should all trade-offs be carefully considered.
IANA Considerations
This document has no IANA actions.
References
Normative References
[D07]

Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC
Morris Dworkin
2007
DOI 10.6028/NIST.SP.800-38D
NIST Special Publication 800-38D
Informative References
[R02]

Authenticated-encryption with associated-data
Phillip Rogaway
2002
DOI 10.1145/586110.586125
Proceedings of the 9th ACM conference on Computer and communications security (CCS '02)
Association for Computing Machinery, New York, NY, USA, 98–107
[BN2000]

Authenticated Encryption: Relations among Notions and Analysis of the Generic Composition Paradigm
Mihir Bellare
Chanathip Namprempre
2000
DOI 10.1007/s00145-008-9026-x
Proceedings of ASIACRYPT 2000, Springer-Verlag, LNCS 1976, pp. 531-545
[JMV2002]

Blockwise-Adaptive Attackers Revisiting the (In)Security of Some Provably Secure Encryption Modes: CBC, GEM, IACBC
Antoine Joux
Gwenaelle Martinet
Frederic Valette
2002
DOI 10.1007/3-540-45708-9_2
Advances in Cryptology — CRYPTO 2002. CRYPTO 2002. Lecture Notes in Computer Science, vol 2442. Springer, Berlin, Heidelberg
[FJMV2004]

Authenticated On-Line Encryption
Pierre-Alain Fouque
Antoine Joux
Gwenaelle Martinet
Frederic Valette
2004
DOI 10.1007/978-3-540-24654-1_11
Selected Areas in Cryptography. SAC 2003. Lecture Notes in Computer Science, vol 3006. Springer, Berlin, Heidelberg.
[FOR17]

Security of Symmetric Primitives under Incorrect Usage of Keys
Pooya Farshim
Claudio Orlandi
Razvan Rosie
2017
DOI 10.13154/tosc.v2017.i1.449-473
IACR Transactions on Symmetric Cryptology, 2017(1), 449–473.
[LGR21]

Partitioning Oracle Attacks
Julia Len
Paul Grubbs
Thomas Ristenpart
2021
30th USENIX Security Symposium (USENIX Security 21), 195--212
[GLR17]

Message Franking via Committing Authenticated Encryption
Paul Grubbs
Jiahui Lu
Thomas Ristenpart
2017
DOI 10.1007/978-3-319-63697-9_3
Advances in Cryptology – CRYPTO 2017. CRYPTO 2017. Lecture Notes in Computer Science, vol 10403. Springer, Cham
[B20]

Mode-Level vs. Implementation-Level Physical Security in Symmetric Cryptography: A Practical Guide Through the Leakage-Resistance Jungle
Davide Bellizia
Olivier Bronchain
Gaëtan Cassiers
Vincent Grosso
Chun Guo
Charles Momin
Olivier Pereira
Thomas Peters
François-Xavier Standaert
2020
DOI 10.1007/978-3-030-56784-2_13
Advances in Cryptology – CRYPTO 2020. CRYPTO 2020. Lecture Notes in Computer Science, vol 12170. Springer, Cham
[GPPS19]

Authenticated Encryption with Nonce Misuse and Physical Leakages: Definitions, Separation Results and Leveled Constructions
Chun Guo
Olivier Pereira
Thomas Peters
François-Xavier Standaert
2019
DOI 10.1007/978-3-030-30530-7_8
Progress in Cryptology - LATINCRYPT 2019. LATINCRYPT 2019. Lecture Notes in Computer Science, vol 11774. Springer, Cham
[BT16]

The Multi-User Security of Authenticated Encryption: AES-GCM in TLS 1.3
Mihir Bellare
Björn Tackmann
2016
DOI 10.1007/978-3-662-53018-4_10
Advances in Cryptology – CRYPTO 2016. CRYPTO 2016. Lecture Notes in Computer Science, vol 9814. Springer, Berlin, Heidelberg
[RS06]

A Provable-Security Treatment of the Key-Wrap Problem
Phillip Rogaway
Thomas Shrimpton
2016
DOI 10.1007/11761679_23
Advances in Cryptology - EUROCRYPT 2006. EUROCRYPT 2006. Lecture Notes in Computer Science, vol 4004. Springer, Berlin, Heidelberg
[ADL17]

Boosting Authenticated Encryption Robustness with Minimal Modifications
Tomer Ashur
Orr Dunkelman
Atul Luykx
2017
DOI 10.1007/978-3-319-63697-9_1
Advances in Cryptology – CRYPTO 2017. CRYPTO 2017. Lecture Notes in Computer Science, vol 10403. Springer, Cham
[FLLW17]

Reforgeability of Authenticated Encryption Schemes
Christian Forler
Eik List
Stefan Lucks
Jakob Wenzel
2017
DOI 10.1007/978-3-319-59870-3_2
Information Security and Privacy. ACISP 2017. Lecture Notes in Computer Science, vol 10343. Springer, Cham
[BC09]

MAC Reforgeability
John Black
Martin Cochran
2009
DOI 10.1007/978-3-642-03317-9_21
Fast Software Encryption. FSE 2009. Lecture Notes in Computer Science, vol 5665. Springer, Berlin, Heidelberg
[A14]

How to Securely Release Unverified Plaintext in Authenticated Encryption
Elena Andreeva
Andrey Bogdanov
Atul Luykx
Bart Mennink
Nicky Mouha
Kan Yasuda
2014
DOI 10.1007/978-3-662-45611-8_6
Advances in Cryptology – ASIACRYPT 2014. ASIACRYPT 2014. Lecture Notes in Computer Science, vol 8873. Springer, Berlin, Heidelberg
[MBTM17]

Report on Lightweight Cryptography
Kerry A. McKay
Larry Bassham
Meltem Sönmez Turan
Nicky Mouha
2017
DOI 10.6028/NIST.IR.8114
[HRRV15]

Online Authenticated-Encryption and its Nonce-Reuse Misuse-Resistance
Viet Tung Hoang
Reza Reyhanitabar
Phillip Rogaway
Damian Vizár
2015
DOI 10.1007/978-3-662-47989-6_24
Advances in Cryptology -- CRYPTO 2015. CRYPTO 2015. Lecture Notes in Computer Science, vol 9215. Springer, Berlin, Heidelberg
[C20]

INT-RUP Secure Lightweight Parallel AE Modes
Avik Chakraborti
Nilanjan Datta
Ashwin Jha
Cuauhtemoc Mancillas-López
Mridul Nandi
Yu Sasaki
2020
DOI 10.13154/tosc.v2019.i4.81-118
IACR Transactions on Symmetric Cryptology, 2019(4), 81–118
[BKY02]

Incremental Unforgeable Encryption
Enrico Buonanno
Jonathan Katz
Moti Yung
2002
DOI 10.1007/3-540-45473-X_9
Fast Software Encryption. FSE 2001. Lecture Notes in Computer Science, vol 2355. Springer, Berlin, Heidelberg
[SY16]

A New Mode of Operation for Incremental Authenticated Encryption with Associated Data
Yu Sasaki
Kan Yasuda
2016
DOI 10.1007/978-3-319-31301-6_23
Selected Areas in Cryptography – SAC 2015. SAC 2015. Lecture Notes in Computer Science, vol 9566. Springer, Cham
[BNT19]

Nonces Are Noticed: AEAD Revisited
Mihir Bellare
Ruth Ng
Björn Tackmann
2019
DOI 10.1007/978-3-030-26948-7_9
Advances in Cryptology – CRYPTO 2019. CRYPTO 2019. Lecture Notes in Computer Science, vol 11692. Springer, Cham
[BH22]

Efficient schemes for committing authenticated encryption
Mihir Bellare
Viet Tung Hoang
2022
DOI 10.1007/978-3-031-07085-3_29
Advances in Cryptology – EUROCRYPT 2022. EUROCRYPT 2022. Lecture Notes in Computer Science, vol 13276. Springer, Cham.
[CR22]

On Committing Authenticated-Encryption
John Chan
Phillip Rogaway
2022
DOI 10.1007/978-3-031-17146-8_14
Computer Security – ESORICS 2022. ESORICS 2022. Lecture Notes in Computer Science, vol 13555. Springer, Cham.
[HKR2015]

Robust Authenticated-Encryption AEZ and the Problem That It Solves
Viet Tung Hoang
Ted Krovetz
Phillip Rogaway
2015
DOI 10.1007/978-3-662-46800-5_2
Advances in Cryptology -- EUROCRYPT 2015. EUROCRYPT 2015. Lecture Notes in Computer Science, vol 9056. Springer, Berlin, Heidelberg.
[MLGR23]

Context Discovery and Commitment Attacks: How to Break CCM, EAX, SIV, and More
Sanketh Menda
Julia Len
Paul Grubbs
Thomas Ristenpart
2023
DOI 10.1007/978-3-031-30634-1_13
Advances in Cryptology – EUROCRYPT 2023. EUROCRYPT 2023. Lecture Notes in Computer Science, vol 14007. Springer, Cham.
[BBCLNSS21]

QCB: Efficient Quantum-Secure Authenticated Encryption
Ritam Bhaumik
Xavier Bonnetain
André Chailloux
Gaëtan Leurent
María Naya-Plasencia
André Schrottenlohe
Yannick Seurin
2021
DOI 10.1007/978-3-030-92062-3_23
Advances in Cryptology – ASIACRYPT 2021. ASIACRYPT 2021. Lecture Notes in Computer Science(), vol 13090. Springer, Cham.
[KLLNP16]

Quantum Differential and Linear Cryptanalysis
Marc Kaplan
Gaëtan Leurent
Anthony Leverrier
María Naya-Plasencia
2021
DOI 10.13154/tosc.v2016.i1.71-94
IACR Transactions on Symmetric Cryptology, 2016(1), 71–94.
[G17]

Quantum Security of Cryptographic Primitives
Tommaso Gagliardoni
2017
Ph.D. Thesis, Technische Universität Darmstadt
[EV16]

Linking Online Misuse-Resistant Authenticated Encryption and Blockwise Attack Models
Guillaume Endignoux
Damian Vizár
2016
DOI 10.13154/TOSC.V2016.I2.125-144
IACR Transactions on Symmetric Cryptology
[FFL12]

McOE: A family of almost foolproof on-line authenticated encryption schemes
Ewan Fleischmann
Christian Forler
Stefan Lucks
2012
DOI 10.1007/978-3-642-34047-5_12
Fast Software Encryption: 19th International Workshop, FSE 2012, Washington, DC, USA, March 19-21, 2012. Revised Selected Papers. Springer Berlin Heidelberg, 2012
[ABV21]

Nonce-misuse security of the SAEF authenticated encryption mode
Elena Andreeva
Amit Singh Bhati
Damian Vizár
2021
DOI 10.1007/978-3-030-81652-0_20
Selected Areas in Cryptography: 27th International Conference, Halifax, NS, Canada (Virtual Event), October 21-23, 2020, Revised Selected Papers 27. Springer International Publishing, 2021
[YSS23]

Committing Security of Ascon: Cryptanalysis on Primitive and Proof on Mode
Yusuke Naito
Yu Sasaki
Takeshi Sugawara
2023
DOI 10.46586/tosc.v2023.i4.420-451
IACR Transactions on Symmetric Cryptology 2023, no. 4 (2023): 420-451
[ADGKLS22]

How to abuse and fix authenticated encryption without key commitment
Ange Albertini
Thai Duong
Shay Gueron
Stefan Kölbl
Atul Luykx
Sophie Schmieg
2022
1st USENIX Security Symposium (USENIX Security 22), pp. 3291-3308. 2022
[BPPS17]

On leakage-resilient authenticated encryption with decryption leakages
Francesco Berti
Olivier Pereira
Thomas Peters
François-Xavier Standaert
2017
DOI 10.13154/tosc.v2017.i3.271-293
IACR Transactions on Symmetric Cryptology (2017): 271-293
[HTT18]

The multi-user security of GCM, revisited: Tight bounds for nonce randomization
Viet Tung Hoang
Stefano Tessaro
Aishwarya Thiruvengadam
2018
DOI 10.1145/3243734.3243816
Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security, pp. 1429-1440. 2018
[BHT18]

Revisiting AES-GCM-SIV: multi-user security, faster key derivation, and better bounds
Priyanka Bose
Viet Tung Hoang
Stefano Tessaro
2018
DOI 10.1007/978-3-319-78381-9_18
Annual International Conference on the Theory and Applications of Cryptographic Techniques, pp. 468-499. Cham: Springer International Publishing, 2018
[LMP17]

Analyzing multi-key security degradation
Atul Luykx
Bart Mennink
Kenneth G. Paterson
2017
DOI 10.1007/978-3-319-70697-9_20
Conference on the Theory and Applications of Cryptology and Information Security, Hong Kong, China, December 3-7, 2017, Proceedings, Part II 23, pp. 575-605. Springer International Publishing, 2017.
[DGGP21]

The security of ChaCha20-Poly1305 in the multi-user setting
Jean Paul Degabriele
Jérôme Govinden
Felix Günther
Kenneth G. Paterson
2021
DOI 10.1145/3460120.3484814
In Proceedings of the 2021 ACM SIGSAC Conference on Computer and Communications Security, pp. 1981-2003. 2021.
[B13]

Re: secret message numbers
Daniel J. Bernstein
2013
Message in Google group on cryptographic competitions, October 2013.
[BM18]

Indifferentiable authenticated encryption
Manuel Barbosa
Pooya Farshim
2018
DOI 10.1007/978-3-319-96884-1_7
Advances in Cryptology–CRYPTO 2018: 38th Annual International Cryptology Conference, Santa Barbara, CA, USA, August 19–23, 2018, Proceedings, Part I 38, pp. 187-220. Springer International Publishing, 2018.
[JNPS21]

The Deoxys AEAD family
Jérémy Jean
Ivica Nikolić
Thomas Peyrin
Yannick Seurin
2021
DOI 10.1007/s00145-021-09397-w
Journal of Cryptology 34, no. 3 (2021): 31.
[DEMS21a]

Ascon v1.2: Lightweight Authenticated Encryption and Hashing
Christoph Dobraunig
Maria Eichlseder
Florian Mendel
Martin Schläffer
2021
DOI 10.1007/s00145-021-09398-9
Journal of Cryptology 34 (2021): 1-42.
[DEMS21b]

Ascon v1.2
Christoph Dobraunig
Maria Eichlseder
Florian Mendel
Martin Schläffer
2021
Submission to the NIST LWC Competition
[CJRR99]

Towards sound approaches to counteract power-analysis attacks.
Suresh Chari
Charanjit S. Jutla
Josyula R. Rao
Pankaj Rohatgi
1999
DOI 10.1007/3-540-48405-1_26
Advances in Cryptology—CRYPTO'99: 19th Annual International Cryptology Conference Santa Barbara, California, USA, August 15–19, 1999 Proceedings 19, pp. 398-412. Springer Berlin Heidelberg, 1999.
[M05]

Efficient authentication of large, dynamic data sets using Galois/Counter Mode (GCM).
David McGrew
2005
DOI 10.1109/SISW.2005.3
Third IEEE International Security in Storage Workshop (SISW'05), pp. 6-pp. IEEE, 2005.
[S04]

A Characterization of Authenticated-Encryption as a Form of Chosen-Ciphertext Security
Tom Shrimpton
2004
Cryptology ePrint Archive, Paper 2004/272
[BMOS17]

Authenticated encryption in the face of protocol and side channel leakage.
Guy Barwell
Daniel P. Martin
Elisabeth Oswald
Martijn Stam
2017
DOI 10.1007/978-3-319-70694-8_24
Advances in Cryptology – ASIACRYPT 2017. ASIACRYPT 2017. Lecture Notes in Computer Science, vol 10624. Springer, Cham
[RFC5116]
[RFC8446]
[RFC4303]
[RFC8221]
[RFC9000]
[RFC2119]
[RFC8174]
[I-D.irtf-cfrg-aead-limits]
[RFC8645]
[RFC8439]
[RFC8452]
[I-D.irtf-cfrg-aegis-aead]
[RFC7253]
[RFC9058]
AEAD Algorithms with Additional Functionality
In this section, we briefly discuss AEAD algorithms that provide additional functionality. As noted in Section 4.1, each additional functionality requires a redefinition of the conventional AEAD interface; thus, each additional functionality property defines a new class of cryptographic algorithms.
Most importantly, for every Additional Functionality AEAD class, conventional security properties must be redefined concerning the targeted additional functionality and the new interface. Although it might be possible to consider a particular Additional Functionality AEAD algorithm as a conventional AEAD algorithm and study it for the conventional confidentiality and integrity, security (or insecurity) in that sense won't be sufficient to label that algorithm as a secure (or insecure) Additional Functionality AEAD. Only security in the sense of the redefined conventional properties would suffice.
For the examples given in this section, we leave it out of scope how to concretely redefine conventional security for these classes; we only briefly describe the additional functionality they offer and provide further references.
Incremental Authenticated Encryption
Definition: An AEAD algorithm allows re-encrypting and authenticating a message (associated data and a plaintext pair), which only partly differs from some previous message, faster than processing it from scratch.
Examples: Incremental AEAD algorithm of [SY16].
Security notion: Privacy, Authenticity [SY16].
Notes: The interface of an incremental AEAD algorithm is usually expanded, when compared with conventional AEAD, with several operations, which perform different types of updates. For example, one can consider such operations as "Append" or "Chop", which provide a straightforward additional functionality. A comprehensive definition of an incremental AEAD interface is provided in [SY16].
Further reading: [SY16], [M05], [BKY02].
Robust Authenticated Encryption
Definition: An AEAD algorithm allows users to choose a desired ciphertext expansion (the difference between the length of plaintext and corresponding ciphertext) along with an input to the encryption operation. This feature enables the regulation of desired data integrity guarantees, which depend on ciphertext expansion, for each particular application while using the same algorithm implementation.
Examples: AEZ [HKR2015].
Security notion: RAE [HKR2015].
Notes: The security goal of robust AEAD algorithms is to ensure the best possible security, even with small ciphertext expansion (referred to as stretch). For instance, analyzing any AEAD algorithm with a one-byte stretch for conventional integrity reveals insecurity, as the probability of forging a ciphertext is no less than 1/256. Nonetheless, from the robust AEAD perspective, an algorithm with such forgery probability for a one-byte ciphertext expansion is secure, representing the best achievable security in that scenario.
Further reading: [HKR2015].
Acknowledgments
This document benefited greatly from the comments received from the CFRG community, for which we are very grateful. We would also like to extend special appreciation to Liliya Akhmetzyanova, Evgeny Alekseev, Alexandra Babueva, Frank Denis, Kirill Kutsenok, Sergey Kyazhin, Samuel Lucas, Grigory Marshalko, Christopher Patton, and Christopher Wood for their thoughtful comments, proposals, and discussions.