rfc9771.original   rfc9771.txt 
Crypto Forum A.A. Bozhko, Ed. Internet Research Task Force (IRTF) A. Bozhko, Ed.
Internet-Draft CryptoPro Request for Comments: 9771 CryptoPro
Intended status: Informational 11 October 2024 Category: Informational May 2025
Expires: 14 April 2025 ISSN: 2070-1721
Properties of AEAD Algorithms Properties of Authenticated Encryption with Associated Data (AEAD)
draft-irtf-cfrg-aead-properties-09 Algorithms
Abstract Abstract
Authenticated Encryption with Associated Data (AEAD) algorithms Authenticated Encryption with Associated Data (AEAD) algorithms
provide both confidentiality and integrity of data. The widespread provide both confidentiality and integrity of data. The widespread
use of AEAD algorithms in various applications has led to an use of AEAD algorithms in various applications has led to an
increased demand for AEAD algorithms with additional properties, increased demand for AEAD algorithms with additional properties,
driving research in the field. This document provides definitions driving research in the field. This document provides definitions
for the most common of those properties, aiming to improve for the most common of those properties and aims to improve
consistency in the terminology used in documentation. This document consistency in the terminology used in documentation. This document
is a product of the Crypto Forum Research Group. is a product of the Crypto Forum Research Group.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Research Task Force
and may be updated, replaced, or obsoleted by other documents at any (IRTF). The IRTF publishes the results of Internet-related research
time. It is inappropriate to use Internet-Drafts as reference and development activities. These results might not be suitable for
material or to cite them other than as "work in progress." 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.
This Internet-Draft will expire on 14 April 2025. 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 Notice Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document.
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Background
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Scope
2. Conventions Used in This Document . . . . . . . . . . . . . . 4 2. Conventions Used in This Document
3. AEAD Algorithms . . . . . . . . . . . . . . . . . . . . . . . 4 3. AEAD Algorithms
4. AEAD Properties . . . . . . . . . . . . . . . . . . . . . . . 5 4. AEAD Properties
4.1. Classification of additional AEAD Properties . . . . . . 5 4.1. Classification of Additional AEAD Properties
4.2. Conventional Properties . . . . . . . . . . . . . . . . . 6 4.2. Conventional Properties
4.2.1. Confidentiality . . . . . . . . . . . . . . . . . . . 6 4.2.1. Confidentiality
4.2.2. Data Integrity . . . . . . . . . . . . . . . . . . . 7 4.2.2. Data Integrity
4.2.3. Authenticated Encryption Security . . . . . . . . . . 7 4.2.3. Authenticated Encryption Security
4.3. Security Properties . . . . . . . . . . . . . . . . . . . 7 4.3. Security Properties
4.3.1. Blockwise Security . . . . . . . . . . . . . . . . . 7 4.3.1. Blockwise Security
4.3.2. Full Commitment . . . . . . . . . . . . . . . . . . . 8 4.3.2. Full Commitment
4.3.3. Key Commitment . . . . . . . . . . . . . . . . . . . 8 4.3.3. Key Commitment
4.3.4. Leakage Resistance . . . . . . . . . . . . . . . . . 9 4.3.4. Leakage Resistance
4.3.5. Multi-User Security . . . . . . . . . . . . . . . . . 10 4.3.5. Multi-user Security
4.3.6. Nonce-Hiding . . . . . . . . . . . . . . . . . . . . 10 4.3.6. Nonce Hiding
4.3.7. Nonce Misuse . . . . . . . . . . . . . . . . . . . . 11 4.3.7. Nonce Misuse
4.3.8. Quantum Security . . . . . . . . . . . . . . . . . . 12 4.3.8. Quantum Security
4.3.9. Reforgeability Resilience . . . . . . . . . . . . . . 12 4.3.9. Reforgeability Resilience
4.3.10. Release of Unverified Plaintext (RUP) Integrity . . . 13 4.3.10. Release of Unverified Plaintext (RUP) Integrity
4.4. Implementation Properties . . . . . . . . . . . . . . . . 13 4.4. Implementation Properties
4.4.1. Hardware efficient . . . . . . . . . . . . . . . . . 13 4.4.1. Hardware Efficient
4.4.2. Inverse-Free . . . . . . . . . . . . . . . . . . . . 14 4.4.2. Inverse-Free
4.4.3. Lightweight . . . . . . . . . . . . . . . . . . . . . 14 4.4.3. Lightweight
4.4.4. Parallelizable . . . . . . . . . . . . . . . . . . . 14 4.4.4. Parallelizable
4.4.5. Setup-Free . . . . . . . . . . . . . . . . . . . . . 15 4.4.5. Setup-Free
4.4.6. Single Pass . . . . . . . . . . . . . . . . . . . . . 15 4.4.6. Single Pass
4.4.7. Static Associated Data Efficient . . . . . . . . . . 15 4.4.7. Static Associated Data Efficient
4.4.8. Streamable . . . . . . . . . . . . . . . . . . . . . 15 4.4.8. Streamable
5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 5. Security Considerations
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 6. IANA Considerations
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 7. References
7.1. Normative References . . . . . . . . . . . . . . . . . . 17 7.1. Normative References
7.2. Informative References . . . . . . . . . . . . . . . . . 17 7.2. Informative References
Appendix A. AEAD Algorithms with Additional Functionality . . . 25 Appendix A. AEAD Algorithms with Additional Functionality
A.1. Incremental Authenticated Encryption . . . . . . . . . . 26 A.1. Incremental Authenticated Encryption
A.2. Robust Authenticated Encryption . . . . . . . . . . . . . 26 A.2. Robust Authenticated Encryption
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 27 Acknowledgments
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 27 Author's Address
1. Introduction 1. Introduction
An Authenticated Encryption with Associated Data (AEAD) algorithm An Authenticated Encryption with Associated Data (AEAD) algorithm
provides confidentiality for the plaintext to be encrypted and provides confidentiality for the plaintext to be encrypted and
integrity for the plaintext and some associated data (sometimes integrity for the plaintext and some associated data (sometimes
called Header). AEAD algorithms play a crucial role in various called "Header"). AEAD algorithms play a crucial role in various
applications and have emerged as a significant focus in cryptographic applications and have emerged as a significant focus in cryptographic
research. research.
1.1. Background 1.1. Background
AEAD algorithms are formally defined in [RFC5116]. The main benefit AEAD algorithms are formally defined in [RFC5116]. The main benefit
of AEAD algorithms is that they simultaneously provide data of AEAD algorithms is that they simultaneously provide data
confidentiality and integrity and have a simple unified interface. confidentiality and integrity and have a simple unified interface.
In contrast to generic compositions of Message Authentication Code In contrast to generic compositions of Message Authentication Code
(MAC) and encryption algorithms, an AEAD algorithm allows for a (MAC) and encryption algorithms, an AEAD algorithm allows for a
reduction in key and state sizes, improving the data processing reduction in key and state sizes, improving the data processing
speed. Most AEAD algorithms come with security analysis, usage speed. Most AEAD algorithms come with security analysis, usage
guidelines, and reference implementations. Consequently, their guidelines, and reference implementations. Consequently, their
integration into high-level schemes and protocols is highly integration into high-level schemes and protocols is highly
transparent. For instance, AEAD algorithms are mandatory in TLS 1.3 transparent. For instance, AEAD algorithms are mandatory in TLS 1.3
[RFC8446], IPsec ESP [RFC4303][RFC8221], and QUIC [RFC9000]. [RFC8446], IPsec Encapsulating Security Payload (ESP) [RFC4303]
[RFC8221], and QUIC [RFC9000].
While confidentiality and data integrity, being the conventional While confidentiality and data integrity (the conventional properties
properties of AEAD algorithms, suffice for many applications, some of AEAD algorithms) suffice for many applications, some environments
environments demand other uncommon cryptographic properties. These demand other uncommon cryptographic properties. These often require
often require additional analysis and research. As the number of additional analysis and research. As the number of such properties
such properties and corresponding research papers grows, inevitable and corresponding research papers grows, inevitable misunderstandings
misunderstandings and confusion arise. It is a common situation when and confusion arise. This is a common situation when related but
related but formally different properties are named identically, or formally different properties are named identically or when some
some security properties only have folklore understanding and are not security properties only have folklore understanding and are not
formally defined. Consequently, the risk of misusing AEAD algorithms formally defined. Consequently, the risk of misusing AEAD algorithms
increases, potentially resulting in security issues. increases, potentially resulting in security issues.
1.2. Scope 1.2. Scope
In this document, in Section 4, we provide the list of the most In Section 4 of this document, we provide a list of the most common
common additional properties of AEAD algorithms. The properties are additional properties of AEAD algorithms. The properties are divided
divided into two categories, namely security properties (see into two categories, namely, security properties (see Section 4.3)
Section 4.3) and implementation properties (see Section 4.4). We and implementation properties (see Section 4.4). We provide a high-
provide a high-level definition for each property. For security level definition for each property. For security properties, we also
properties, we also reference an informative source where a formal reference an informative source where a formal game-based security
game-based security notion is defined; we do not consider security notion is defined; we do not consider security properties for which
properties for which no game-based formalization exists. When no game-based formalization exists. When possible, we offer
possible, we offer additional information: synonymous names, examples additional information: synonymous names, examples of algorithms that
of algorithms that provide the property, applications that might provide the property, applications that might necessitate the
necessitate such property from an AEAD algorithm, references for property from an AEAD algorithm, references for further reading, and
further reading, and additional notes containing information outside additional notes containing information outside these categories.
these categories.
The objective of this document is to enhance clarity and establish a The objective of this document is to enhance clarity and establish a
common language in the field. In particular, the primary application common language in the field. In particular, the primary application
of the document lies in the following two use cases within the IRTF of the document lies in the following two use cases within the
or the IETF documents development process: document development process in the IRTF and IETF:
* For an RFC or I-D that defines an AEAD algorithm, it is * For an RFC or I-D that defines an AEAD algorithm, it is
recommended to use the notations of Section 4 when listing recommended to use the notations in Section 4 when listing
additional properties of the algorithm. additional properties of the algorithm.
* For an RFC or I-D that defines a generic protocol based on an AEAD * 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 algorithm, it is recommended to use the notations in Section 4 if
any additional properties are required from the algorithm. any additional properties are required from the algorithm.
This document represents the consensus of the Crypto Forum Research This document represents the consensus of the Crypto Forum Research
Group (CFRG). This document is not an IETF product and is not a Group (CFRG). This document is not an IETF product and is not a
standard. standard.
2. Conventions Used in This Document 2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119][RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. AEAD Algorithms 3. AEAD Algorithms
This section gives a conventional definition of an AEAD algorithm This section gives a conventional definition of an AEAD algorithm
following [RFC5116]. following [RFC5116].
Definition: An AEAD algorithm is defined by two operations, which are Definition:
authenticated encryption and authenticated decryption: An AEAD algorithm is defined by two operations, which are
authenticated encryption and authenticated decryption:
* A deterministic operation of authenticated encryption has four * A deterministic operation of authenticated encryption has four
inputs, each a binary string: a secret key K of a fixed bit 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 length, a nonce N, associated data A, and a plaintext P. The
plaintext contains the data to be encrypted and authenticated, and plaintext contains the data to be encrypted and authenticated,
the associated data contains the data to be authenticated only. and the associated data contains the data to be authenticated
Each nonce value MUST be unique in every distinct invocation of only. Each nonce value MUST be unique in every distinct
the operation for any particular value of the key. The invocation of the operation for any particular value of the
authenticated encryption operation outputs a ciphertext C. key. The authenticated encryption operation outputs a
ciphertext C.
* A deterministic operation of authenticated decryption has four * A deterministic operation of authenticated decryption has four
inputs, each a binary string: a secret key K of a fixed bit 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 length, a nonce N, associated data A, and a ciphertext C. The
operation verifies the integrity of the ciphertext and associated operation verifies the integrity of the ciphertext and
data and decrypts the ciphertext. It returns a special symbol associated data and decrypts the ciphertext. It returns a
FAIL if the inputs are not authentic; otherwise, the operation special symbol FAIL if the inputs are not authentic; otherwise,
returns a plaintext P. the operation returns a plaintext P.
We note that specifications of AEAD algorithms that use We note that specifications of AEAD algorithms that use
authentication tags to ensure integrity MAY define it as an authentication tags to ensure integrity may define the authentication
independent output of the encryption operation and as an independent tag as an independent output of the encryption operation and an
input of the decryption operation. Throughout this document, by independent input of the decryption operation. Throughout this
default, we will consider the authentication tag as part of the document, by default, we consider the authentication tag as part of
ciphertext. the ciphertext.
For more details on the AEAD definition, please refer to [RFC5116]. For more details on the AEAD definition, please refer to [RFC5116].
Throughout this document, by default, we will consider nonce-based Throughout this document, by default, we consider nonce-based AEAD
AEAD algorithms, which have an interface from the definition above, algorithms, which have an interface as defined above, and we give no
and give no other restrictions on their structure. However, some other restrictions on their structure. However, some properties
properties considered in the document apply only to particular considered in the document apply only to particular classes of such
classes of such algorithms, like block cipher-based AEAD algorithms algorithms, like AEAD algorithms based on block ciphers (such
(such algorithms use block cipher as a building block). If that is algorithms use a block cipher as a building block). If that is the
the case, we explicitly point that out in the corresponding section. case, we explicitly point that out in the corresponding section.
4. AEAD Properties 4. AEAD Properties
4.1. Classification of additional AEAD Properties 4.1. Classification of Additional AEAD Properties
In this document, we employ a high-level classification of additional In this document, we employ a high-level classification of additional
properties. This classification aims to provide insight into how one properties. This classification aims to provide insight into how one
can benefit from each property. The additional properties in this can benefit from each property. The additional properties are
section are categorized into one of these two groups: categorized into one of these two groups:
* Security properties: We classify a property as a security property * Security properties: We classify a property as a security property
if it either takes into account new threats or extends adversarial if it either takes into account new threats or extends adversarial
capabilities, in addition to those posed by the typical nonce- capabilities, in addition to those posed by the typical nonce-
respecting adversary whose goal is to compromise confidentiality respecting adversary whose goal is to compromise confidentiality
or data integrity. or data integrity.
* Implementation properties: We classify a property as an * Implementation properties: We classify a property as an
implementation property if it enables more efficient implementation property if it enables more efficient
implementations of the AEAD algorithm in specific cases or implementations of the AEAD algorithm in specific cases or
environments. environments.
We note that some additional properties of AEAD algorithms found in We note that some additional properties of AEAD algorithms found in
the literature could not be allocated to either of these two groups. the literature could not be allocated to either of these two groups.
The observation is that such properties require an extension of the The observation is that such properties require an extension of the
conventional AEAD interface. We refer to these properties as conventional AEAD interface. We refer to these properties as
'additional functionality properties' and define the corresponding "additional functionality properties" and define the corresponding
group as follows: group as follows:
* Additional functionality properties: We classify a property as an * Additional functionality properties: We classify a property as an
additional functionality property if it introduces new features in additional functionality property if it introduces new features in
addition to the standard authenticated encryption with associated addition to the standard AEAD.
data.
With the extension of the conventional AEAD interface, each With the extension of the conventional AEAD interface, each
additional functionality property defines a new class of additional functionality property defines a new class of
cryptographic algorithms. Consequently, the basic threats and cryptographic algorithms. Consequently, the basic threats and
adversarial capabilities must be redefined for each class. As a adversarial capabilities must be redefined for each class. As a
result, additional functionality properties consider the basic result, additional functionality properties consider the basic
threats and adversarial capabilities for their class of algorithms, threats and adversarial capabilities for their class of algorithms,
in contrast to security properties, which consider the extended ones. in contrast to security properties, which consider the extended ones.
For this reason, we do not focus on additional functionality For this reason, we do not focus on additional functionality
properties in this document. However, for the sake of completeness, properties in this document. However, for the sake of completeness,
in Appendix A, we briefly present two classes of AEAD algorithms with in Appendix A, we briefly present two classes of AEAD algorithms with
additional functionality. additional functionality.
4.2. Conventional Properties 4.2. Conventional Properties
In this section, we recall the conventional properties of an AEAD In this section, we recall the conventional properties of an AEAD
algorithm. Active nonce-respecting adversaries in a single-key algorithm. Active nonce-respecting adversaries in a single-key
setting are considered. setting are considered.
We say that an AEAD algorithm provides security if it provides We say that an AEAD algorithm provides security if it provides the
conventional properties listed in this section. conventional properties listed in this section.
4.2.1. Confidentiality 4.2.1. Confidentiality
Definition: An AEAD algorithm guarantees that the plaintext is not Definition:
available to an active, nonce-respecting adversary. 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]). Security notions:
IND-CCA [BN08] (or IND-CCA2 [S04])
Synonyms: Message privacy. Synonyms:
Message privacy
Notes: Confidentiality against passive adversaries can also be Notes:
considered. The corresponding security notion is IND-CPA Confidentiality against passive adversaries can also be
[BN2000][R02]. considered. The corresponding security notion is IND-CPA [BN08]
[R02].
Further reading: [R02], [BN2000], [S04]. Further reading:
[R02], [BN08], [S04]
4.2.2. Data Integrity 4.2.2. Data Integrity
Definition: An AEAD algorithm allows one to ensure that the Definition:
ciphertext and the associated data have not been changed or forged by An AEAD algorithm allows one to ensure that the ciphertext and the
an active, nonce-respecting adversary. associated data have not been changed or forged by an active,
nonce-respecting adversary.
Security notion: IND-CTXT [BN2000] (or AUTH [R02]). Security notions:
INT-CTXT [BN08] (or AUTH [R02])
Synonyms: Message authentication, authenticity. Synonyms:
Message authentication, authenticity
Further reading: [R02], [BN2000], [S04]. Further reading:
[R02], [BN08], [S04]
4.2.3. Authenticated Encryption Security 4.2.3. Authenticated Encryption Security
Definition: An AEAD algorithm provides confidentiality and data Definition:
integrity against active, nonce-respecting adversaries. An AEAD algorithm provides confidentiality and data integrity
against active, nonce-respecting adversaries.
Security notion: IND-CPA and IND-CTXT [BN2000][R02] (or equivalently Security notions:
IND-CCA3 [S04]). IND-CPA and INT-CTXT [BN08] [R02] (or equivalently, IND-CCA3
[S04])
Notes: Please refer to [I-D.irtf-cfrg-aead-limits] for usage limits Notes:
on modern AEAD algorithms used in IETF protocols. Please refer to [AEAD-LIMITS] for usage limits on modern AEAD
algorithms used in IETF protocols.
Further reading: [R02], [BN2000], [S04]. Further reading:
[R02], [BN08], [S04]
4.3. Security Properties 4.3. Security Properties
4.3.1. Blockwise Security 4.3.1. Blockwise Security
Definition: An AEAD algorithm provides security even if an adversary Definition:
can adaptively choose the next part of the plaintext depending on An AEAD algorithm provides security even if an adversary can
already computed ciphertext parts during an encryption operation. 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 Security notions:
adversaries, B-INT-CTXT for integrity [EV16]; OAE1 [HRRV15] (a D-LORS-BCPA for confidentiality against passive adversaries, B-
stronger notion; originally OAE (Online Authenticated Encryption) in INT-CTXT for integrity [EV17]; OAE1 [HRRV15] (a stronger notion;
[FFL12]). originally OAE (Online Authenticated Encryption) in [FFL12])
Examples: Deoxys [JNPS21], SAEF [ABV21]. Examples:
Deoxys [JNPS21], SAEF [ABV21]
Notes: Blockwise security is highly relevant for streamable AEAD Notes:
algorithms (see Section 4.4.8). The OAE1 security notion [HRRV15], Blockwise security is highly relevant for streamable AEAD
and the OAE2 notion [HRRV15] are tailored for streamable AEAD algorithms (see Section 4.4.8). The OAE1 security notion [HRRV15]
algorithms. OAE1 was first defined in [FFL12] under the name OAE; and the OAE2 notion [HRRV15] are tailored for streamable AEAD
however, it contained a glitch, and the reformulated definition was algorithms. OAE1 was first defined in [FFL12] under the name OAE;
presented in [HRRV15]. Blockwise security follows from security in however, it contained a glitch, and the reformulated definition
the OAE notion [EV16]. For a discussion on security notions for was presented in [HRRV15]. Blockwise security follows from
streamable AEAD algorithms see [HRRV15]. security in the OAE notion [EV17]. For a discussion on security
notions for streamable AEAD algorithms, see [HRRV15].
Applications: Real-time streaming protocols, encryption on resource- Applications:
constrained devices. Real-time streaming protocols, encryption on resource-constrained
devices
Further reading: [EV16], [JMV2002], [FJMV2004], [HRRV15]. Further reading:
[EV17], [JMV2002], [FJMV2004], [HRRV15]
4.3.2. Full Commitment 4.3.2. Full Commitment
Definition: An AEAD algorithm guarantees that it is hard to find two Definition:
or more different tuples of the key, nonce, associated data, and An AEAD algorithm guarantees that it is hard to find two or more
plaintext such that they encrypt to the same ciphertext. In other different tuples of the key, nonce, associated data, and plaintext
words, an AEAD scheme guarantees that a ciphertext is a commitment to such that they encrypt to the same ciphertext. In other words, an
all inputs of an authenticated encryption operation. 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 Security notions:
setting (see the notes below) [MLGR23]. CMT-4 [BH22], generalized CMT for a restricted setting (see the
notes below) [MLGR23]
Examples: Ascon [DEMS21a][DEMS21b][YSS23], full committing versions Examples:
of GCM and GCM-SIV [BH22], generic constructions [BH22][CR22]. Ascon [DEMS21a] [DEMS21b] [YSS23], full committing versions of
Galois/Counter Mode (GCM) and GCM-SIV [BH22], generic
constructions [BH22] and [CR22]
Notes: Full commitment can be considered in a weaker setting, where Notes:
certain restrictions on the tuples produced by an adversary are Full commitment can be considered in a weaker setting, where
imposed [MLGR23]. For instance, an adversary must find tuples that certain restrictions on the tuples produced by an adversary are
all share the same associated data value. In such cases, an AEAD imposed [MLGR23]. For instance, an adversary must find tuples
algorithm is said to provide full commitment in a restricted setting. that all share the same associated data value. In such cases, an
The imposed restrictions MUST be listed. AEAD algorithm is said to provide full commitment in a restricted
setting. The imposed restrictions MUST be listed.
Applications: Message franking [GLR17]. Applications:
Message franking [GLR17]
Further reading: [BH22], [CR22], [MLGR23]. Further reading:
[BH22], [CR22], [MLGR23]
4.3.3. Key Commitment 4.3.3. Key Commitment
Definition: An AEAD algorithm guarantees that it is hard to find two Definition:
or more different keys and the same number of potentially equal An AEAD algorithm guarantees that it is hard to find two or more
triples of nonce, associated data, and plaintext such that they different keys and the same number of potentially equal triples of
encrypt to the same ciphertext under corresponding keys. In other nonce, associated data, and plaintext such that they encrypt to
words, an AEAD scheme guarantees that a ciphertext is a commitment to the same ciphertext under corresponding keys. In other words, an
the key used for an authenticated encryption operation. AEAD scheme guarantees that a ciphertext is a commitment to the
key used for an authenticated encryption operation.
Security notion: CMT-1 [BH22]. Security notions:
CMT-1 [BH22]
Synonyms: Key-robustness, key collision resistance. Synonyms:
Key robustness, key collision resistance
Examples: Ascon [DEMS21a][DEMS21b][YSS23], generic constructions from Examples:
[BH22] [CR22]. Ascon [DEMS21a] [DEMS21b] [YSS23], generic constructions from
[BH22] and [CR22]
Notes: Key commitment follows from full commitment. Full commitment Notes:
does not follow from key commitment [BH22]. Key commitment follows from full commitment. Full commitment does
not follow from key commitment [BH22].
Applications: Password-Authenticated Key Exchange, password-based Applications:
encryption [LGR21], key rotation, envelope encryption [ADGKLS22]. Password-Authenticated Key Exchange, password-based encryption
[LGR21], key rotation, envelope encryption [ADGKLS22]
Further reading: [BH22],[CR22], [FOR17], [LGR21], [GLR17]. Further reading:
[BH22], [CR22], [FOR17], [LGR21], [GLR17]
4.3.4. Leakage Resistance 4.3.4. Leakage Resistance
Definition: An AEAD algorithm provides security even if some Definition:
additional information about computations of an encryption (and An AEAD algorithm provides security even if some additional
possibly decryption) operation is obtained via side-channel leakages. 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 Security notions:
decryption) for integrity, CCAL1 [GPPS19] (CCAmL2 [GPPS19] with CIL1 [GPPS19] (CIML2 [BPPS17] with leakages in decryption) for
leakages in decryption) for Authenticated Encryption security. integrity, CCAL1 [GPPS19] (CCAmL2 [GPPS19] with leakages in
decryption) for authenticated encryption security
Examples: Ascon [DEMS21a][DEMS21b] (security under CIML2 and CCAL1 Examples:
notions [B20]), TEDT [GPPS19]. Ascon [DEMS21a] [DEMS21b] (security under CIML2 and CCAL1 notions
[B20]), TEDT [GPPS19]
Notes: Leakages during AEAD operation executions are implementation- Notes:
dependent. It is possible to implement symmetric algorithms in a way Leakages during AEAD operation executions are implementation-
that every possible physical leakage is entirely independent of the dependent. It is possible to implement symmetric algorithms in a
secret inputs of the algorithm (for example, with a masking technique way that every possible physical leakage is entirely independent
[CJRR99]), meaning the adversary doesn't gain any additional of the secret inputs of the algorithm (for example, with a masking
information about the algorithm's computation via side-channel technique [CJRR99]), meaning the adversary doesn't gain any
leakages. We say that an AEAD algorithm doesn't provide leakage additional information about the algorithm's computation via side-
resistance if it can achieve leakage resistance only with such an channel leakages. We say that an AEAD algorithm doesn't provide
implementation. Leakage-resistant AEAD algorithms aim to place as leakage resistance if it can only achieve leakage resistance with
mild requirements on implementation as possible to achieve leakage such an implementation. Leakage-resistant AEAD algorithms aim to
resistance. These requirements SHOULD be listed. 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 Confidentiality of plaintext in the presence of leakages in the
encryption operation is unachievable if an adversary can repeat the encryption operation is unachievable if an adversary can repeat
nonce used to encrypt the plaintext in other encryption queries. the nonce used to encrypt the plaintext in other encryption
Confidentiality can be achieved only for plaintexts encrypted with queries. Confidentiality can be achieved only for plaintexts
fresh nonces (analogously to nonce-misuse resilience, see encrypted with fresh nonces (analogously to nonce-misuse
Section 4.3.7). For further discussions, see [GPPS19] and [B20]. resilience; see Section 4.3.7). For further discussions, see
[GPPS19] and [B20].
For primitive-based AEAD algorithms, key evolution (internal re- For primitive-based AEAD algorithms, key evolution (internal re-
keying [RFC8645]) can contribute to achieving leakage resistance with keying [RFC8645]) can contribute to achieving leakage resistance
leakages in encryption. Confidentiality in the presence of with leakages in encryption. Confidentiality in the presence of
decryption leakages can be achieved by two-pass AEAD algorithms with decryption leakages can be achieved by two-pass AEAD algorithms
key evolution, which compute independent ephemeral key values for with key evolution, which compute independent ephemeral key values
encryption and tag generation, where the computation of these keys is for encryption and tag generation, where the computation of these
implemented without any leakages. For more discussions on achieving keys is implemented without any leakages. For more discussion on
leakage resistance see [B20]. achieving leakage resistance, see [B20].
A well-known weaker property, Leakage Resilience, introduced in Leakage Resilience, a well-known weaker property introduced in
[BMOS17], can also be considered. However, this document makes a [BMOS17], can also be considered. However, following the
conscious choice to focus on the stronger Leakage Resistance, framework established in [GPPS19] and [B20], this document makes a
following the framework established in [GPPS19], [B20], for its conscious choice to focus on the stronger Leakage Resistance for
enhanced practicality and comprehensiveness. its enhanced practicality and comprehensiveness.
Applications: Encryption on smart cards, Internet-of-things devices, Applications:
or other constrained devices. Encryption on smart cards, Internet-of-Things devices, or other
constrained devices
Further reading: [GPPS19], [B20], [BPPS17], [BMOS17]. Further reading:
[GPPS19], [B20], [BPPS17], [BMOS17]
4.3.5. Multi-User Security 4.3.5. Multi-user Security
Definition: An AEAD algorithm security degrades slower than linearly Definition:
with an increase in the number of users. The security of an AEAD algorithm degrades slower than linearly
with an increase in the number of users.
Security notion: mu-ind [BT16]. Security notions:
mu-ind [BT16]
Examples: AES-GCM [D07], ChaCha20-Poly1305 [RFC8439], AES-GCM-SIV Examples:
[RFC8452], AEGIS [I-D.irtf-cfrg-aegis-aead]. AES-GCM [D07], ChaCha20-Poly1305 [RFC8439], AES-GCM-SIV [RFC8452],
AEGIS [AEGIS-AEAD]
Notes: It holds that for any AEAD algorithm security degrades no Notes:
worse than linearly with an increase in the number of users [BT16]. For any AEAD algorithm, security degrades no worse than linearly
However, for some applications with a significant number of users, with an increase in the number of users [BT16]. However, for some
better multi-user guarantees are required. For example, in the TLS applications with a significant number of users, better multi-user
1.3 protocol, to address this issue, AEAD algorithms are used with a guarantees are required. For example, in the TLS 1.3 protocol,
randomized nonce (deterministically derived from a traffic secret and AEAD algorithms are used with a randomized nonce
a sequence number). Using nonce randomization in block cipher (deterministically derived from a traffic secret and a sequence
counter-based AEAD modes can contribute to multi-user security number) to address this issue. Using nonce randomization in block
[BT16]. Multi-user usage limits for AES-GCM and ChaCha20-Poly1305 cipher counter-based AEAD modes can contribute to multi-user
are provided in [I-D.irtf-cfrg-aead-limits]. 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 A weaker security notion, multi-user key recovery, is also
and thoroughly studied in [BT16]. While this document focuses on introduced and thoroughly studied in [BT16]. While this document
indistinguishability for security notions, key recovery might be focuses on indistinguishability for security notions, key recovery
relevant and valuable to study alongside indistinguishability. might be relevant and valuable to study alongside
indistinguishability.
Applications: Data transmission layer of secure communication Applications:
protocols (e.g., TLS, IPSec, SRTP, etc.) Data transmission layer of secure communication protocols (e.g.,
TLS, IPsec, the Secure Real-time Transport Protocol (SRTP), etc.)
Further reading: [BT16], [HTT18], [LMP17], [DGGP21], [BHT18]. Further reading:
[BT16], [HTT18], [LMP17], [DGGP21], [BHT18]
4.3.6. Nonce-Hiding 4.3.6. Nonce Hiding
Definition: An AEAD algorithm provides confidentiality for the nonce Definition:
value used to encrypt plaintext. The algorithm includes information An AEAD algorithm provides confidentiality for the nonce value
about the nonce in the ciphertext and doesn't require the nonce as used to encrypt plaintext. The algorithm includes information
input for the decryption operation. about the nonce in the ciphertext and doesn't require the nonce as
input for the decryption operation.
Security notion: AE2 [BNT19]. Security notions:
AE2 [BNT19]
Examples: Hide-Nonce (HN) transforms [BNT19]. Examples:
Hide-Nonce (HN) transforms [BNT19]
Notes: As discussed in [BNT19], adversary-visible nonces might Notes:
compromise message and user privacy, similar to the way any metadata As discussed in [BNT19], adversary-visible nonces might compromise
might do. As pointed out in [B13], even using a counter as a nonce message and user privacy, similar to the way any metadata might.
value might compromise privacy. Designing a privacy-preserving way As pointed out in [B13], even using a counter as a nonce value
to manage nonces might be a challenging problem for an application. 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- Applications:
band' nonce communication. Any application that can't rely on a secure "out-of-band" nonce
communication
Further reading: [BNT19]. Further reading:
[BNT19]
4.3.7. Nonce Misuse 4.3.7. Nonce Misuse
Definition: An AEAD algorithm provides security (resilience or Definition:
resistance) even if an adversary can repeat nonces in its encryption An AEAD algorithm provides security (resilience or resistance)
queries. Nonce misuse resilience and resistance are defined as even if an adversary can repeat nonces in its encryption queries.
follows: Nonce misuse resilience and resistance are defined as follows:
* Nonce misuse resilience: Security is provided for messages Nonce misuse resilience: Security is provided for messages
encrypted with non-repeated (fresh) nonces (correctly encrypted encrypted with non-repeated (fresh) nonces (correctly encrypted
messages). messages).
Security notion: CPA resilience (confidentiality), authenticity Security notions:
resilience (integrity), CCA resilience (authenticated encryption) Chosen-Plaintext Attack (CPA) resilience (confidentiality),
[ADL17]. authenticity resilience (integrity), Chosen-Ciphertext
Attack (CCA) resilience (authenticated encryption) [ADL17]
Examples: ChaCha20-Poly1305 [RFC8439], AES-GCM [D07] (only Examples:
confidentiality). ChaCha20-Poly1305 [RFC8439], AES-GCM [D07] (only
confidentiality)
* Nonce misuse resistance: Security is provided for all messages Nonce misuse resistance: Security is provided for all messages
that were not encrypted with the same nonce value more than once. that were not encrypted with the same nonce value more than
once.
Security notion: MRAE [RS06]. Security notions:
MRAE [RS06]
Examples: AES-GCM-SIV [RFC8452], Deoxys-II [JNPS21]. Examples:
AES-GCM-SIV [RFC8452], Deoxys-II [JNPS21]
Notes: SIV construction [RS06] is a generic construction that Notes:
provides nonce misuse resistance. Synthetic Initialization Vector (SIV) construction [RS06] is
a generic construction that provides nonce misuse
resistance.
Notes: Nonce misuse resilience follows from nonce misuse resistance. Notes:
Nonce misuse resistance does not follow from nonce misuse resilience. 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 Applications:
guaranteed, security against fault-injection attacks and Any application where nonce uniqueness can't be guaranteed,
malfunctions, processes parallelization, full disk encryption. security against fault-injection attacks and malfunctions,
processes parallelization, full disk encryption
Further reading: [RS06], [ADL17]. Further reading:
[RS06], [ADL17], [IIM25]
4.3.8. Quantum Security 4.3.8. Quantum Security
Definition: An AEAD algorithm provides security (in a Q1 or Q2 model) Definition:
against a quantum adversary. Q1 and Q2 models are defined as An AEAD algorithm provides security (in a Q1 or Q2 model) against
follows: a quantum adversary. Q1 and Q2 models are defined as follows:
* Q1 model: An adversary has access to local quantum computational Q1 model: An adversary has access to local quantum computational
power. It has classical access to encryption and decryption power. It has classical access to encryption and decryption
oracles. oracles.
Synonyms: Post-quantum security. Synonyms:
Post-quantum security
Examples: AES-GCM [D07], ChaCha20-Poly1305 [RFC8439], OCB Examples:
[RFC7253], MGM [RFC9058], AES-GCM-SIV [RFC8452], AEGIS AES-GCM [D07], ChaCha20-Poly1305 [RFC8439], OCB [RFC7253],
[I-D.irtf-cfrg-aegis-aead]. Multilinear Galois Mode (MGM) [RFC9058], AES-GCM-SIV
[RFC8452], AEGIS [AEGIS-AEAD]
* Q2 model: An adversary has access to local quantum computational Q2 model: An adversary has access to local quantum computational
power. It has quantum access to encryption and decryption power. It has quantum access to encryption and decryption
oracles, i.e., it can query encryption and decryption oracles with oracles, i.e., it can query encryption and decryption oracles
quantum superpositions of inputs to receive quantum superpositions with quantum superpositions of inputs to receive quantum
of the outputs. superpositions of the outputs.
Synonyms: Superposition-based quantum security. Synonyms:
Superposition-based quantum security
Examples: QCB [BBCLNSS21]. Examples:
QCB [BBCLNSS21]
Notes: Most symmetric cryptographic algorithms that are secure in the Notes:
classical model provide quantum security in the Q1 model, i.e., they Most symmetric cryptographic algorithms that are secure in the
are post-quantum secure. Security in the Q1 setting corresponds to classical model provide quantum security in the Q1 model, i.e.,
security against "harvest now, decrypt later" attacks. Security in they are post-quantum secure. Security in the Q1 setting
Q1 follows from security in Q2, the converse does not hold. For corresponds to security against "harvest now, decrypt later"
discussions on the relevance of the Q2 model please see [G17]. 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]. Further reading:
[KLLNP16], [BBCLNSS21], [G17]
4.3.9. Reforgeability Resilience 4.3.9. Reforgeability Resilience
Definition: An AEAD algorithm guarantees that once a successful Definition:
forgery for the algorithm has been found, it is still hard to find An AEAD algorithm guarantees that once a successful forgery for
any subsequent forgery. the algorithm has been found, it is still hard to find any
subsequent forgery.
Security notion: j-Int-CTXT [FLLW17]. Security notions:
j-Int-CTXT [FLLW17]
Examples: Deoxys [JNPS21], AEGIS [I-D.irtf-cfrg-aegis-aead], Ascon Examples:
[DEMS21a][DEMS21b]. Deoxys [JNPS21], AEGIS [AEGIS-AEAD], Ascon [DEMS21a] [DEMS21b]
Applications: VoIP, real-time streaming in a lightweight setting, Applications:
applications that require small ciphertext expansion (i.e., short Voice over IP (VoIP), real-time streaming in a lightweight
tags). setting, applications that require small ciphertext expansion
(i.e., short tags)
Further reading: [BC09], [FLLW17]. Further reading:
[BC09], [FLLW17]
4.3.10. Release of Unverified Plaintext (RUP) Integrity 4.3.10. Release of Unverified Plaintext (RUP) Integrity
Definition: An AEAD algorithm provides data integrity even if Definition:
plaintext is released for every ciphertext, including those with An AEAD algorithm provides data integrity even if plaintext is
failed integrity verification. released for every ciphertext, including those with failed
integrity verification.
Security notion: INT-RUP [A14]. Security notions:
INT-RUP [A14]
Examples: GCM-RUP [ADL17]. Examples:
GCM [IIM25], GCM-RUP [ADL17]
Applications: Decryption with limited memory [FJMV2004], real-time Applications:
streaming protocols. Decryption with limited memory [FJMV2004], real-time streaming
protocols
Notes: In [ADL17] a generic approach to achieve INT-RUP security is Notes:
introduced. In [ADL17], a generic approach to achieve INT-RUP security is
introduced.
In the provided definition, we only consider integrity in the RUP In the provided definition, we only consider integrity in the RUP
setting, since confidentiality, in the usual sense, is unachievable setting, since confidentiality, in the usual sense, is
under RUP. In [A14], the notion of 'Plaintext Awareness' is unachievable under RUP. In [A14], the notion of "Plaintext
introduced, capturing the best possible confidentiality under RUP in Awareness" is introduced, capturing the best possible
the following sense: 'The adversary cannot gain any additional confidentiality under RUP in the following sense: "the adversary
knowledge about the plaintext from decryption queries beyond what it cannot gain any additional knowledge about the plaintext from
can derive from encryption queries'. decryption queries besides what it can derive from encryption
queries".
Further reading: [A14], [ADL17]. Further reading:
[A14], [ADL17], [IIM25]
4.4. Implementation Properties 4.4. Implementation Properties
4.4.1. Hardware efficient 4.4.1. Hardware Efficient
Definition: An AEAD algorithm ensures optimal performance when Definition:
operating on hardware that complies with the specified requirements. 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. Notes:
Certain algorithms are tailored to minimize the area of dedicated Various classes of hardware may be taken into consideration.
hardware implementations, while others are intended to capitalize on Certain algorithms are tailored to minimize the area of dedicated
general-purpose CPUs, with or without specific instruction sets. It hardware implementations, while others are intended to capitalize
is RECOMMENDED to specify the minimum platform requirements for the on general-purpose CPUs, with or without specific instruction
AEAD to fulfill its intended purpose, as well as to match its sets. It is RECOMMENDED to specify the minimum platform
performance and security claims. requirements for the AEAD to fulfill its intended purpose, as well
as to match its performance and security claims.
4.4.2. Inverse-Free 4.4.2. Inverse-Free
Definition: An AEAD algorithm based on a given primitive can be Definition:
implemented without invoking the inverse of that primitive. An AEAD algorithm based on a given primitive can be implemented
without invoking the inverse of that primitive.
Examples: AES-GCM [D07], ChaCha20-Poly1305 [RFC8439], OCB [RFC7253], Examples:
MGM [RFC9058], AEGIS [I-D.irtf-cfrg-aegis-aead]. AES-GCM [D07], ChaCha20-Poly1305 [RFC8439], MGM [RFC9058], AEGIS
[AEGIS-AEAD]
Notes: In a sponge-based AEAD algorithm, an underlying permutation is Notes:
viewed as a primitive. In a sponge-based AEAD algorithm, an underlying permutation is
viewed as a primitive.
4.4.3. Lightweight 4.4.3. Lightweight
Definition: An AEAD algorithm can be efficiently and securely Definition:
implemented on resource-constrained devices. In particular, it meets An AEAD algorithm can be efficiently and securely implemented on
the criteria required in the NIST Lightweight Cryptography resource-constrained devices. In particular, it meets the
competition [MBTM17]. criteria required in the NIST Lightweight Cryptography competition
[MBTM17].
Examples: OCB [RFC7253], Ascon [DEMS21a][DEMS21b]. Examples:
OCB [RFC7253], Ascon [DEMS21a] [DEMS21b]
Further reading: [MBTM17]. Further reading:
[MBTM17]
4.4.4. Parallelizable 4.4.4. Parallelizable
Definition: An AEAD algorithm can fully exploit the parallel Definition:
computation infrastructure. In other words, a parallelizable AEAD An AEAD algorithm can fully exploit the parallel computation
algorithm allows for the computation of ciphertext segments infrastructure. In other words, a parallelizable AEAD algorithm
(plaintext segments for decryption) in parallel, meaning that allows for the computation of ciphertext segments (plaintext
ciphertext segments are computed independently. segments for decryption) in parallel, meaning that ciphertext
segments are computed independently.
Synonyms: Pipelineable. Synonyms:
Pipelineable
Examples: AES-GCM [D07], ChaCha20-Poly1305 [RFC8439], OCB [RFC7253], Examples:
MGM [RFC9058], AEGIS [I-D.irtf-cfrg-aegis-aead]. AES-GCM [D07], ChaCha20-Poly1305 [RFC8439], OCB [RFC7253], MGM
[RFC9058], AEGIS [AEGIS-AEAD]
Further reading: [C20]. Further reading:
[C20]
4.4.5. Setup-Free 4.4.5. Setup-Free
Definition: An AEAD algorithm's operations can be implemented in a Definition:
way that using a new key incurs either no overhead or negligible An AEAD algorithm's operations can be implemented in a way that
overhead compared to the reuse of a previous key. Overhead may using a new key incurs either no overhead or negligible overhead
involve additional computations or increased storage space, such as compared to the reuse of a previous key. Overhead may involve
precomputing a key schedule for a block cipher. additional computations or increased storage space, such as
precomputing a key schedule for a block cipher.
Examples: ChaCha20-Poly1305 [RFC8439], AEGIS Examples:
[I-D.irtf-cfrg-aegis-aead], Ascon [DEMS21a][DEMS21b]. ChaCha20-Poly1305 [RFC8439], AEGIS [AEGIS-AEAD], Ascon [DEMS21a]
[DEMS21b]
4.4.6. Single Pass 4.4.6. Single Pass
Definition: An AEAD algorithm encryption (decryption) operation can Definition:
be implemented with a single pass over the plaintext (ciphertext). 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], Examples:
MGM [RFC9058], AEGIS [I-D.irtf-cfrg-aegis-aead]. AES-GCM [D07], ChaCha20-Poly1305 [RFC8439], OCB [RFC7253], MGM
[RFC9058], AEGIS [AEGIS-AEAD]
4.4.7. Static Associated Data Efficient 4.4.7. Static Associated Data Efficient
Definition: An AEAD algorithm allows pre-computation for static (or Definition:
repeating) associated data so that static associated data doesn't An AEAD algorithm allows precomputation for static (or repeating)
significantly contribute to the computational cost of encryption. 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]. Examples:
AES-GCM [D07], ChaCha20-Poly1305 [RFC8439], OCB [RFC7253]
4.4.8. Streamable 4.4.8. Streamable
Definition: An AEAD algorithm encryption (decryption) operation can Definition:
be implemented with constant memory usage and a single one-direction An AEAD algorithm encryption (decryption) operation can be
pass over the plaintext (ciphertext), writing out the result during implemented with constant memory usage and a single one-direction
that pass. pass over the plaintext (ciphertext), writing out the result
during that pass.
Synonyms: Online. Synonyms:
Online
Examples: AES-GCM [D07], ChaCha20-Poly1305 [RFC8439], OCB [RFC7253], Examples:
MGM [RFC9058], AEGIS [I-D.irtf-cfrg-aegis-aead], Ascon AES-GCM [D07], ChaCha20-Poly1305 [RFC8439], OCB [RFC7253], MGM
[DEMS21a][DEMS21b]. [RFC9058], AEGIS [AEGIS-AEAD], Ascon [DEMS21a] [DEMS21b]
Applications: Real-time streaming protocols, resource-constrained Applications:
devices. Real-time streaming protocols, resource-constrained devices
Notes: Blockwise security (see Section 4.3.1) and RUP integrity (see Notes:
Section 4.3.10) might be relevant security properties for streamable Blockwise security (see Section 4.3.1) and RUP integrity (see
AEAD algorithms in certain applications. Section 4.3.10) might be relevant security properties for
streamable AEAD algorithms in certain applications.
Further reading: [HRRV15], [FJMV2004]. Further reading:
[HRRV15], [FJMV2004]
5. Security Considerations 5. Security Considerations
This document gives high-level definitions of AEAD properties. For This document gives high-level definitions of AEAD properties. For
each security property, we provide an informational reference to a each security property, we provide an informational reference to a
game-based security notion (or security notions if there are separate game-based security notion (or security notions if there are separate
notions for integrity and confidentiality) that formalizes the notions for integrity and confidentiality) that formalizes the
property. We only consider game-based notions and security property. We only consider game-based notions and security
properties that can be formalized using this approach. However, properties that can be formalized using this approach. However,
there are different approaches to formalizing AEAD security, like the there are different approaches to formalizing AEAD security, like the
skipping to change at page 16, line 28 skipping to change at line 831
are given, with standardized AEAD algorithms preferred for commonly are given, with standardized AEAD algorithms preferred for commonly
encountered properties. However, for certain properties, only non- encountered properties. However, for certain properties, only non-
standardized algorithms exist. Implementing such algorithms requires standardized algorithms exist. Implementing such algorithms requires
careful consideration, and it is advised to contact the algorithm careful consideration, and it is advised to contact the algorithm
designers for reference implementations and implementation designers for reference implementations and implementation
guidelines. guidelines.
Every claimed security property of an AEAD algorithm MUST undergo Every claimed security property of an AEAD algorithm MUST undergo
security analysis within a relevant notion. It's RECOMMENDED to use security analysis within a relevant notion. It's RECOMMENDED to use
the security notions referenced in the document. If an alternative the security notions referenced in the document. If an alternative
notion is used, there MUST exist proof of equivalence or it SHOULD be notion is used, proof of equivalence MUST exist, or use of a non-
indicated that a non-equivalent notion is used. For security equivalent notion SHOULD be indicated. For security properties that
properties that extend adversarial capabilities, consideration of extend adversarial capabilities, consideration of integrity and
integrity and confidentiality separately may be relevant. If the confidentiality separately may be relevant. If the algorithm
algorithm provides only one of these, that SHOULD be indicated. provides only one of these, that SHOULD be indicated.
When specifying security requirements for an AEAD algorithm in an When specifying security requirements for an AEAD algorithm in an
application, it SHOULD be indicated, for every required security application, it SHOULD be indicated, for every required security
property, whether only integrity or confidentiality is necessary. property, whether only integrity or confidentiality is necessary.
Additionally, for each security property, it SHOULD be specified Additionally, for each security property, it SHOULD be specified
whether an analysis in an alternative security notion is required. whether an analysis in an alternative security notion is required.
We also note that some additional properties come with trade-offs in We also note that some additional properties come with trade-offs in
terms of classical security and efficiency, and may only be supported terms of classical security and efficiency, and they may only be
in non-standardized or modified AEAD algorithms. This immediately supported in non-standardized or modified AEAD algorithms. This
implies challenges in deployment and interoperability. In an immediately implies challenges in deployment and interoperability.
application, the requirements for additional AEAD properties SHOULD In an application, the requirements for additional AEAD properties
be highly motivated and justified, as should all trade-offs be SHOULD be highly motivated and justified, and all trade-offs should
carefully considered. be carefully considered.
6. IANA Considerations 6. IANA Considerations
This document has no IANA actions. This document has no IANA actions.
7. References 7. References
7.1. Normative References 7.1. Normative References
[D07] Dworkin, M., "Recommendation for Block Cipher Modes of [D07] Dworkin, M., "Recommendation for Block Cipher Modes of
Operation: Galois/Counter Mode (GCM) and GMAC", NIST Operation: Galois/Counter Mode (GCM) and GMAC", NIST
Special Publication 800-38D, DOI 10.6028/NIST.SP.800-38D, SP 800-38D, DOI 10.6028/NIST.SP.800-38D, 2007,
2007, <https://csrc.nist.gov/pubs/sp/800/38/d/final>. <https://csrc.nist.gov/pubs/sp/800/38/d/final>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
<https://www.rfc-editor.org/info/rfc5116>. <https://www.rfc-editor.org/info/rfc5116>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
7.2. Informative References 7.2. Informative References
[A14] Andreeva, E., Bogdanov, A., Luykx, A., Mennink, B., Mouha, [A14] Andreeva, E., Bogdanov, A., Luykx, A., Mennink, B., Mouha,
N., and K. Yasuda, "How to Securely Release Unverified N., and K. Yasuda, "How to Securely Release Unverified
Plaintext in Authenticated Encryption", Advances in Plaintext in Authenticated Encryption", Advances in
Cryptology – ASIACRYPT 2014. ASIACRYPT 2014. Lecture Notes Cryptology - ASIACRYPT 2014, Lecture Notes in Computer
in Computer Science, vol 8873. Springer, Berlin, Science, vol. 8873, pp. 105-125,
Heidelberg, DOI 10.1007/978-3-662-45611-8_6, 2014, DOI 10.1007/978-3-662-45611-8_6, 2014,
<https://doi.org/10.1007/978-3-662-45611-8_6>. <https://doi.org/10.1007/978-3-662-45611-8_6>.
[ABV21] Andreeva, E., Bhati, A.S., and D. Vizár, "Nonce-misuse [ABV21] Andreeva, E., Bhati, A.S., and D. Vizár, "Nonce-Misuse
security of the SAEF authenticated encryption mode", Security of the SAEF Authenticated Encryption Mode",
Selected Areas in Cryptography: 27th International Selected Areas in Cryptography (SAC 2020), Lecture Notes
Conference, Halifax, NS, Canada (Virtual Event), October in Computer Science, vol. 12804, pp. 512-534,
21-23, 2020, Revised Selected Papers 27. Springer
International Publishing, 2021,
DOI 10.1007/978-3-030-81652-0_20, 2021, DOI 10.1007/978-3-030-81652-0_20, 2021,
<https://doi.org/10.1007/978-3-030-81652-0_20>. <https://doi.org/10.1007/978-3-030-81652-0_20>.
[ADGKLS22] Albertini, A., Duong, T., Gueron, S., Kölbl, S., Luykx, [ADGKLS22] Albertini, A., Duong, T., Gueron, S., Kölbl, S., Luykx,
A., and S. Schmieg, "How to abuse and fix authenticated A., and S. Schmieg, "How to Abuse and Fix Authenticated
encryption without key commitment", 1st USENIX Security Encryption Without Key Commitment", 31st USENIX Security
Symposium (USENIX Security 22), pp. 3291-3308. 2022, 2022. Symposium (USENIX Security 22), pp. 3291-3308, 2022.
[ADL17] Ashur, T., Dunkelman, O., and A. Luykx, "Boosting [ADL17] Ashur, T., Dunkelman, O., and A. Luykx, "Boosting
Authenticated Encryption Robustness with Minimal Authenticated Encryption Robustness with Minimal
Modifications", Advances in Cryptology – CRYPTO 2017. Modifications", Advances in Cryptology - CRYPTO 2017,
CRYPTO 2017. Lecture Notes in Computer Science, vol 10403. Lecture Notes in Computer Science, vol. 10403, pp. 3-33,
Springer, Cham, DOI 10.1007/978-3-319-63697-9_1, 2017, DOI 10.1007/978-3-319-63697-9_1, 2017,
<https://doi.org/10.1007/978-3-319-63697-9_1>. <https://doi.org/10.1007/978-3-319-63697-9_1>.
[B13] Bernstein, D. J., "Re: secret message numbers", Message in [AEAD-LIMITS]
Google group on cryptographic competitions, October 2013., Günther, F., Thomson, M., and C. A. Wood, "Usage Limits on
2013, <https://groups.google.com/d/msg/crypto- AEAD Algorithms", Work in Progress, Internet-Draft, draft-
irtf-cfrg-aead-limits-10, 8 April 2025,
<https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-
aead-limits-10>.
[AEGIS-AEAD]
Denis, F. and S. Lucas, "The AEGIS Family of Authenticated
Encryption Algorithms", Work in Progress, Internet-Draft,
draft-irtf-cfrg-aegis-aead-16, 17 February 2025,
<https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-
aegis-aead-16>.
[B13] Bernstein, D. J., "Re: wondering the secret message
number", Message to the Cryptographic Competitions Google
Group, 2013, <https://groups.google.com/d/msg/crypto-
competitions/n5ECGwYr6Vk/bsEfPWqSAU4J>. competitions/n5ECGwYr6Vk/bsEfPWqSAU4J>.
[B20] Bellizia, D., Bronchain, O., Cassiers, G., Grosso, V., [B20] Bellizia, D., Bronchain, O., Cassiers, G., Grosso, V.,
Guo, C., Momin, C., Pereira, O., Peters, T., and FX. Guo, C., Momin, C., Pereira, O., Peters, T., and F.-X.
Standaert, "Mode-Level vs. Implementation-Level Physical Standaert, "Mode-Level vs. Implementation-Level Physical
Security in Symmetric Cryptography: A Practical Guide Security in Symmetric Cryptography: A Practical Guide
Through the Leakage-Resistance Jungle", Advances in Through the Leakage-Resistance Jungle", Advances in
Cryptology – CRYPTO 2020. CRYPTO 2020. Lecture Notes in Cryptology - CRYPTO 2020, Lecture Notes in Computer
Computer Science, vol 12170. Springer, Cham, Science, vol. 12170, pp. 369-400,
DOI 10.1007/978-3-030-56784-2_13, 2020, DOI 10.1007/978-3-030-56784-2_13, 2020,
<https://doi.org/10.1007/978-3-030-56784-2_13>. <https://doi.org/10.1007/978-3-030-56784-2_13>.
[BBCLNSS21] [BBCLNSS21]
Bhaumik, R., Bonnetain, X., Chailloux, A., Leurent, G., Bhaumik, R., Bonnetain, X., Chailloux, A., Leurent, G.,
Naya-Plasencia, M., Schrottenlohe, A., and Y. Seurin, Naya-Plasencia, M., Schrottenloher, A., and Y. Seurin,
"QCB: Efficient Quantum-Secure Authenticated Encryption", "QCB: Efficient Quantum-Secure Authenticated Encryption",
Advances in Cryptology – ASIACRYPT 2021. ASIACRYPT 2021. Advances in Cryptology - ASIACRYPT 2021, Lecture Notes in
Lecture Notes in Computer Science(), vol 13090. Springer, Computer Science, vol. 13090, pp. 668-698,
Cham., DOI 10.1007/978-3-030-92062-3_23, 2021, DOI 10.1007/978-3-030-92062-3_23, 2021,
<https://doi.org/10.1007/978-3-030-92062-3_23>. <https://doi.org/10.1007/978-3-030-92062-3_23>.
[BC09] Black, J. and M. Cochran, "MAC Reforgeability", Fast [BC09] Black, J. and M. Cochran, "MAC Reforgeability", Fast
Software Encryption. FSE 2009. Lecture Notes in Computer Software Encryption (FSE 2009), Lecture Notes in Computer
Science, vol 5665. Springer, Berlin, Heidelberg, Science, vol. 5665, pp. 345-362,
DOI 10.1007/978-3-642-03317-9_21, 2009, DOI 10.1007/978-3-642-03317-9_21, 2009,
<https://doi.org/10.1007/978-3-642-03317-9_21>. <https://doi.org/10.1007/978-3-642-03317-9_21>.
[BH22] Bellare, M. and V.T. Hoang, "Efficient schemes for [BH22] Bellare, M. and V.T. Hoang, "Efficient Schemes for
committing authenticated encryption", Advances in Committing Authenticated Encryption", Advances in
Cryptology – EUROCRYPT 2022. EUROCRYPT 2022. Lecture Notes Cryptology - EUROCRYPT 2022, Lecture Notes in Computer
in Computer Science, vol 13276. Springer, Cham., Science, vol. 13276, pp. 845-875,
DOI 10.1007/978-3-031-07085-3_29, 2022, DOI 10.1007/978-3-031-07085-3_29, 2022,
<https://doi.org/10.1007/978-3-031-07085-3_29>. <https://doi.org/10.1007/978-3-031-07085-3_29>.
[BHT18] Bose, P., Hoang, V.T., and S. Tessaro, "Revisiting AES- [BHT18] Bose, P., Hoang, V.T., and S. Tessaro, "Revisiting AES-
GCM-SIV: multi-user security, faster key derivation, and GCM-SIV: Multi-user Security, Faster Key Derivation, and
better bounds", Annual International Conference on the Better Bounds", Advances in Cryptology - EUROCRYPT 2018,
Theory and Applications of Cryptographic Techniques, pp. Lecture Notes in Computer Science, vol. 10820, pp.
468-499, DOI 10.1007/978-3-319-78381-9_18, 2018,
468-499. Cham: Springer International Publishing, 2018,
DOI 10.1007/978-3-319-78381-9_18, 2018,
<https://doi.org/10.1007/978-3-319-78381-9_18>. <https://doi.org/10.1007/978-3-319-78381-9_18>.
[BKY02] Buonanno, E., Katz, J., and M. Yung, "Incremental [BKY02] Buonanno, E., Katz, J., and M. Yung, "Incremental
Unforgeable Encryption", Fast Software Encryption. FSE Unforgeable Encryption", Fast Software Encryption (FSE
2001. Lecture Notes in Computer Science, vol 2355. 2001), Lecture Notes in Computer Science, vol. 2355, pp.
Springer, Berlin, Heidelberg, DOI 10.1007/3-540-45473-X_9, 109-124, DOI 10.1007/3-540-45473-X_9, 2002,
2002, <https://doi.org/10.1007/3-540-45473-X_9>. <https://doi.org/10.1007/3-540-45473-X_9>.
[BM18] Barbosa, M. and P. Farshim, "Indifferentiable [BM18] Barbosa, M. and P. Farshim, "Indifferentiable
authenticated encryption", Advances in Cryptology–CRYPTO Authenticated Encryption", Advances in Cryptology - CRYPTO
2018: 38th Annual International Cryptology Conference, 2018, Lecture Notes in Computer Science, vol. 10991, pp.
Santa Barbara, CA, USA, August 19–23, 2018, Proceedings, 187-220, DOI 10.1007/978-3-319-96884-1_7, 2018,
Part I 38, pp. 187-220. Springer International Publishing,
2018., DOI 10.1007/978-3-319-96884-1_7, 2018,
<https://doi.org/10.1007/978-3-319-96884-1_7>. <https://doi.org/10.1007/978-3-319-96884-1_7>.
[BMOS17] Barwell, G., Martin, D.P., Oswald, E., and M. Stam, [BMOS17] Barwell, G., Martin, D.P., Oswald, E., and M. Stam,
"Authenticated encryption in the face of protocol and side "Authenticated Encryption in the Face of Protocol and Side
channel leakage.", Advances in Cryptology – ASIACRYPT Channel Leakage", Advances in Cryptology - ASIACRYPT 2017,
2017. ASIACRYPT 2017. Lecture Notes in Computer Science, Lecture Notes in Computer Science, vol. 10624, pp.
vol 10624. Springer, Cham, 693-723, DOI 10.1007/978-3-319-70694-8_24, 2017,
DOI 10.1007/978-3-319-70694-8_24, 2017,
<https://doi.org/10.1007/978-3-319-70694-8_24>. <https://doi.org/10.1007/978-3-319-70694-8_24>.
[BN2000] Bellare, M. and C. Namprempre, "Authenticated Encryption: [BN08] Bellare, M. and C. Namprempre, "Authenticated Encryption:
Relations among Notions and Analysis of the Generic Relations among Notions and Analysis of the Generic
Composition Paradigm", Proceedings of ASIACRYPT 2000, Composition Paradigm", Journal of Cryptology, vol. 21, pp.
Springer-Verlag, LNCS 1976, pp. 531-545, 469-491, DOI 10.1007/s00145-008-9026-x, 2008,
DOI 10.1007/s00145-008-9026-x, 2000,
<https://doi.org/10.1007/s00145-008-9026-x>. <https://doi.org/10.1007/s00145-008-9026-x>.
[BNT19] Bellare, M., Ng, R., and B. Tackmann, "Nonces Are Noticed: [BNT19] Bellare, M., Ng, R., and B. Tackmann, "Nonces Are Noticed:
AEAD Revisited", Advances in Cryptology – CRYPTO 2019. AEAD Revisited", Advances in Cryptology - CRYPTO 2019,
CRYPTO 2019. Lecture Notes in Computer Science, vol 11692. Lecture Notes in Computer Science, vol. 11692, pp.
Springer, Cham, DOI 10.1007/978-3-030-26948-7_9, 2019, 235-265, DOI 10.1007/978-3-030-26948-7_9, 2019,
<https://doi.org/10.1007/978-3-030-26948-7_9>. <https://doi.org/10.1007/978-3-030-26948-7_9>.
[BPPS17] Berti, F., Pereira, O., Peters, T., and F.X. Standaert, [BPPS17] Berti, F., Pereira, O., Peters, T., and F.-X. Standaert,
"On leakage-resilient authenticated encryption with "On Leakage-Resilient Authenticated Encryption with
decryption leakages", IACR Transactions on Symmetric Decryption Leakages", IACR Transactions on Symmetric
Cryptology (2017): 271-293, Cryptology, vol. 2017, no. 3, pp. 271-293,
DOI 10.13154/tosc.v2017.i3.271-293, 2017, DOI 10.13154/tosc.v2017.i3.271-293, 2017,
<https://doi.org/10.13154/tosc.v2017.i3.271-293>. <https://doi.org/10.13154/tosc.v2017.i3.271-293>.
[BT16] Bellare, M. and B. Tackmann, "The Multi-User Security of [BT16] Bellare, M. and B. Tackmann, "The Multi-user Security of
Authenticated Encryption: AES-GCM in TLS 1.3", Advances in Authenticated Encryption: AES-GCM in TLS 1.3", Advances in
Cryptology – CRYPTO 2016. CRYPTO 2016. Lecture Notes in Cryptology - CRYPTO 2016, Lecture Notes in Computer
Computer Science, vol 9814. Springer, Berlin, Heidelberg, Science, vol. 9814, pp. 247-276,
DOI 10.1007/978-3-662-53018-4_10, 2016, DOI 10.1007/978-3-662-53018-4_10, 2016,
<https://doi.org/10.1007/978-3-662-53018-4_10>. <https://doi.org/10.1007/978-3-662-53018-4_10>.
[C20] Chakraborti, A., Datta, N., Jha, A., Mancillas-López, C., [C20] Chakraborti, A., Datta, N., Jha, A., Mancillas-López, C.,
Nandi, M., and Y. Sasaki, "INT-RUP Secure Lightweight Nandi, M., and Y. Sasaki, "INT-RUP Secure Lightweight
Parallel AE Modes", IACR Transactions on Symmetric Parallel AE Modes", IACR Transactions on Symmetric
Cryptology, 2019(4), 81–118, Cryptology, vol. 2019, no.4, pp. 81-118,
DOI 10.13154/tosc.v2019.i4.81-118, 2020, DOI 10.13154/tosc.v2019.i4.81-118, 2020,
<https://doi.org/10.13154/tosc.v2019.i4.81-118>. <https://doi.org/10.13154/tosc.v2019.i4.81-118>.
[CJRR99] Chari, S., Jutla, C.S., Rao, J.R., and P. Rohatgi, [CJRR99] Chari, S., Jutla, C.S., Rao, J.R., and P. Rohatgi,
"Towards sound approaches to counteract power-analysis "Towards Sound Approaches to Counteract Power-Analysis
attacks.", Advances in Cryptology—CRYPTO'99: 19th Annual Attacks", Advances in Cryptology - CRYPTO'99, Lecture
International Cryptology Conference Santa Barbara, Notes in Computer Science, vol. 1666, pp. 398-412,
California, USA, August 15–19, 1999 Proceedings 19, pp.
398-412. Springer Berlin Heidelberg, 1999.,
DOI 10.1007/3-540-48405-1_26, 1999, DOI 10.1007/3-540-48405-1_26, 1999,
<https://doi.org/10.1007/3-540-48405-1_26>. <https://doi.org/10.1007/3-540-48405-1_26>.
[CR22] Chan, J. and P. Rogaway, "On Committing Authenticated- [CR22] Chan, J. and P. Rogaway, "On Committing Authenticated-
Encryption", Computer Security – ESORICS 2022. ESORICS Encryption", Computer Security - ESORICS 2022, Lecture
2022. Lecture Notes in Computer Science, vol 13555. Notes in Computer Science, vol. 13555, pp. 275-294,
Springer, Cham., DOI 10.1007/978-3-031-17146-8_14, 2022, DOI 10.1007/978-3-031-17146-8_14, 2022,
<https://doi.org/10.1007/978-3-031-17146-8_14>. <https://doi.org/10.1007/978-3-031-17146-8_14>.
[DEMS21a] Dobraunig, C., Eichlseder, M., Mendel, F., and M. [DEMS21a] Dobraunig, C., Eichlseder, M., Mendel, F., and M.
Schläffer, "Ascon v1.2: Lightweight Authenticated Schläffer, "Ascon v1.2: Lightweight Authenticated
Encryption and Hashing", Journal of Cryptology 34 (2021): Encryption and Hashing", Journal of Cryptology, vol. 34,
1-42., DOI 10.1007/s00145-021-09398-9, 2021, no. 33, DOI 10.1007/s00145-021-09398-9, 2021,
<https://doi.org/10.1007/s00145-021-09398-9>. <https://doi.org/10.1007/s00145-021-09398-9>.
[DEMS21b] Dobraunig, C., Eichlseder, M., Mendel, F., and M. [DEMS21b] Dobraunig, C., Eichlseder, M., Mendel, F., and M.
Schläffer, "Ascon v1.2", Submission to the NIST LWC Schläffer, "Ascon v1.2", Submission to the NIST LWC
Competition, 2021. Competition, 2021.
[DGGP21] Degabriele, J.P., Govinden, J., Günther, F., and K. [DGGP21] Degabriele, J.P., Govinden, J., Günther, F., and K.
Paterson, "The security of ChaCha20-Poly1305 in the multi- Paterson, "The Security of ChaCha20-Poly1305 in the Multi-
user setting", In Proceedings of the 2021 ACM SIGSAC User Setting", Proceedings of the 2021 ACM SIGSAC
Conference on Computer and Communications Security, pp. Conference on Computer and Communications Security (CCS
1981-2003. 2021., DOI 10.1145/3460120.3484814, 2021, '21), pp. 1981-2003, DOI 10.1145/3460120.3484814, 2021,
<https://doi.org/10.1145/3460120.3484814>. <https://doi.org/10.1145/3460120.3484814>.
[EV16] Endignoux, G. and D. Vizár, "Linking Online Misuse- [EV17] Endignoux, G. and D. Vizár, "Linking Online Misuse-
Resistant Authenticated Encryption and Blockwise Attack Resistant Authenticated Encryption and Blockwise Attack
Models", IACR Transactions on Symmetric Cryptology, Models", IACR Transactions on Symmetric Cryptology, vol.
DOI 10.13154/TOSC.V2016.I2.125-144, 2016, 2016, no. 2, pp. 125-144,
DOI 10.13154/TOSC.V2016.I2.125-144, 2017,
<https://doi.org/10.13154/TOSC.V2016.I2.125-144>. <https://doi.org/10.13154/TOSC.V2016.I2.125-144>.
[FFL12] Fleischmann, E., Forler, C., and S. Lucks, "McOE: A family [FFL12] Fleischmann, E., Forler, C., and S. Lucks, "McOE: A Family
of almost foolproof on-line authenticated encryption of Almost Foolproof On-Line Authenticated Encryption
schemes", Fast Software Encryption: 19th International Schemes", Fast Software Encryption (FSE 2012), Lecture
Workshop, FSE 2012, Washington, DC, USA, March 19-21, Notes in Computer Science, vol. 7549, pp. 196-215,
2012. Revised Selected Papers. Springer Berlin Heidelberg, DOI 10.1007/978-3-642-34047-5_12, 2012,
2012, DOI 10.1007/978-3-642-34047-5_12, 2012,
<https://doi.org/10.1007/978-3-642-34047-5_12>. <https://doi.org/10.1007/978-3-642-34047-5_12>.
[FJMV2004] Fouque, PA., Joux, A., Martinet, G., and F. Valette, [FJMV2004] Fouque, P.-A., Joux, A., Martinet, G., and F. Valette,
"Authenticated On-Line Encryption", Selected Areas in "Authenticated On-Line Encryption", Selected Areas in
Cryptography. SAC 2003. Lecture Notes in Computer Science, Cryptography (SAC 2003), Lecture Notes in Computer
vol 3006. Springer, Berlin, Heidelberg., Science, vol. 3006, DOI 10.1007/978-3-540-24654-1_11,
DOI 10.1007/978-3-540-24654-1_11, 2004, 2004, <https://doi.org/10.1007/978-3-540-24654-1_11>.
<https://doi.org/10.1007/978-3-540-24654-1_11>.
[FLLW17] Forler, C., List, E., Lucks, S., and J. Wenzel, [FLLW17] Forler, C., List, E., Lucks, S., and J. Wenzel,
"Reforgeability of Authenticated Encryption Schemes", "Reforgeability of Authenticated Encryption Schemes",
Information Security and Privacy. ACISP 2017. Lecture Information Security and Privacy (ACISP 2017), Lecture
Notes in Computer Science, vol 10343. Springer, Cham, Notes in Computer Science, vol. 10343, pp. 19-37,
DOI 10.1007/978-3-319-59870-3_2, 2017, DOI 10.1007/978-3-319-59870-3_2, 2017,
<https://doi.org/10.1007/978-3-319-59870-3_2>. <https://doi.org/10.1007/978-3-319-59870-3_2>.
[FOR17] Farshim, P., Orlandi, C., and R. Rosie, "Security of [FOR17] Farshim, P., Orlandi, C., and R. Rosie, "Security of
Symmetric Primitives under Incorrect Usage of Keys", IACR Symmetric Primitives under Incorrect Usage of Keys", IACR
Transactions on Symmetric Cryptology, 2017(1), 449–473., Transactions on Symmetric Cryptology, vol. 2017, no. 1,
DOI 10.13154/tosc.v2017.i1.449-473, 2017, pp. 449-473, DOI 10.13154/tosc.v2017.i1.449-473, 2017,
<https://doi.org/10.13154/tosc.v2017.i1.449-473>. <https://doi.org/10.13154/tosc.v2017.i1.449-473>.
[G17] Gagliardoni, T., "Quantum Security of Cryptographic [G17] Gagliardoni, T., "Quantum Security of Cryptographic
Primitives", Ph.D. Thesis, Technische Universität Primitives", Ph.D. Thesis, Technische Universität
Darmstadt, 2017, Darmstadt, 2017,
<https://tuprints.ulb.tu-darmstadt.de/6019/>. <https://tuprints.ulb.tu-darmstadt.de/6019/>.
[GLR17] Grubbs, P., Lu, J., and T. Ristenpart, "Message Franking [GLR17] Grubbs, P., Lu, J., and T. Ristenpart, "Message Franking
via Committing Authenticated Encryption", Advances in via Committing Authenticated Encryption", Advances in
Cryptology – CRYPTO 2017. CRYPTO 2017. Lecture Notes in Cryptology - CRYPTO 2017, Lecture Notes in Computer
Computer Science, vol 10403. Springer, Cham, Science, vol. 10403, pp. 66-97,
DOI 10.1007/978-3-319-63697-9_3, 2017, DOI 10.1007/978-3-319-63697-9_3, 2017,
<https://doi.org/10.1007/978-3-319-63697-9_3>. <https://doi.org/10.1007/978-3-319-63697-9_3>.
[GPPS19] Guo, C., Pereira, O., Peters, T., and FX. Standaert, [GPPS19] Guo, C., Pereira, O., Peters, T., and F.-X. Standaert,
"Authenticated Encryption with Nonce Misuse and Physical "Authenticated Encryption with Nonce Misuse and Physical
Leakages: Definitions, Separation Results and Leveled Leakages: Definitions, Separation Results and First
Constructions", Progress in Cryptology - LATINCRYPT 2019. Construction", Progress in Cryptology - LATINCRYPT 2019,
LATINCRYPT 2019. Lecture Notes in Computer Science, vol Lecture Notes in Computer Science, vol. 11774, pp.
11774. Springer, Cham, DOI 10.1007/978-3-030-30530-7_8, 150-172, DOI 10.1007/978-3-030-30530-7_8, 2019,
2019, <https://doi.org/10.1007/978-3-030-30530-7_8>. <https://doi.org/10.1007/978-3-030-30530-7_8>.
[HKR2015] Hoang, VT., Krovetz, T., and P. Rogaway, "Robust [HKR2015] Hoang, V.T., Krovetz, T., and P. Rogaway, "Robust
Authenticated-Encryption AEZ and the Problem That It Authenticated-Encryption AEZ and the Problem That It
Solves", Advances in Cryptology -- EUROCRYPT 2015. Solves", Advances in Cryptology -- EUROCRYPT 2015, Lecture
EUROCRYPT 2015. Lecture Notes in Computer Science, vol Notes in Computer Science, vol. 9056, pp. 15-44,
9056. Springer, Berlin, Heidelberg.,
DOI 10.1007/978-3-662-46800-5_2, 2015, DOI 10.1007/978-3-662-46800-5_2, 2015,
<https://doi.org/10.1007/978-3-662-46800-5_2>. <https://doi.org/10.1007/978-3-662-46800-5_2>.
[HRRV15] Hoang, VT., Reyhanitabar, R., Rogaway, P., and D. Vizár, [HRRV15] Hoang, VT., Reyhanitabar, R., Rogaway, P., and D. Vizár,
"Online Authenticated-Encryption and its Nonce-Reuse "Online Authenticated-Encryption and its Nonce-Reuse
Misuse-Resistance", Advances in Cryptology -- CRYPTO 2015. Misuse-Resistance", Advances in Cryptology -- CRYPTO 2015,
CRYPTO 2015. Lecture Notes in Computer Science, vol 9215. Lecture Notes in Computer Science, vol. 9215, pp. 493-517,
Springer, Berlin, Heidelberg,
DOI 10.1007/978-3-662-47989-6_24, 2015, DOI 10.1007/978-3-662-47989-6_24, 2015,
<https://doi.org/10.1007/978-3-662-47989-6_24>. <https://doi.org/10.1007/978-3-662-47989-6_24>.
[HTT18] Hoang, V.T., Tessaro, S., and A. Thiruvengadam, "The [HTT18] Hoang, V.T., Tessaro, S., and A. Thiruvengadam, "The
multi-user security of GCM, revisited: Tight bounds for Multi-user Security of GCM, Revisited: Tight Bounds for
nonce randomization", Proceedings of the 2018 ACM SIGSAC Nonce Randomization", Proceedings of the 2018 ACM SIGSAC
Conference on Computer and Communications Security, pp. Conference on Computer and Communications Security (CCS
1429-1440. 2018, DOI 10.1145/3243734.3243816, 2018, '18), pp. 1429-1440, DOI 10.1145/3243734.3243816, 2018,
<https://doi.org/10.1145/3243734.3243816>. <https://doi.org/10.1145/3243734.3243816>.
[I-D.irtf-cfrg-aead-limits] [IIM25] Inoue, A., Iwata, T., and K. Minematsu, "Comprehensive
Günther, F., Thomson, M., and C. A. Wood, "Usage Limits on Robustness Analysis of GCM, CCM, and OCB3", Topics in
AEAD Algorithms", Work in Progress, Internet-Draft, draft- Cryptology - CT-RSA 2025, Lecture Notes in Computer
irtf-cfrg-aead-limits-09, 9 October 2024, Science, vol. 15598, DOI 10.1007/978-3-031-88661-4_4,
<https://datatracker.ietf.org/doc/html/draft-irtf-cfrg- 2025, <https://doi.org/10.1007/978-3-031-88661-4_4>.
aead-limits-09>.
[I-D.irtf-cfrg-aegis-aead]
Denis, F. and S. Lucas, "The AEGIS Family of Authenticated
Encryption Algorithms", Work in Progress, Internet-Draft,
draft-irtf-cfrg-aegis-aead-12, 23 September 2024,
<https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-
aegis-aead-12>.
[JMV2002] Joux, A., Martinet, G., and F. Valette, "Blockwise- [JMV2002] Joux, A., Martinet, G., and F. Valette, "Blockwise-
Adaptive Attackers Revisiting the (In)Security of Some Adaptive Attackers Revisiting the (In)Security of Some
Provably Secure Encryption Modes: CBC, GEM, IACBC", Provably Secure Encryption Modes: CBC, GEM, IACBC",
Advances in Cryptology — CRYPTO 2002. CRYPTO 2002. Lecture Advances in Cryptology - CRYPTO 2002, Lecture Notes in
Notes in Computer Science, vol 2442. Springer, Berlin, Computer Science, vol. 2442, DOI 10.1007/3-540-45708-9_2,
Heidelberg, DOI 10.1007/3-540-45708-9_2, 2002, 2002, <https://doi.org/10.1007/3-540-45708-9_2>.
<https://doi.org/10.1007/3-540-45708-9_2>.
[JNPS21] Jean, M., Nikolić, I., Peyrin, T., and Y. Seurin, "The [JNPS21] Jean, M., Nikolić, I., Peyrin, T., and Y. Seurin, "The
Deoxys AEAD family", Journal of Cryptology 34, no. 3 Deoxys AEAD family", Journal of Cryptology, vol. 34, no.
(2021): 31., DOI 10.1007/s00145-021-09397-w, 2021, 31, DOI 10.1007/s00145-021-09397-w, 2021,
<https://doi.org/10.1007/s00145-021-09397-w>. <https://doi.org/10.1007/s00145-021-09397-w>.
[KLLNP16] Menda, M., Leurent, G., Leverrier, A., and M. Naya- [KLLNP16] Menda, M., Leurent, G., Leverrier, A., and M. Naya-
Plasencia, "Quantum Differential and Linear Plasencia, "Quantum Differential and Linear
Cryptanalysis", IACR Transactions on Symmetric Cryptology, Cryptanalysis", IACR Transactions on Symmetric Cryptology,
2016(1), 71–94., DOI 10.13154/tosc.v2016.i1.71-94, 2021, vol. 2016, no.1, pp. 71-94,
DOI 10.13154/tosc.v2016.i1.71-94, 2016,
<https://doi.org/10.13154/tosc.v2016.i1.71-94>. <https://doi.org/10.13154/tosc.v2016.i1.71-94>.
[LGR21] Len, J., Grubbs, P., and T. Ristenpart, "Partitioning [LGR21] Len, J., Grubbs, P., and T. Ristenpart, "Partitioning
Oracle Attacks", 30th USENIX Security Symposium (USENIX Oracle Attacks", 30th USENIX Security Symposium (USENIX
Security 21), 195--212, 2021. Security 21), pp. 195-212, 2021.
[LMP17] Luykx, A., Mennink, B., and K. Paterson, "Analyzing multi- [LMP17] Luykx, A., Mennink, B., and K. Paterson, "Analyzing Multi-
key security degradation", Conference on the Theory and key Security Degradation", Advances in Cryptology -
Applications of Cryptology and Information Security, Hong ASIACRYPT 2017, Lecture Notes in Computer Science, vol.
Kong, China, December 3-7, 2017, Proceedings, Part II 23, 10625, pp. 575-605, DOI 10.1007/978-3-319-70697-9_20,
pp. 575-605. Springer International Publishing, 2017., 2017, <https://doi.org/10.1007/978-3-319-70697-9_20>.
DOI 10.1007/978-3-319-70697-9_20, 2017,
<https://doi.org/10.1007/978-3-319-70697-9_20>.
[M05] McGrew, D., "Efficient authentication of large, dynamic [M05] McGrew, D., "Efficient authentication of large, dynamic
data sets using Galois/Counter Mode (GCM).", Third IEEE data sets using Galois/Counter Mode (GCM)", Third IEEE
International Security in Storage Workshop (SISW'05), pp. International Security in Storage Workshop (SISW'05), pp.
6-pp. IEEE, 2005., DOI 10.1109/SISW.2005.3, 2005, 6-94, DOI 10.1109/SISW.2005.3, 2005,
<https://doi.org/10.1109/SISW.2005.3>. <https://doi.org/10.1109/SISW.2005.3>.
[MBTM17] McKay, K., Bassham, L., Turan, MS., and N. Mouha, "Report [MBTM17] McKay, K., Bassham, L., Turan, MS., and N. Mouha, "Report
on Lightweight Cryptography", DOI 10.6028/NIST.IR.8114, on Lightweight Cryptography", NISTIR 8114,
2017, <https://doi.org/10.6028/NIST.IR.8114>. DOI 10.6028/NIST.IR.8114, 2017,
<https://doi.org/10.6028/NIST.IR.8114>.
[MLGR23] Menda, S., Julia, J., Grubbs, P., and T. Ristenpart, [MLGR23] Menda, S., Julia, J., Grubbs, P., and T. Ristenpart,
"Context Discovery and Commitment Attacks: How to Break "Context Discovery and Commitment Attacks: How to Break
CCM, EAX, SIV, and More", Advances in Cryptology – CCM, EAX, SIV, and More", Advances in Cryptology -
EUROCRYPT 2023. EUROCRYPT 2023. Lecture Notes in Computer EUROCRYPT 2023, Lecture Notes in Computer Science, vol.
Science, vol 14007. Springer, Cham., 14007, pp. 379-407, DOI 10.1007/978-3-031-30634-1_13,
DOI 10.1007/978-3-031-30634-1_13, 2023, 2023, <https://doi.org/10.1007/978-3-031-30634-1_13>.
<https://doi.org/10.1007/978-3-031-30634-1_13>.
[R02] Rogaway, P., "Authenticated-encryption with associated- [R02] Rogaway, P., "Authenticated-encryption with associated-
data", Proceedings of the 9th ACM conference on Computer data", Proceedings of the 9th ACM Conference on Computer
and communications security (CCS '02), Association for and Communications Security (CCS '02), pp. 98-107,
Computing Machinery, New York, NY, USA, 98–107,
DOI 10.1145/586110.586125, 2002, DOI 10.1145/586110.586125, 2002,
<https://doi.org/10.1145/586110.586125>. <https://doi.org/10.1145/586110.586125>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005, RFC 4303, DOI 10.17487/RFC4303, December 2005,
<https://www.rfc-editor.org/info/rfc4303>. <https://www.rfc-editor.org/info/rfc4303>.
[RFC7253] Krovetz, T. and P. Rogaway, "The OCB Authenticated- [RFC7253] Krovetz, T. and P. Rogaway, "The OCB Authenticated-
Encryption Algorithm", RFC 7253, DOI 10.17487/RFC7253, May Encryption Algorithm", RFC 7253, DOI 10.17487/RFC7253, May
2014, <https://www.rfc-editor.org/info/rfc7253>. 2014, <https://www.rfc-editor.org/info/rfc7253>.
skipping to change at page 25, line 7 skipping to change at line 1222
DOI 10.17487/RFC9000, May 2021, DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/info/rfc9000>. <https://www.rfc-editor.org/info/rfc9000>.
[RFC9058] Smyshlyaev, S., Ed., Nozdrunov, V., Shishkin, V., and E. [RFC9058] Smyshlyaev, S., Ed., Nozdrunov, V., Shishkin, V., and E.
Griboedova, "Multilinear Galois Mode (MGM)", RFC 9058, Griboedova, "Multilinear Galois Mode (MGM)", RFC 9058,
DOI 10.17487/RFC9058, June 2021, DOI 10.17487/RFC9058, June 2021,
<https://www.rfc-editor.org/info/rfc9058>. <https://www.rfc-editor.org/info/rfc9058>.
[RS06] Rogaway, R. and T. Shrimpton, "A Provable-Security [RS06] Rogaway, R. and T. Shrimpton, "A Provable-Security
Treatment of the Key-Wrap Problem", Advances in Cryptology Treatment of the Key-Wrap Problem", Advances in Cryptology
- EUROCRYPT 2006. EUROCRYPT 2006. Lecture Notes in - EUROCRYPT 2006, Lecture Notes in Computer Science, vol.
Computer Science, vol 4004. Springer, Berlin, Heidelberg, 4004, pp. 373-390, DOI 10.1007/11761679_23, 2016,
DOI 10.1007/11761679_23, 2016,
<https://doi.org/10.1007/11761679_23>. <https://doi.org/10.1007/11761679_23>.
[S04] Shrimpton, T., "A Characterization of Authenticated- [S04] Shrimpton, T., "A Characterization of Authenticated-
Encryption as a Form of Chosen-Ciphertext Security", Encryption as a Form of Chosen-Ciphertext Security",
Cryptology ePrint Archive, Paper 2004/272, 2004, Cryptology ePrint Archive, Paper 2004/272, 2004,
<https://eprint.iacr.org/2004/272>. <https://eprint.iacr.org/2004/272>.
[SY16] Sasaki, Y. and K. Yasuda, "A New Mode of Operation for [SY16] Sasaki, Y. and K. Yasuda, "A New Mode of Operation for
Incremental Authenticated Encryption with Associated Incremental Authenticated Encryption with Associated
Data", Selected Areas in Cryptography – SAC 2015. SAC Data", Selected Areas in Cryptography - SAC 2015, Lecture
2015. Lecture Notes in Computer Science, vol 9566. Notes in Computer Science, vol. 9566, pp. 397-416,
Springer, Cham, DOI 10.1007/978-3-319-31301-6_23, 2016, DOI 10.1007/978-3-319-31301-6_23, 2016,
<https://doi.org/10.1007/978-3-319-31301-6_23>. <https://doi.org/10.1007/978-3-319-31301-6_23>.
[YSS23] Naito, Y., Sasaki, Y., and T. Sugawara, "Committing [YSS23] Naito, Y., Sasaki, Y., and T. Sugawara, "Committing
Security of Ascon: Cryptanalysis on Primitive and Proof on Security of Ascon: Cryptanalysis on Primitive and Proof on
Mode", IACR Transactions on Symmetric Cryptology 2023, no. Mode", IACR Transactions on Symmetric Cryptology, vol.
4 (2023): 420-451, DOI 10.46586/tosc.v2023.i4.420-451, 2023, no. 4, pp. 420-451,
2023, <https://doi.org/10.46586/tosc.v2023.i4.420-451>. DOI 10.46586/tosc.v2023.i4.420-451, 2023,
<https://doi.org/10.46586/tosc.v2023.i4.420-451>.
Appendix A. AEAD Algorithms with Additional Functionality Appendix A. AEAD Algorithms with Additional Functionality
In this section, we briefly discuss AEAD algorithms that provide In this section, we briefly discuss AEAD algorithms that provide
additional functionality. As noted in Section 4.1, each additional additional functionality. As noted in Section 4.1, each additional
functionality requires a redefinition of the conventional AEAD functionality requires a redefinition of the conventional AEAD
interface; thus, each additional functionality property defines a new interface; thus, each additional functionality property defines a new
class of cryptographic algorithms. class of cryptographic algorithms.
Most importantly, for every Additional Functionality AEAD class, Most importantly, for every AEAD class with additional functionality,
conventional security properties must be redefined concerning the conventional security properties must be redefined concerning the
targeted additional functionality and the new interface. Although it targeted additional functionality and the new interface. Although it
might be possible to consider a particular Additional Functionality might be possible to consider a particular AEAD algorithm with
AEAD algorithm as a conventional AEAD algorithm and study it for the additional functionality as a conventional AEAD algorithm and study
conventional confidentiality and integrity, security (or insecurity) it for the conventional confidentiality and integrity, security (or
in that sense won't be sufficient to label that algorithm as a secure insecurity) in that sense won't be sufficient to label that algorithm
(or insecure) Additional Functionality AEAD. Only security in the as a secure (or insecure) additional functionality AEAD. Only
sense of the redefined conventional properties would suffice. 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 For the examples given in this section, we leave it out of scope how
to concretely redefine conventional security for these classes; we to concretely redefine conventional security for these classes; we
only briefly describe the additional functionality they offer and only briefly describe the additional functionality they offer and
provide further references. provide further references.
A.1. Incremental Authenticated Encryption A.1. Incremental Authenticated Encryption
Definition: An AEAD algorithm allows re-encrypting and authenticating Definition:
a message (associated data and a plaintext pair), which only partly For a message that only partly differs from some previous message,
differs from some previous message, faster than processing it from an AEAD algorithm allows re-encrypting and authenticating that
scratch. message (associated data and a plaintext pair) faster than
processing it from scratch.
Examples: Incremental AEAD algorithm of [SY16]. Examples:
Incremental AEAD algorithm of [SY16]
Security notion: Privacy, Authenticity [SY16]. Security notions:
Privacy, authenticity [SY16]
Notes: The interface of an incremental AEAD algorithm is usually Notes:
expanded, when compared with conventional AEAD, with several When compared with conventional AEAD, the interface of an
operations, which perform different types of updates. For example, incremental AEAD algorithm is usually expanded with several
one can consider such operations as "Append" or "Chop", which provide operations, which perform different types of updates. For
a straightforward additional functionality. A comprehensive example, one can consider operations such as "Append" or "Chop",
definition of an incremental AEAD interface is provided in [SY16]. which provide a straightforward additional functionality. A
comprehensive definition of an incremental AEAD interface is
provided in [SY16].
Further reading: [SY16], [M05], [BKY02]. Further reading:
[SY16], [M05], [BKY02]
A.2. Robust Authenticated Encryption A.2. Robust Authenticated Encryption
Definition: An AEAD algorithm allows users to choose a desired Definition:
ciphertext expansion (the difference between the length of plaintext An AEAD algorithm allows users to choose a desired ciphertext
and corresponding ciphertext) along with an input to the encryption expansion (the difference between the length of plaintext and
operation. This feature enables the regulation of desired data corresponding ciphertext) along with an input to the encryption
integrity guarantees, which depend on ciphertext expansion, for each operation. This feature enables the regulation of desired data
particular application while using the same algorithm implementation. integrity guarantees, which depend on ciphertext expansion, for
each particular application while using the same algorithm
implementation.
Examples: AEZ [HKR2015]. Examples:
AEZ [HKR2015]
Security notion: RAE [HKR2015]. Security notions:
Robust Authenticated Encryption (RAE) [HKR2015]
Notes: The security goal of robust AEAD algorithms is to ensure the Notes:
best possible security, even with small ciphertext expansion The security goal of robust AEAD algorithms is to ensure the best
(referred to as stretch). For instance, analyzing any AEAD algorithm possible security, even with small ciphertext expansion (referred
with a one-byte stretch for conventional integrity reveals to as stretch). For instance, analyzing any AEAD algorithm with a
insecurity, as the probability of forging a ciphertext is no less one-byte stretch for conventional integrity reveals insecurity, as
than 1/256. Nonetheless, from the robust AEAD perspective, an the probability of forging a ciphertext is no less than 1/256.
algorithm with such forgery probability for a one-byte ciphertext Nonetheless, from the robust AEAD perspective, an algorithm with
expansion is secure, representing the best achievable security in such forgery probability for a one-byte ciphertext expansion is
that scenario. secure, representing the best achievable security in that
scenario.
Further reading: [HKR2015]. Further reading:
[HKR2015]
Acknowledgments Acknowledgments
This document benefited greatly from the comments received from the This document benefited greatly from the comments received from the
CFRG community, for which we are very grateful. We would also like CFRG community, for which we are very grateful. We would also like
to extend special appreciation to Liliya Akhmetzyanova, Evgeny to extend special appreciation to Liliya Akhmetzyanova, Evgeny
Alekseev, Alexandra Babueva, Frank Denis, Kirill Kutsenok, Sergey Alekseev, Alexandra Babueva, Frank Denis, Kirill Kutsenok, Sergey
Kyazhin, Samuel Lucas, Grigory Marshalko, Christopher Patton, and Kyazhin, Samuel Lucas, Grigory Marshalko, Christopher Patton, and
Christopher Wood for their thoughtful comments, proposals, and Christopher Wood for their thoughtful comments, proposals, and
discussions. discussions.
 End of changes. 210 change blocks. 
636 lines changed or deleted 743 lines changed or added

This html diff was produced by rfcdiff 1.48.