CryptoPro

andbogc@gmail.com

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 and aims to improve consistency in the terminology used in documentation. This document is a product of the Crypto Forum Research Group.

Status of This Memo 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 .

Copyright Notice 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 () 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.

Table of Contents

• .  Introduction
  • .  Background
  • .  Scope
• .  Conventions Used in This Document
• .  AEAD Algorithms
• .  AEAD Properties
  • .  Classification of Additional AEAD Properties
  • .  Conventional Properties
    • .  Confidentiality
    • .  Data Integrity
    • .  Authenticated Encryption Security
  • .  Security Properties
    • .  Blockwise Security
    • .  Full Commitment
    • .  Key Commitment
    • .  Leakage Resistance
    • .  Multi-user Security
    • .  Nonce Hiding
    • .  Nonce Misuse
    • .  Quantum Security
    • .  Reforgeability Resilience
    • . Release of Unverified Plaintext (RUP) Integrity
  • .  Implementation Properties
    • .  Hardware Efficient
    • .  Inverse-Free
    • .  Lightweight
    • .  Parallelizable
    • .  Setup-Free
    • .  Single Pass
    • .  Static Associated Data Efficient
    • .  Streamable
• .  Security Considerations
• .  IANA Considerations
• .  References
  • .  Normative References
  • .  Informative References
• .  AEAD Algorithms with Additional Functionality
  • .  Incremental Authenticated Encryption
  • .  Robust Authenticated Encryption
• Acknowledgments
• Author's Address

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 . 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 , IPsec Encapsulating Security Payload (ESP) , and QUIC . 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.

Scope In 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 ) and implementation properties (see ). 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 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 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 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 .

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 the authentication tag as an independent output of the encryption operation and 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 . 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.

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 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 AEAD.

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 , 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 the 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 notions:

IND-CCA (or IND-CCA2 )

Synonyms:

Message privacy

Notes:

Confidentiality against passive adversaries can also be considered. The corresponding security notion is IND-CPA .

Further reading:

, ,

Data Integrity

Definition:

An AEAD algorithm allows one to ensure that the ciphertext and the associated data have not been changed or forged by an active, nonce-respecting adversary.

Security notions:

INT-CTXT (or AUTH )

Synonyms:

Message authentication, authenticity

Further reading:

, ,

Authenticated Encryption Security

Definition:

An AEAD algorithm provides confidentiality and data integrity against active, nonce-respecting adversaries.

Security notions:

IND-CPA and INT-CTXT (or equivalently, IND-CCA3 )

Notes:

Please refer to for usage limits on modern AEAD algorithms used in IETF protocols.

Further reading:

, ,

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 notions:

D-LORS-BCPA for confidentiality against passive adversaries, B-INT-CTXT for integrity ; OAE1 (a stronger notion; originally OAE (Online Authenticated Encryption) in )

Examples:

Deoxys , SAEF

Notes:

Blockwise security is highly relevant for streamable AEAD algorithms (see ). The OAE1 security notion and the OAE2 notion are tailored for streamable AEAD algorithms. OAE1 was first defined in under the name OAE; however, it contained a glitch, and the reformulated definition was presented in . Blockwise security follows from security in the OAE notion . For a discussion on security notions for streamable AEAD algorithms, see .

Applications:

Real-time streaming protocols, encryption on resource-constrained devices

Further reading:

, , ,

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 notions:

CMT-4 , generalized CMT for a restricted setting (see the notes below)

Examples:

Ascon , full committing versions of Galois/Counter Mode (GCM) and GCM-SIV , generic constructions and

Notes:

Full commitment can be considered in a weaker setting, where certain restrictions on the tuples produced by an adversary are imposed . 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

Further reading:

, ,

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 notions:

CMT-1

Synonyms:

Key robustness, key collision resistance

Examples:

Ascon , generic constructions from and

Notes:

Key commitment follows from full commitment. Full commitment does not follow from key commitment .

Applications:

Password-Authenticated Key Exchange, password-based encryption , key rotation, envelope encryption

Further reading:

, , , ,

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 notions:

CIL1 (CIML2 with leakages in decryption) for integrity, CCAL1 (CCAmL2 with leakages in decryption) for authenticated encryption security

Examples:

Ascon (security under CIML2 and CCAL1 notions ), TEDT

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 ), 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 ). For further discussions, see and . For primitive-based AEAD algorithms, key evolution (internal re-keying ) 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 . Leakage Resilience, a well-known weaker property introduced in , can also be considered. However, following the framework established in and , this document makes a conscious choice to focus on the stronger Leakage Resistance for its enhanced practicality and comprehensiveness.

Applications:

Encryption on smart cards, Internet-of-Things devices, or other constrained devices

Further reading:

, , ,

Multi-user Security

Definition:

The security of an AEAD algorithm degrades slower than linearly with an increase in the number of users.

Security notions:

mu-ind

Examples:

AES-GCM , ChaCha20-Poly1305 , AES-GCM-SIV , AEGIS

Notes:

For any AEAD algorithm, security degrades no worse than linearly with an increase in the number of users . 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 . Multi-user usage limits for AES-GCM and ChaCha20-Poly1305 are provided in . A weaker security notion, multi-user key recovery, is also introduced and thoroughly studied in . 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, the Secure Real-time Transport Protocol (SRTP), etc.)

Further reading:

, , , ,

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 notions:

AE2

Examples:

Hide-Nonce (HN) transforms

Notes:

As discussed in , adversary-visible nonces might compromise message and user privacy, similar to the way any metadata might. As pointed out in , 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:

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 for messages encrypted with non-repeated (fresh) nonces (correctly encrypted messages).

Security notions:

Chosen-Plaintext Attack (CPA) resilience (confidentiality), authenticity resilience (integrity), Chosen-Ciphertext Attack (CCA) resilience (authenticated encryption)

Examples:

ChaCha20-Poly1305 , AES-GCM (only confidentiality)

Nonce misuse resistance:

Security is provided for all messages that were not encrypted with the same nonce value more than once.

Security notions:

MRAE

Examples:

AES-GCM-SIV , Deoxys-II

Notes:

Synthetic Initialization Vector (SIV) construction 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:

, ,

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 , ChaCha20-Poly1305 , OCB , Multilinear Galois Mode (MGM) , AES-GCM-SIV , AEGIS

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

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 .

Further reading:

, ,

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 notions:

j-Int-CTXT

Examples:

Deoxys , AEGIS , Ascon

Applications:

Voice over IP (VoIP), real-time streaming in a lightweight setting, applications that require small ciphertext expansion (i.e., short tags)

Further reading:

,

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 notions:

INT-RUP

Examples:

GCM , GCM-RUP

Applications:

Decryption with limited memory , real-time streaming protocols

Notes:

In , 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 , 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".

Further reading:

, ,

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 based on a given primitive can be implemented without invoking the inverse of that primitive.

Examples:

AES-GCM , ChaCha20-Poly1305 , MGM , AEGIS

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 .

Examples:

OCB , Ascon

Further reading:

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 , ChaCha20-Poly1305 , OCB , MGM , AEGIS

Further reading:

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 , AEGIS , Ascon

Single Pass

Definition:

An AEAD algorithm encryption (decryption) operation can be implemented with a single pass over the plaintext (ciphertext).

Examples:

AES-GCM , ChaCha20-Poly1305 , OCB , MGM , AEGIS

Static Associated Data Efficient

Definition:

An AEAD algorithm allows precomputation for static (or repeating) associated data so that static associated data doesn't significantly contribute to the computational cost of encryption.

Examples:

AES-GCM , ChaCha20-Poly1305 , OCB

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 , ChaCha20-Poly1305 , OCB , MGM , AEGIS , Ascon

Applications:

Real-time streaming protocols, resource-constrained devices

Notes:

Blockwise security (see ) and RUP integrity (see ) might be relevant security properties for streamable AEAD algorithms in certain applications.

Further reading:

,

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 ; 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, and all trade-offs should be carefully considered.

IANA Considerations This document has no IANA actions.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document defines algorithms for Authenticated Encryption with Associated Data (AEAD), and defines a uniform interface and a registry for such algorithms. The interface and registry can be used as an application-independent set of cryptoalgorithm suites. This approach provides advantages in efficiency and security, and promotes the reuse of crypto implementations. [STANDARDS-TRACK] RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References Advances in Cryptology - ASIACRYPT 2014, Lecture Notes in Computer Science, vol. 8873, pp. 105-125 Selected Areas in Cryptography (SAC 2020), Lecture Notes in Computer Science, vol. 12804, pp. 512-534 31st USENIX Security Symposium (USENIX Security 22), pp. 3291-3308 Advances in Cryptology - CRYPTO 2017, Lecture Notes in Computer Science, vol. 10403, pp. 3-33 IBM Research Europe - Zurich Mozilla Cloudflare An Authenticated Encryption with Associated Data (AEAD) algorithm provides confidentiality and integrity. Excessive use of the same key can give an attacker advantages in breaking these properties. This document provides simple guidance for users of common AEAD functions about how to limit the use of keys in order to bound the advantage given to an attacker. It considers limits in both single- and multi-key settings. Work in Progress Fastly Inc. Individual Contributor This document describes the AEGIS-128L, AEGIS-256, AEGIS-128X, and AEGIS-256X AES-based authenticated encryption algorithms designed for high-performance applications. The document is a product of the Crypto Forum Research Group (CFRG). It is not an IETF product and is not a standard. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/cfrg/draft-irtf-cfrg-aegis-aead. Work in Progress Message to the Cryptographic Competitions Google Group Advances in Cryptology - CRYPTO 2020, Lecture Notes in Computer Science, vol. 12170, pp. 369-400 Advances in Cryptology - ASIACRYPT 2021, Lecture Notes in Computer Science, vol. 13090, pp. 668-698 Fast Software Encryption (FSE 2009), Lecture Notes in Computer Science, vol. 5665, pp. 345-362 Advances in Cryptology - EUROCRYPT 2022, Lecture Notes in Computer Science, vol. 13276, pp. 845-875 Advances in Cryptology - EUROCRYPT 2018, Lecture Notes in Computer Science, vol. 10820, pp. 468-499 Fast Software Encryption (FSE 2001), Lecture Notes in Computer Science, vol. 2355, pp. 109-124 Advances in Cryptology - CRYPTO 2018, Lecture Notes in Computer Science, vol. 10991, pp. 187-220 Advances in Cryptology - ASIACRYPT 2017, Lecture Notes in Computer Science, vol. 10624, pp. 693-723 Journal of Cryptology, vol. 21, pp. 469-491 Advances in Cryptology - CRYPTO 2019, Lecture Notes in Computer Science, vol. 11692, pp. 235-265 IACR Transactions on Symmetric Cryptology, vol. 2017, no. 3, pp. 271-293 Advances in Cryptology - CRYPTO 2016, Lecture Notes in Computer Science, vol. 9814, pp. 247-276 IACR Transactions on Symmetric Cryptology, vol. 2019, no.4, pp. 81-118 Advances in Cryptology - CRYPTO'99, Lecture Notes in Computer Science, vol. 1666, pp. 398-412 Computer Security - ESORICS 2022, Lecture Notes in Computer Science, vol. 13555, pp. 275-294 Journal of Cryptology, vol. 34, no. 33 Submission to the NIST LWC Competition Proceedings of the 2021 ACM SIGSAC Conference on Computer and Communications Security (CCS '21), pp. 1981-2003 IACR Transactions on Symmetric Cryptology, vol. 2016, no. 2, pp. 125-144 Fast Software Encryption (FSE 2012), Lecture Notes in Computer Science, vol. 7549, pp. 196-215 Selected Areas in Cryptography (SAC 2003), Lecture Notes in Computer Science, vol. 3006 Information Security and Privacy (ACISP 2017), Lecture Notes in Computer Science, vol. 10343, pp. 19-37 IACR Transactions on Symmetric Cryptology, vol. 2017, no. 1, pp. 449-473 Ph.D. Thesis, Technische Universität Darmstadt Advances in Cryptology - CRYPTO 2017, Lecture Notes in Computer Science, vol. 10403, pp. 66-97 Progress in Cryptology - LATINCRYPT 2019, Lecture Notes in Computer Science, vol. 11774, pp. 150-172 Advances in Cryptology -- EUROCRYPT 2015, Lecture Notes in Computer Science, vol. 9056, pp. 15-44 Advances in Cryptology -- CRYPTO 2015, Lecture Notes in Computer Science, vol. 9215, pp. 493-517 Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security (CCS '18), pp. 1429-1440 Topics in Cryptology - CT-RSA 2025, Lecture Notes in Computer Science, vol. 15598 Advances in Cryptology - CRYPTO 2002, Lecture Notes in Computer Science, vol. 2442 Journal of Cryptology, vol. 34, no. 31 IACR Transactions on Symmetric Cryptology, vol. 2016, no.1, pp. 71-94 30th USENIX Security Symposium (USENIX Security 21), pp. 195-212 Advances in Cryptology - ASIACRYPT 2017, Lecture Notes in Computer Science, vol. 10625, pp. 575-605 Third IEEE International Security in Storage Workshop (SISW'05), pp. 6-94 Advances in Cryptology - EUROCRYPT 2023, Lecture Notes in Computer Science, vol. 14007, pp. 379-407 Proceedings of the 9th ACM Conference on Computer and Communications Security (CCS '02), pp. 98-107 This document describes an updated version of the Encapsulating Security Payload (ESP) protocol, which is designed to provide a mix of security services in IPv4 and IPv6. ESP is used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and limited traffic flow confidentiality. This document obsoletes RFC 2406 (November 1998). [STANDARDS-TRACK] This document specifies OCB, a shared-key blockcipher-based encryption scheme that provides confidentiality and authenticity for plaintexts and authenticity for associated data. This document is a product of the Crypto Forum Research Group (CFRG). This document replaces RFC 7321, "Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)". The goal of this document is to enable ESP and AH to benefit from cryptography that is up to date while making IPsec interoperable. This document defines the ChaCha20 stream cipher as well as the use of the Poly1305 authenticator, both as stand-alone algorithms and as a "combined mode", or Authenticated Encryption with Associated Data (AEAD) algorithm. RFC 7539, the predecessor of this document, was meant to serve as a stable reference and an implementation guide. It was a product of the Crypto Forum Research Group (CFRG). This document merges the errata filed against RFC 7539 and adds a little text to the Security Considerations section. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. This memo specifies two authenticated encryption algorithms that are nonce misuse resistant -- that is, they do not fail catastrophically if a nonce is repeated. This document is the product of the Crypto Forum Research Group. A certain maximum amount of data can be safely encrypted when encryption is performed under a single key. This amount is called the "key lifetime". This specification describes a variety of methods for increasing the lifetime of symmetric keys. It provides two types of re-keying mechanisms based on hash functions and block ciphers that can be used with modes of operations such as CTR, GCM, CBC, CFB, and OMAC. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm. Multilinear Galois Mode (MGM) is an Authenticated Encryption with Associated Data (AEAD) block cipher mode based on the Encrypt-then-MAC (EtM) principle. MGM is defined for use with 64-bit and 128-bit block ciphers. MGM has been standardized in Russia. It is used as an AEAD mode for the GOST block cipher algorithms in many protocols, e.g., TLS 1.3 and IPsec. This document provides a reference for MGM to enable review of the mechanisms in use and to make MGM available for use with any block cipher. Advances in Cryptology - EUROCRYPT 2006, Lecture Notes in Computer Science, vol. 4004, pp. 373-390 Cryptology ePrint Archive, Paper 2004/272 Selected Areas in Cryptography - SAC 2015, Lecture Notes in Computer Science, vol. 9566, pp. 397-416 IACR Transactions on Symmetric Cryptology, vol. 2023, no. 4, pp. 420-451

AEAD Algorithms with Additional Functionality In this section, we briefly discuss AEAD algorithms that provide additional functionality. As noted in , 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.

Incremental Authenticated Encryption

Definition:

For a message that only partly differs from some previous message, an AEAD algorithm allows re-encrypting and authenticating that message (associated data and a plaintext pair) faster than processing it from scratch.

Examples:

Incremental AEAD algorithm of

Security notions:

Privacy, authenticity

Notes:

When compared with conventional AEAD, the interface of an incremental AEAD algorithm is usually expanded with several operations, which perform different types of updates. For example, one can consider operations such as "Append" or "Chop", which provide a straightforward additional functionality. A comprehensive definition of an incremental AEAD interface is provided in .

Further reading:

, ,

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

Security notions:

Robust Authenticated Encryption (RAE)

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:

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 , , , , , , , , , and for their thoughtful comments, proposals, and discussions.

Author's Address CryptoPro

andbogc@gmail.com