| RFC 9771 | Properties of AEAD Algorithms | April 2025 |
| Bozhko | Informational | [Page] |
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 and aims to improve consistency in the terminology used in documentation. This document is a product of the Crypto Forum Research Group.¶
This document is not an Internet Standards Track specification; it is published for informational purposes.¶
This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the consensus of the Crypto Forum Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.¶
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9771.¶
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶
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.¶
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 Encapsulating Security Payload (ESP) [RFC4303] [RFC8221], and QUIC [RFC9000].¶
While confidentiality and data integrity (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. This is a common situation when related but formally different properties are named identically or when 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.¶
In Section 4 of this document, we provide a 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; we do not consider security properties for which no game-based formalization exists. When possible, we offer additional information: synonymous names, examples of algorithms that provide the property, applications that might necessitate the 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 document development process in the IRTF and IETF:¶
For an RFC or I-D that defines an AEAD algorithm, it is recommended to use the notations in 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 in 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.¶
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.¶
This section gives a conventional definition of an AEAD algorithm following [RFC5116].¶
An AEAD algorithm is defined by two operations, which are authenticated encryption and authenticated decryption:¶
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 consider the authentication tag as part of the ciphertext.¶
For more details on the AEAD definition, please refer to [RFC5116].¶
Throughout this document, by default, we consider nonce-based AEAD algorithms, which have an interface as defined above, and we give no other restrictions on their structure. However, some properties considered in the document apply only to particular classes of such algorithms, like AEAD algorithms based on block ciphers (such algorithms use a block cipher as a building block). If that is the case, we explicitly point that out in the corresponding section.¶
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 are categorized into one of these two groups:¶
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:¶
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.¶
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 the conventional properties listed in this section.¶
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 only achieve leakage resistance with such an implementation. Leakage-resistant AEAD algorithms aim to place requirements on implementations that are as mild 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 discussion on achieving leakage resistance, see [B20].¶
Leakage Resilience, a well-known weaker property introduced in [BMOS17], can also be considered. However, following the framework established in [GPPS19] and [B20], this document makes a conscious choice to focus on the stronger Leakage Resistance for its enhanced practicality and comprehensiveness.¶
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, AEAD algorithms are used with a randomized nonce (deterministically derived from a traffic secret and a sequence number) to address this issue. 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 [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.¶
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:¶
An AEAD algorithm provides security (in a Q1 or Q2 model) against a quantum adversary. Q1 and Q2 models are defined as follows:¶
An adversary has access to local quantum computational power. It has classical access to encryption and decryption oracles.¶
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.¶
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 besides what it can derive from encryption queries".¶
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, proof of equivalence MUST exist, or use of a non-equivalent notion SHOULD be indicated. 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 they 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.¶
This document has no IANA actions.¶
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 AEAD class with additional functionality, conventional security properties must be redefined concerning the targeted additional functionality and the new interface. Although it might be possible to consider a particular AEAD algorithm with additional functionality 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.¶
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.¶