<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-irtf-cfrg-aead-properties-09" number="9771" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" submissionType="IRTF" category="info" consensus="true" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" version="3">

<!-- [rfced] Please note that the title of the document has been updated as
follows. Abbreviations have been expanded per Section 3.6 of RFC 7322 ("RFC
Style Guide"). Please review.

Original:
  Properties of AEAD Algorithms

Current:
  Properties of Authenticated Encryption with Associated Data (AEAD)
  Algorithms
-->

  <front>
    <title abbrev="Properties of AEAD algorithms">Properties Algorithms">Properties of AEAD Authenticated Encryption with Associated Data (AEAD) Algorithms</title>
    <seriesInfo name="Internet-Draft" value="draft-irtf-cfrg-aead-properties-09" /> name="RFC" value="9771"/>
    <author fullname="Andrey Bozhko" initials="A.A." initials="A" role="editor" surname="Bozhko">
      <organization>CryptoPro</organization>
      <address>
	<email>andbogc@gmail.com</email>
      </address>
    </author>
    <date year="2024" />
		<area>General</area> year="2025" month="April"/>

    <workgroup>Crypto Forum</workgroup>
    <keyword>authenticated encryption, mode encryption</keyword>
    <keyword>mode of operation, AEAD, properties</keyword> operation</keyword>
    <keyword>AEAD</keyword>
    <keyword>properties</keyword>

<!-- [rfced] Please ensure that the guidelines listed in Section 2.1 of RFC
5743 have been adhered to in this document. See
https://www.rfc-editor.org/rfc/rfc5743.html#section-2.1.
-->

    <abstract>
      <t> Authenticated Encryption with Associated Data (AEAD) algorithms
      provide both confidentiality and integrity of data. The widespread use
      of AEAD algorithms in various applications has led to an increased
      demand for AEAD algorithms with additional properties, driving research
      in the field. This document provides definitions for the most common of
      those properties, aiming properties and aims to improve consistency in the terminology used
      in documentation. This document is a product of the Crypto Forum
      Research Group.
			</t>
		</abstract>
	</front>
	<middle>
		<section anchor="Introduction" numbered="true" toc="default">
			<name>Introduction</name>
			<t>An Authenticated Encryption with Associated Data (AEAD) algorithm provides confidentiality for the plaintext to be encrypted and integrity for the plaintext and some associated data (sometimes called Header). "Header"). AEAD algorithms play a crucial role in various applications and have emerged as a significant focus in cryptographic research.</t>
			<section anchor="IntBack" numbered="true" toc="default">
				<name>Background</name>
				 <t>
					AEAD algorithms are formally defined in <xref target="RFC5116" format="default"/>. The main benefit of AEAD algorithms is that they simultaneously provide data confidentiality and integrity and have a simple unified interface. In contrast to generic compositions of Message Authentication Code (MAC) and encryption algorithms, an AEAD algorithm allows for a reduction in key and state sizes, improving the data processing speed. Most AEAD algorithms come with security analysis, usage guidelines, and reference implementations. Consequently, their integration into high-level schemes and protocols is highly transparent. For instance, AEAD algorithms are mandatory in TLS 1.3 <xref target="RFC8446" format="default" />, IPsec ESP Encapsulating Security Payload (ESP) <xref target="RFC4303" format="default" /><xref /> <xref target="RFC8221" format="default" />, and QUIC <xref target="RFC9000" format="default" />.
				</t>
				<t>
					While confidentiality and data integrity, being the integrity (the conventional properties of AEAD algorithms, algorithms) suffice for many applications, some environments demand other uncommon cryptographic properties. These often require additional analysis and research. As the number of such properties and corresponding research papers grows, inevitable misunderstandings and confusion arise. It This is a common situation when related but formally different properties are named identically, identically or when some security properties only have folklore understanding and are not formally defined. Consequently, the risk of misusing AEAD algorithms increases, potentially resulting in security issues.
				</t>
			</section>
			<section anchor="IntScope" numbered="true" toc="default">
				<name>Scope</name>
				<t>
					In this document, in <xref target="Properties" format="default"/>, format="default"/> of this document, we provide the a list of the most common additional properties of AEAD algorithms. The properties are divided into two categories, namely namely, security properties (see <xref target="SecurityProp" format="default"/>) and implementation properties (see <xref target="ImpProp" format="default"/>).

					We provide a high-level definition for each property. For security properties, we also reference an informative source where a formal game-based security notion is defined; we do not consider security properties for which no game-based formalization exists. When possible, we offer additional information: synonymous names, examples of algorithms that provide the property, applications that might necessitate such the property from an AEAD algorithm, references for further reading, and additional notes containing information outside these categories.
				</t>

				<t>
					The objective of this document is to enhance clarity and establish a common language in the field. In particular, the primary application of the document lies in the following two use cases within the IRTF or the IETF documents document development process: process in the IRTF and IETF:
				</t>
				<ul>
					<li>
						<t>For an RFC or I-D that defines an AEAD algorithm, it is recommended to use the notations of in <xref target="Properties" format="default"/> when listing additional properties of the algorithm.</t>
					</li>
					<li>
						<t>For an RFC or I-D that defines a generic protocol based on an AEAD algorithm, it is recommended to use the notations of in <xref target="Properties" format="default"/> if any additional properties are required from the algorithm.</t>
					</li>
				</ul>
				<t>
					This document represents the consensus of the Crypto Forum Research Group (CFRG). This document is not an IETF product and is not a standard.
				</t>
			</section>
		</section>
		<section numbered="true" toc="default">
			<name>Conventions Used in This Document</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP 14 BCP&nbsp;14 <xref target="RFC2119" format="default" /><xref target="RFC8174" format="default" /> target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.
        </t>

		</section>
	<section anchor="AEAD" numbered="true" toc="default">
	  <name>AEAD Algorithms</name>

	  <t> This section gives a conventional definition of an AEAD
	  algorithm following <xref target="RFC5116" format="default"/>. </t>
			<t>
				Definition: An

	  <dl newline="true" spacing="normal">
	    <dt>Definition:</dt>
	    <dd><t>An AEAD algorithm is defined by two operations, which are
	    authenticated encryption and authenticated decryption:
			</t>
				<ul>
					<li>
						<t>A decryption:</t>
	    <ul spacing="normal">
	      <li>A deterministic operation of authenticated encryption
	      has four inputs, each a binary string: a secret key K of a fixed
	      bit length, a nonce N, associated data A, and a plaintext P. The
	      plaintext contains the data to be encrypted and authenticated,
	      and the associated data contains the data to be authenticated
	      only. Each nonce value MUST <bcp14>MUST</bcp14> be unique in every
	      distinct invocation of the operation for any particular value of
	      the key. The authenticated encryption operation outputs a
	      ciphertext C.</t>
					</li>
					<li>
						<t>A C.</li>
	      <li>A deterministic operation of authenticated decryption has
	      four inputs, each a binary string: a secret key K of a fixed bit
	      length, a nonce N, associated data A, and a ciphertext C. The
	      operation verifies the integrity of the ciphertext and
	      associated data and decrypts the ciphertext. It returns a
	      special symbol FAIL if the inputs are not authentic; otherwise,
	      the operation returns a plaintext P.</t>
					</li> P.</li>
	    </ul>
			<t>
	    </dd>
	  </dl>
<!-- [rfced] Will readers understand what "it" refers to here?

Original:
   We note that specifications of AEAD algorithms that use
   authentication tags to ensure integrity MAY define it as an
   independent output of the encryption operation and as an independent
   input of the decryption operation.
-->

	  <t>We note that specifications of AEAD algorithms that use
	    authentication tags to ensure integrity <bcp14>MAY</bcp14> define
	    it as an independent output of the encryption operation and as an
	    independent input of the decryption operation. Throughout this
	    document, by default, we will consider the authentication tag as
	    part of the ciphertext.
			</t>
			<t>
				For more details on the AEAD definition, please refer to <xref target="RFC5116" format="default" />.
			</t>

			<t>
				Throughout this document, by default, we will consider nonce-based AEAD algorithms, which have an interface from the definition as defined above, and we give no other restrictions on their structure. However, some properties considered in the document apply only to particular classes of such algorithms, like block cipher-based AEAD algorithms based on block ciphers (such algorithms use a block cipher as a building block). If that is the case, we explicitly point that out in the corresponding section.
			</t>
		</section>
	<section anchor="Properties" numbered="true" toc="default">
	  <name>AEAD Properties</name>
	  <section anchor="Classification" numbered="true" toc="default">
	    <name>Classification of additional Additional AEAD Properties</name>
				<t>
					In
	    <t>In this document, we employ a high-level classification of
	    additional properties. This classification aims to provide insight
	    into how one can benefit from each property. The additional
	    properties in this section are categorized into one of these two groups:
				</t>
				<ul>
					<li>
						<t>
							Security
	    groups:</t>
	    <ul spacing="normal">
	      <li>Security properties: We classify a property as a security
	      property if it either takes into account new threats or extends
	      adversarial capabilities, in addition to those posed by the
	      typical nonce-respecting adversary whose goal is to compromise
	      confidentiality or data integrity.
						</t>
					</li>
					<li>
						<t>
							Implementation integrity.</li>
	      <li>Implementation properties: We classify a property as an
	      implementation property if it enables more efficient
	      implementations of the AEAD algorithm in specific cases or environments.
						</t>
					</li>
	      environments.</li>
	    </ul>
	    <t> We note that some additional properties of AEAD algorithms
	    found in the literature could not be allocated to either of these
	    two groups. The observation is that such properties require an
	    extension of the conventional AEAD interface. We refer to these
	    properties as 'additional "additional functionality properties' properties" and define the
	    corresponding group as follows:
				</t>
				<ul>

					<li>
						<t>
							Additional follows:</t>
	    <ul spacing="normal">
	      <li>Additional functionality properties: We classify a property
	      as an additional functionality property if it introduces new
	      features in addition to the standard authenticated encryption with associated data.
						</t>
					</li> AEAD.</li>
	    </ul>
	    <t> With the extension of the conventional AEAD interface, each
	    additional functionality property defines a new class of
	    cryptographic algorithms. Consequently, the basic threats and
	    adversarial capabilities must be redefined for each class. As a
	    result, additional functionality properties consider the basic
	    threats and adversarial capabilities for their class of
	    algorithms, in contrast to security properties, which consider the
	    extended ones. For this reason, we do not focus on additional
	    functionality properties in this document. However, for the sake
	    of completeness, in <xref target="AddProp" format="default"/>, we
	    briefly present two classes of AEAD algorithms with additional
	    functionality.
				</t>
			</section>

 <section anchor="Base" numbered="true" toc="default">
   <name>Conventional Properties</name>
				<t>
					In
   <t>In this section, we recall the conventional properties of an AEAD
   algorithm. Active nonce-respecting adversaries in a single-key setting are
   considered.
   </t>
   <t>
     We say that an AEAD algorithm provides security if it provides the conventional properties listed in this section.
   </t>
   <section anchor="Conf" numbered="true" toc="default">
     <name>Confidentiality</name>
					<t>
						Definition: An

     <dl spacing="normal" newline="true">
       <dt>Definition:</dt><dd>An AEAD algorithm guarantees that the plaintext is not
       available to an active, nonce-respecting adversary.
					</t>
					<t>
						Security notion: IND-CCA adversary.</dd>
       <dt>Security notion:</dt><dd>IND-CCA <xref target="BN2000"
       format="default"/> (or IND-CCA2 <xref target="S04" format="default"/>).
					</t>
					<t>
						Synonyms: Message privacy.
					</t>
					<t>
						Notes: Confidentiality format="default"/>)</dd>
       <dt>Synonyms:</dt><dd>Message privacy</dd>
       <dt>Notes:</dt><dd>Confidentiality against passive adversaries can also
       be considered. The corresponding security notion is IND-CPA <xref
       target="BN2000" format="default"/><xref target="R02" format="default"/>.
					</t>
					<t>
						Further reading: format="default"/> <xref target="R02"
       format="default"/>.</dd>
       <dt>Further reading:</dt><dd><xref target="R02" format="default"/>,
       <xref target="BN2000" format="default"/>, <xref target="S04" format="default"/>.
					</t>
       format="default"/></dd>
     </dl>
     </section>

<!-- [rfced] Please confirm that "IND-CTXT" is correct here. We ask because we
do not see "IND-CTXT" in [BN2000], but we do see "INT-CTXT".

Original:
   Security notion: IND-CTXT [BN2000] (or AUTH [R02]).

   Security notion: IND-CPA and IND-CTXT [BN2000][R02] (or equivalently
   IND-CCA3 [S04]).
-->

     <section anchor="Int" numbered="true" toc="default">
       <name>Data Integrity</name>
					<t>
						Definition: An
     <dl spacing="normal" newline="true">
       <dt>Definition:</dt><dd>An AEAD algorithm allows one to ensure that the
       ciphertext and the associated data have not been changed or forged by
       an active, nonce-respecting adversary.
					</t>
					<t>
						Security notion: IND-CTXT adversary.</dd>
       <dt>Security notion:</dt><dd>IND-CTXT <xref target="BN2000"
       format="default"/> (or AUTH <xref target="R02" format="default"/>).
					</t>
					<t>
						Synonyms: Message
       format="default"/>)</dd>
       <dt>Synonyms:</dt><dd>Message authentication, authenticity.
					</t>
					<t>
						Further reading: <xref authenticity</dd>
       <dt>Further reading:</dt><dd><xref target="R02" format="default"/>,
       <xref target="BN2000" format="default"/>, <xref target="S04" format="default"/>.
					</t>
       format="default"/></dd>
     </dl>
     </section>

     <section anchor="AE" numbered="true" toc="default">
       <name>Authenticated Encryption Security</name>
					<t>
						Definition: An
       <dl newline="true" spacing="normal">
	 <dt>Definition:</dt><dd>An AEAD algorithm provides confidentiality
	 and data integrity against active, nonce-respecting adversaries.
					</t>
					<t>
						Security notion: IND-CPA adversaries.</dd>
	 <dt>Security notion:</dt><dd>IND-CPA and IND-CTXT <xref
	 target="BN2000" format="default"/><xref format="default"/> <xref target="R02"
	 format="default"/> (or equivalently equivalently, IND-CCA3 <xref target="S04" format="default"/>).
					</t>
					<t>
						Notes: Please
	 format="default"/>)</dd>
	 <dt>Notes:</dt><dd>Please refer to <xref
	 target="I-D.irtf-cfrg-aead-limits" format="default"/> for usage
	 limits on modern AEAD algorithms used in IETF protocols.
					</t>
					<t>
						Further reading: <xref protocols.</dd>
	 <dt>Further reading:</dt><dd><xref target="R02" format="default"/>,
	 <xref target="BN2000" format="default"/>, <xref target="S04" format="default"/>.
					</t>
	 format="default"/></dd>
       </dl>
     </section>

 </section>

 <section anchor="SecurityProp" numbered="true" toc="default">
   <name>Security Properties</name>
   <section anchor="BWsec" numbered="true" toc="default">
     <name>Blockwise Security</name>
					<t>
						Definition: An
     <dl newline="true" spacing="normal">
       <dt>Definition:</dt><dd>An AEAD algorithm provides security even if an
       adversary can adaptively choose the next part of the plaintext
       depending on already computed already-computed ciphertext parts during an encryption operation.
					</t>
					<t>
						Security notion: D-LORS-BCPA
       operation.</dd>
       <dt>Security notion:</dt><dd>D-LORS-BCPA for confidentiality against
       passive adversaries, B-INT-CTXT for integrity <xref target="EV16" target="EV17"
       format="default"/>; OAE1 <xref target="HRRV15" format="default"/> (a
       stronger notion; originally OAE (Online Authenticated Encryption) in
       <xref target="FFL12" format="default"/>).
					</t>
					<t>
						Examples: Deoxys format="default"/>)</dd>
       <dt>Examples:</dt><dd>Deoxys <xref target="JNPS21" format="default"/>,
       SAEF <xref target="ABV21" format="default"/>.
					</t>
					<t>
						Notes: Blockwise format="default"/></dd>

       <dt>Notes:</dt><dd>Blockwise security is highly relevant for streamable
       AEAD algorithms (see <xref target="Online" format="default"/>). The
       OAE1 security notion <xref target="HRRV15" format="default"/>, format="default"/> and the
       OAE2 notion <xref target="HRRV15" format="default"/> are tailored for
       streamable AEAD algorithms. OAE1 was first defined in <xref
       target="FFL12" format="default"/> under the name OAE; however, it
       contained a glitch, and the reformulated definition was presented in
       <xref target="HRRV15" format="default"/>. Blockwise security follows
       from security in the OAE notion <xref target="EV16" target="EV17"
       format="default"/>. For a discussion on security notions for streamable
       AEAD algorithms algorithms, see <xref target="HRRV15" format="default"/>.
					</t>
					<t>
						Applications: Real-time format="default"/>.</dd>
       <dt>Applications:</dt><dd>Real-time streaming protocols, encryption on
       resource-constrained devices.
					</t>
					<t>
						Further reading: <xref target="EV16" devices</dd>
       <dt>Further reading:</dt><dd><xref target="EV17" format="default"/>,
       <xref target="JMV2002" format="default"/>, <xref target="FJMV2004"
       format="default"/>, <xref target="HRRV15" format="default"/>.
					</t> format="default"/></dd>
     </dl>
   </section>

   <section anchor="FullComm" numbered="true" toc="default">
     <name>Full Commitment</name>
					<t>
						Definition: An
     <dl spacing="normal" newline="true">
       <dt>Definition:</dt><dd>An AEAD algorithm guarantees that it is hard to
       find two or more different tuples of the key, nonce, associated data,
       and plaintext such that they encrypt to the same ciphertext. In other
       words, an AEAD scheme guarantees that a ciphertext is a commitment to
       all inputs of an authenticated encryption operation.
					</t>
					<t>
						Security notion: CMT-4 operation.</dd>
       <dt>Security notion:</dt><dd>CMT-4 <xref target="BH22"
       format="default"/>, generalized CMT for a restricted setting (see the
       notes below) <xref target="MLGR23" format="default" />.
					</t>
					<t>
						Examples: Ascon format="default"/></dd>
       <dt>Examples:</dt><dd>Ascon <xref target="DEMS21a" format="default"/><xref
       format="default"/> <xref target="DEMS21b" format="default"/><xref format="default"/> <xref
       target="YSS23" format="default"/>, full committing versions of GCM Galois/Counter Mode (GCM) and
       GCM-SIV <xref target="BH22" format="default"/>, generic constructions
       <xref target="BH22" format="default"/><xref format="default"/> and <xref target="CR22"
       format="default" />.
					</t>
					<t>
						Notes: Full /></dd>
       <dt>Notes:</dt><dd>Full commitment can be considered in a weaker
       setting, where certain restrictions on the tuples produced by an
       adversary are imposed <xref target="MLGR23" format="default" />. For
       instance, an adversary must find tuples that all share the same
       associated data value. In such cases, an AEAD algorithm is said to
       provide full commitment in a restricted setting. The imposed
       restrictions MUST <bcp14>MUST</bcp14> be listed.
					</t>
					<t>
						Applications: Message listed.</dd>
       <dt>Applications:</dt><dd>Message franking <xref target="GLR17"
       format="default" />.
					</t>
					<t>
						Further reading:
						<xref /></dd>
       <dt>Further reading:</dt><dd><xref target="BH22" format="default" />,
       <xref target="CR22" format="default" />, <xref target="MLGR23"
       format="default" />.
					</t> /></dd>
     </dl>

   </section>
   <section anchor="KeyComm" numbered="true" toc="default">
     <name>Key Commitment</name>
					<t>
						Definition: An
     <dl spacing="normal" newline="true">
       <dt>Definition:</dt><dd>An AEAD algorithm guarantees that it is hard to
       find two or more different keys and the same number of potentially
       equal triples of nonce, associated data, and plaintext such that they
       encrypt to the same ciphertext under corresponding keys. In other
       words, an AEAD scheme guarantees that a ciphertext is a commitment to
       the key used for an authenticated encryption operation.
					</t>
					<t>
						Security notion: CMT-1 operation.</dd>
       <dt>Security notion:</dt><dd>CMT-1 <xref target="BH22" format="default"/>.
					</t>
					<t>
						Synonyms: Key-robustness, format="default"/></dd>
       <dt>Synonyms:</dt><dd>Key robustness, key collision resistance.
					</t>
					<t>
						Examples: Ascon resistance</dd>
       <dt>Examples:</dt><dd>Ascon <xref target="DEMS21a" format="default"/><xref
       format="default"/> <xref target="DEMS21b" format="default"/><xref format="default"/> <xref
       target="YSS23" format="default"/>, generic constructions from <xref
       target="BH22" format="default"/> and <xref target="CR22" format="default"/>.
					</t>
					<t>
						Notes: Key
       format="default"/></dd>
       <dt>Notes:</dt><dd>Key commitment follows from full commitment. Full
       commitment does not follow from key commitment <xref target="BH22"
       format="default" />.
					</t>
					<t>
						Applications: Password-Authenticated />.</dd>
       <dt>Applications:</dt><dd>Password-Authenticated Key Exchange,
       password-based encryption <xref target="LGR21" format="default" />, key
       rotation, envelope encryption <xref target="ADGKLS22" format="default" />.
					</t>
					<t>
						Further reading:
						<xref
       /></dd>
       <dt>Further reading:</dt><dd><xref target="BH22" format="default" />,<xref
       />, <xref target="CR22" format="default" />, <xref target="FOR17"
       format="default" />, <xref target="LGR21" format="default" />, <xref
       target="GLR17" format="default" />.
					</t> /></dd>
     </dl>

   </section>

   <section anchor="Leakage" numbered="true" toc="default">
     <name>Leakage Resistance</name>
					<t>
						Definition: An
     <dl spacing="normal" newline="true">
       <dt>Definition:</dt><dd>An AEAD algorithm provides security even if
       some additional information about computations of an encryption (and
       possibly decryption) operation is obtained via side-channel leakages.
					</t>
					<t>
						Security notion: CIL1
       leakages.</dd>
       <dt>Security notion:</dt><dd>CIL1 <xref target="GPPS19"
       format="default" /> (CIML2 <xref target="BPPS17" format="default" />
       with leakages in decryption) for integrity, CCAL1 <xref target="GPPS19"
       format="default" /> (CCAmL2 <xref target="GPPS19" format="default" />
       with leakages in decryption) for Authenticated Encryption security.
					</t>
					<t>
						Examples: Ascon authenticated encryption
       security</dd>
       <dt>Examples:</dt><dd>Ascon <xref target="DEMS21a" format="default"/><xref
       format="default"/> <xref target="DEMS21b" format="default"/> (security
       under CIML2 and CCAL1 notions <xref target="B20" format="default" />),
       TEDT <xref target="GPPS19" format="default" />.
					</t>
					<t>
						Notes: Leakages /></dd>

      <dt>Notes:</dt><dd><t>Leakages during AEAD operation executions are
       implementation-dependent. It is possible to implement symmetric
       algorithms in a way that every possible physical leakage is entirely
       independent of the secret inputs of the algorithm (for example, with a
       masking technique <xref target="CJRR99" format="default" />), meaning
       the adversary doesn't gain any additional information about the
       algorithm's computation via side-channel leakages. We say that an AEAD
       algorithm doesn't provide leakage resistance if it can only achieve leakage
       resistance only with such an implementation. Leakage-resistant AEAD
       algorithms aim to place as mild requirements on implementation implementations that are as mild as
       possible to achieve leakage resistance. These requirements SHOULD
       <bcp14>SHOULD</bcp14> be listed.
					</t>
					<t>
						Confidentiality listed.</t>
       <t>Confidentiality of plaintext in the presence of leakages in the
       encryption operation is unachievable if an adversary can repeat the
       nonce used to encrypt the plaintext in other encryption
       queries. Confidentiality can be achieved only for plaintexts encrypted
       with fresh nonces (analogously to nonce-misuse resilience, resilience; see <xref
       target="NM" format="default" />). For further discussions, see <xref
       target="GPPS19" format="default" /> and <xref target="B20"
       format="default" />.
					</t>
					<t>
						For />.</t>
       <t>For primitive-based AEAD algorithms, key evolution (internal
       re-keying <xref target="RFC8645" format="default" />) can contribute to
       achieving leakage resistance with leakages in
       encryption. Confidentiality in the presence of decryption leakages can
       be achieved by two-pass AEAD algorithms with key evolution, which
       compute independent ephemeral key values for encryption and tag
       generation, where the computation of these keys is implemented without
       any leakages. For more discussions discussion on achieving leakage resistance resistance, see
       <xref target="B20" format="default" />.
					</t>
					<t>
						A />.</t>
       <t>Leakage Resilience, a well-known weaker property, Leakage Resilience, property introduced in
       <xref target="BMOS17" format="default" />, can also be
       considered. However, this document makes a conscious choice to focus on the stronger Leakage Resistance, following the framework established in
       <xref target="GPPS19" format="default" />, /> and <xref target="B20"
       format="default" />, this document makes a conscious choice to focus on
       the stronger Leakage Resistance for its enhanced practicality and comprehensiveness.
					</t>
					<t>
						Applications: Encryption
       comprehensiveness.</t></dd>
       <dt>Applications:</dt><dd>Encryption on smart cards, Internet-of-things Internet-of-Things
       devices, or other constrained devices.
					</t>
					<t>
						Further reading: <xref devices</dd>
       <dt>Further reading:</dt><dd><xref target="GPPS19" format="default" />,
       <xref target="B20" format="default" />, <xref target="BPPS17"
       format="default" />, <xref target="BMOS17" format="default" />.
					</t> /></dd>
     </dl>
   </section>
   <section anchor="Mu-sec" numbered="true" toc="default">
					<name>Multi-User
     <name>Multi-user Security</name>
					<t>
						Definition: An
     <dl newline="true" spacing="normal">

<!-- [rfced] May we remove "It holds that"?

Original:
      It holds that for any AEAD algorithm security degrades no worse
      than linearly with an increase in the number of users [BT16].

Perhaps:
      For any AEAD algorithm, security degrades no worse
      than linearly with an increase in the number of users [BT16].
-->

       <dt>Definition:</dt><dd>The security of an AEAD algorithm degrades slower than
       linearly with an increase in the number of users.
					</t>
					<t>
						Security notion: mu-ind users.</dd>
       <dt>Security notion:</dt><dd>mu-ind  <xref target="BT16" format="default" />.
					</t>
					<t>
						Examples: AES-GCM /></dd>
       <dt>Examples:</dt><dd>AES-GCM <xref target="D07" format="default"/>,
       ChaCha20-Poly1305 <xref target="RFC8439" format="default"/>,
       AES-GCM-SIV <xref target="RFC8452" format="default"/>, AEGIS <xref
       target="I-D.irtf-cfrg-aegis-aead" format="default"/>.
					</t>
					<t>
						Notes: It format="default"/></dd>
       <dt>Notes:</dt><dd><t>It holds that for any AEAD algorithm algorithm, security
       degrades no worse than linearly with an increase in the number of users
       <xref target="BT16" format="default" />. However, for some applications
       with a significant number of users, better multi-user guarantees are
       required. For example, in the TLS 1.3 protocol, to address this issue,
       AEAD algorithms are used with a randomized nonce (deterministically
       derived from a traffic secret and a sequence number). number) to address this issue. Using nonce
       randomization in block cipher counter-based AEAD modes can contribute
       to multi-user security <xref target="BT16" format="default"
       />. Multi-user usage limits for AES-GCM and ChaCha20-Poly1305 are
       provided in <xref target="I-D.irtf-cfrg-aead-limits" format="default"/>.
					</t>
					<t>
						A
       format="default"/>.</t>
       <t>A weaker security notion, multi-user key recovery, is also
       introduced and thoroughly studied in <xref target="BT16"
       format="default" />. While this document focuses on
       indistinguishability for security notions, key recovery might be
       relevant and valuable to study alongside indistinguishability.
					</t>
					<t>
						Applications: Data indistinguishability.</t></dd>
       <dt>Applications:</dt><dd>Data transmission layer of secure
       communication protocols (e.g., TLS, IPSec, SRTP, etc.)
					</t>
					<t>
						Further reading: <xref IPsec, the Secure Real-time Transport Protocol (SRTP), etc.)</dd>
       <dt>Further reading:</dt><dd><xref target="BT16" format="default" />,
       <xref target="HTT18" format="default" />, <xref target="LMP17"
       format="default" />, <xref target="DGGP21" format="default" />, <xref
       target="BHT18" format="default" />.
					</t> /></dd>
     </dl>
   </section>
   <section anchor="NonceHiding" numbered="true" toc="default">
					<name>Nonce-Hiding</name>
					<t>
						Definition: An
     <name>Nonce Hiding</name>
     <dl spacing="normal" newline="true">
       <dt>Definition:</dt><dd>An AEAD algorithm provides confidentiality for
       the nonce value used to encrypt plaintext. The algorithm includes
       information about the nonce in the ciphertext and doesn't require the
       nonce as input for the decryption operation.
					</t>
					<t>
						Security notion: AE2 operation.</dd>
       <dt>Security notion:</dt><dd>AE2 <xref target="BNT19" format="default" />.
					</t>
					<t> /></dd>

<!-- [rfced] Should "Hide-Nonce (HN)" be updated to "Nonce-Hiding" per the
title of Section 4.3.6? We are unable to access [BNT19] to check for
guidance there.

Original:
   4.3.6.  Nonce-Hiding
   ...
   Examples: Hide-Nonce (HN) transforms [BNT19].

Perhaps:
   4.3.6.  Nonce Hiding
   ...
   Examples: Nonce-hiding transforms [BNT19].
-->

       <dt>Examples:</dt><dd>Hide-Nonce (HN) transforms <xref target="BNT19" format="default" />.
					</t>
					<t>
						Notes: As /></dd>
       <dt>Notes:</dt><dd>As discussed in <xref target="BNT19"
       format="default" />, adversary-visible nonces might compromise message
       and user privacy, similar to the way any metadata might do. might. As pointed
       out in <xref target="B13" format="default" />, even using a counter as
       a nonce value might compromise privacy. Designing a privacy-preserving
       way to manage nonces might be a challenging problem for an application.
					</t>
					<t>
						Applications: Any application.</dd>
       <dt>Applications:</dt><dd>Any application that can't rely on a secure 'out-of-band'
       "out-of-band" nonce communication.
					</t>
					<t>
						Further reading: <xref communication</dd>
       <dt>Further reading:</dt><dd><xref target="BNT19" format="default" />.
					</t> /></dd>
     </dl>
   </section>
   <section anchor="NM" numbered="true" toc="default">
     <name>Nonce Misuse</name>
					<t>
						Definition: An
     <dl spacing="normal" newline="true">
       <dt>Definition:</dt><dd><t>An AEAD algorithm provides security
       (resilience or resistance) even if an adversary can repeat nonces in
       its encryption queries. Nonce misuse resilience and resistance are
       defined as follows:
					</t>
					<ul>
						<li>
							<t>
								Nonce follows:</t>
       <dl newline="false" spacing="normal">
	 <dt>Nonce misuse resilience: Security resilience:</dt><dd><t>Security is provided for messages
	 encrypted with non-repeated (fresh) nonces (correctly encrypted messages).
							</t>
							<t>
								Security notion: CPA
	 messages).</t>
	 <dl newline="true" spacing="normal">
	 <dt>Security notion:</dt><dd>CPA resilience (confidentiality),
	 authenticity resilience (integrity), CCA resilience (authenticated
	 encryption) <xref target="ADL17" format="default" />.
							</t>
							<t>
								Examples: ChaCha20-Poly1305 /></dd>
	 <dt>Examples:</dt><dd>ChaCha20-Poly1305 <xref target="RFC8439"
	 format="default"/>, AES-GCM <xref target="D07" format="default"/>
	 (only confidentiality).
							</t>
						</li>
						<li>
							<t>Nonce confidentiality)</dd></dl></dd>

       	 <dt>Nonce misuse resistance: Security resistance:</dt><dd><t>Security is provided for all
       	 messages that were not encrypted with the same nonce value more than
       	 once.</t>
							<t>
								Security notion: MRAE
	 <dl newline="true" spacing="normal">
	 <dt>Security notion:</dt><dd>MRAE <xref target="RS06" format="default" />.
							</t>
							<t>
								Examples: AES-GCM-SIV /></dd>
	 <dt>Examples:</dt><dd>AES-GCM-SIV <xref target="RFC8452"
	 format="default"/>, Deoxys-II <xref target="JNPS21" format="default"/>.
							</t>
							<t>
								Notes: SIV
	 format="default"/></dd>
	 <dt>Notes:</dt><dd>Synthetic Initialization Vector (SIV) construction <xref target="RS06"
	 format="default" /> is a generic construction that provides nonce
	 misuse resistance.
							</t>
						</li>
					</ul>
					<t>
						Notes: Nonce resistance.</dd></dl></dd>
       </dl>
     </dd>
     <dt>Notes:</dt><dd>Nonce misuse resilience follows from nonce misuse
     resistance. Nonce misuse resistance does not follow from nonce misuse resilience.
					</t>
					<t>
						Applications: Any
     resilience.</dd>
     <dt>Applications:</dt><dd>Any application where nonce uniqueness can't be
     guaranteed, security against fault-injection attacks and malfunctions,
     processes parallelization, full disk encryption.
					</t>
					<t>
						Further reading:
						<xref encryption</dd>
     <dt>Further reading:</dt><dd><xref target="RS06" format="default" />,
     <xref target="ADL17" format="default" />.
					</t> /></dd>
     </dl>

   </section>

   <section anchor="Quantum" numbered="true" toc="default">
     <name>Quantum Security</name>
					<t>
						Definition: An
     <dl spacing="normal" newline="true">
       <dt>Definition:</dt><dd><t>An AEAD algorithm provides security (in a Q1
       or Q2 model) against a quantum adversary. Q1 and Q2 models are defined
       as follows:
					</t>
					<ul>
						<li>
							<t>Q1 model:  An follows:</t>
       <dl spacing="normal" newline="false">
	 <dt>Q1 model:</dt><dd><t>An adversary has access to local quantum
	 computational power. It has classical access to encryption and
	 decryption oracles.</t>

							<t>Synonyms: Post-quantum security.</t>

							<t>Examples:
	 <dl spacing="normal" newline="true">
	 <dt>Synonyms:</dt><dd>Post-quantum security</dd>
	 <dt>Examples:</dt><dd> AES-GCM <xref target="D07" format="default"/>,
	 ChaCha20-Poly1305 <xref target="RFC8439" format="default"/>, OCB
	 <xref target="RFC7253" format="default"/>, MGM Multilinear Galois Mode (MGM) <xref target="RFC9058"
	 format="default"/>, AES-GCM-SIV <xref target="RFC8452"
	 format="default"/>, AEGIS <xref target="I-D.irtf-cfrg-aegis-aead" format="default"/>.</t>
						</li>
						<li>
							<t>Q2 model: An
	 format="default"/></dd>
	 </dl></dd>
       	 <dt>Q2 model:</dt><dd><t>An adversary has access to local quantum
       	 computational power. It has quantum access to encryption and
       	 decryption oracles, i.e., it can query encryption and decryption
       	 oracles with quantum superpositions of inputs to receive quantum
       	 superpositions of the outputs.</t>

							<t>Synonyms:
	 <dl spacing="normal" newline="true">
	 <dt>Synonyms:</dt><dd> Superposition-based quantum security.</t>

							<t>Examples: security</dd>
	 <dt>Examples:</dt><dd> QCB <xref target="BBCLNSS21" format="default" />.</t>
						</li>
					</ul>
					<t>
						Notes: Most /></dd>
       </dl></dd>
       </dl>
     </dd>
     <dt>Notes:</dt><dd>Most symmetric cryptographic algorithms that are secure in
     the classical model provide quantum security in the Q1 model, i.e., they
     are post-quantum secure. Security in the Q1 setting corresponds to
     security against "harvest now, decrypt later" attacks. Security in Q1
     follows from security in Q2, Q2; the converse does not hold. For discussions
     on the relevance of the Q2 model model, please see <xref target="G17" format = "default"/>.
					</t>
					<t>
						Further reading:
     "default"/>.</dd>
     <dt>Further reading:</dt><dd> <xref target="KLLNP16" format="default" />,
     <xref target="BBCLNSS21" format="default" />, <xref target="G17" format = "default"/>.
					</t>
     "default"/></dd>
     </dl>
   </section>

   <section anchor="Reforg" numbered="true" toc="default">
     <name>Reforgeability Resilience</name>
					<t>
						Definition: An
     <dl newline="true" spacing="normal">
       <dt>Definition:</dt><dd>An AEAD algorithm guarantees that once a
       successful forgery for the algorithm has been found, it is still hard
       to find any subsequent forgery.
					</t>
					<t>
						Security notion: j-Int-CTXT forgery.</dd>
       <dt>Security notion:</dt><dd>j-Int-CTXT <xref target="FLLW17" format="default" />.
					</t>
					<t>
						Examples: Deoxys /></dd>
       <dt>Examples:</dt><dd>Deoxys <xref target="JNPS21" format="default"/>,
       AEGIS <xref target="I-D.irtf-cfrg-aegis-aead" format="default"/>, Ascon
       <xref target="DEMS21a" format="default"/><xref format="default"/> <xref target="DEMS21b" format="default"/>.
					</t>
					<t>
						Applications: VoIP,
       format="default"/></dd>
       <dt>Applications:</dt><dd>Voice over IP (VoIP), real-time streaming in a lightweight
       setting, applications that require small ciphertext expansion (i.e.,
       short tags).
					</t>
					<t>
						Further reading: <xref tags)</dd>
       <dt>Further reading:</dt><dd><xref target="BC09" format="default" />, <xref target="FLLW17" format="default" />.
					</t> /></dd>
     </dl>
   </section>
   <section anchor="RUP" numbered="true" toc="default">
     <name>Release of Unverified Plaintext (RUP) Integrity</name>
					<t>
						Definition: An
     <dl spacing="normal" newline="true">

<!-- [rfced] FYI - We made minor changes to the quoted text (lowercased "the"
and changed "beyond" to "besides") to exactly match the text at [A14].

Original:
   In [A14], the notion of 'Plaintext
   Awareness' is introduced, capturing the best possible
   confidentiality under RUP in the following sense: 'The adversary
   cannot gain any additional knowledge about the plaintext from
   decryption queries beyond what it can derive from encryption
   queries'.
-->

       <dt>Definition:</dt><dd>An AEAD algorithm provides data integrity even
       if plaintext is released for every ciphertext, including those with
       failed integrity verification.
					</t>
					<t>
						Security notion: INT-RUP verification.</dd>
       <dt>Security notion:</dt><dd>INT-RUP <xref target="A14" format="default" />.
					</t>
					<t>
						Examples: GCM-RUP /></dd>
       <dt>Examples:</dt><dd>GCM-RUP <xref target="ADL17" format="default" />.
					</t>
					<t>
						Applications: Decryption /></dd>
       <dt>Applications:</dt><dd>Decryption with limited memory <xref
       target="FJMV2004" format="default" />, real-time streaming protocols.
					</t>
					<t>
						Notes: In protocols</dd>
       <dt>Notes:</dt><dd><t>In <xref target="ADL17" format="default"/> format="default"/>, a generic
       approach to achieve INT-RUP security is introduced.
					</t>
					<t>
						In introduced.</t>
       <t>In the provided definition, we only consider integrity in the RUP
       setting, since confidentiality, in the usual sense, is unachievable
       under RUP. In <xref target="A14" format="default" />, the notion of 'Plaintext Awareness'
       "Plaintext Awareness" is introduced, capturing the best possible
       confidentiality under RUP in the following sense: 'The "the adversary cannot
       gain any additional knowledge about the plaintext from decryption
       queries beyond besides what it can derive from encryption queries'.
					</t>
					<t>
						Further reading: <xref queries".</t>
     </dd>
     <dt>Further reading:</dt><dd><xref target="A14" format="default" />,
     <xref target="ADL17" format="default" />.
					</t> /></dd>
     </dl>
   </section>
 </section>
 <section anchor="ImpProp" numbered="true" toc="default">
   <name>Implementation Properties</name>

   <section anchor="HardEff" numbered="true" toc="default">
     <name>Hardware efficient</name>
					<t>
						Definition: An Efficient</name>
     <dl newline="true" spacing="normal">
       <dt>Definition:</dt><dd>An AEAD algorithm ensures optimal performance
       when operating on hardware that complies with the specified requirements.
					</t>
					<t>
						Notes: Various
       requirements.</dd>
       <dt>Notes:</dt><dd>Various classes of hardware may be taken into
       consideration. Certain algorithms are tailored to minimize the area of
       dedicated hardware implementations, while others are intended to
       capitalize on general-purpose CPUs, with or without specific
       instruction sets. It is RECOMMENDED <bcp14>RECOMMENDED</bcp14> to specify the
       minimum platform requirements for the AEAD to fulfill its intended
       purpose, as well as to match its performance and security claims.
					</t> claims.</dd>
     </dl>
   </section>

   <section anchor="Inverse" numbered="true" toc="default">
     <name>Inverse-Free</name>
					<t>
						Definition: An
     <dl newline="true" spacing="normal">
       <dt>Definition:</dt><dd>An AEAD algorithm based on a given primitive
       can be implemented without invoking the inverse of that primitive.
					</t>
					<t>
						Examples: AES-GCM primitive.</dd>
       <dt>Examples:</dt><dd>AES-GCM <xref target="D07" format="default"/>,
       ChaCha20-Poly1305 <xref target="RFC8439" format="default"/>, OCB <xref
       target="RFC7253" format="default"/>, MGM <xref target="RFC9058"
       format="default"/>, AEGIS <xref target="I-D.irtf-cfrg-aegis-aead" format="default"/>.
					</t>
					<t>
						Notes: In
       format="default"/></dd>
       <dt>Notes:</dt><dd>In a sponge-based AEAD algorithm, an underlying
       permutation is viewed as a primitive.
					</t> primitive.</dd>
     </dl>
   </section>
   <section anchor="Lightweight" numbered="true" toc="default">
     <name>Lightweight</name>
					<t>
						Definition: An
     <dl newline="true" spacing="normal">
       <dt>Definition:</dt><dd>An AEAD algorithm can be efficiently and
       securely implemented on resource-constrained devices. In particular, it
       meets the criteria required in the NIST Lightweight Cryptography
       competition <xref target="MBTM17" format="default" />.
					</t>
					<t>
						Examples: OCB />.</dd>
       <dt>Examples:</dt><dd>OCB <xref target="RFC7253" format="default"/>,
       Ascon <xref target="DEMS21a" format="default"/><xref target="DEMS21b" format="default"/>.
					</t>
					<t>
						Further reading: format="default"/> <xref target="DEMS21b"
       format="default"/></dd>
       <dt>Further reading:</dt><dd><xref target="MBTM17" format="default" />.
					</t> /></dd>
     </dl>
   </section>
   <section anchor="Parallelizable" numbered="true" toc="default">
     <name>Parallelizable</name>
					<t>
						Definition: An
     <dl newline="true" spacing="normal">
       <dt>Definition:</dt><dd>An AEAD algorithm can fully exploit the parallel
       computation infrastructure. In other words, a parallelizable AEAD
       algorithm allows for the computation of ciphertext segments (plaintext
       segments for decryption) in parallel, meaning that ciphertext segments
       are computed independently.
					</t>
					<t>
						Synonyms: Pipelineable.
					</t>
					<t>
						Examples: AES-GCM independently.</dd>
       <dt>Synonyms:</dt><dd>Pipelineable</dd>
       <dt>Examples:</dt><dd>AES-GCM <xref target="D07" format="default"/>,
       ChaCha20-Poly1305 <xref target="RFC8439" format="default"/>, OCB <xref
       target="RFC7253" format="default"/>, MGM <xref target="RFC9058"
       format="default"/>, AEGIS <xref target="I-D.irtf-cfrg-aegis-aead" format="default"/>.
					</t>
					<t>
						Further reading: <xref
       format="default"/></dd>
       <dt>Further reading:</dt><dd><xref target="C20" format="default" />.
					</t> /></dd>
     </dl>
   </section>
   <section anchor="SetupFree" numbered="true" toc="default">
     <name>Setup-Free</name>
					<t>
						Definition: An
     <dl newline="true" spacing="normal">
       <dt>Definition:</dt><dd>An AEAD algorithm's operations can be
       implemented in a way that using a new key incurs either no overhead or
       negligible overhead compared to the reuse of a previous key. Overhead
       may involve additional computations or increased storage space, such as
       precomputing a key schedule for a block cipher.
					</t>
					<t>
						Examples: ChaCha20-Poly1305 cipher.</dd>
       <dt>Examples:</dt><dd>ChaCha20-Poly1305 <xref target="RFC8439"
       format="default"/>, AEGIS <xref target="I-D.irtf-cfrg-aegis-aead"
       format="default"/>, Ascon <xref target="DEMS21a" format="default"/><xref
       format="default"/> <xref target="DEMS21b" format="default"/>.
					</t> format="default"/></dd>
     </dl>
   </section>
   <section anchor="SinglePass" numbered="true" toc="default">
     <name>Single Pass</name>
					<t>
						Definition: An
     <dl newline="true" spacing="normal">

       <dt>Definition:</dt><dd>An AEAD algorithm encryption (decryption)
       operation can be implemented with a single pass over the plaintext (ciphertext).
					</t>
					<t>
						Examples: AES-GCM
       (ciphertext).</dd>
       <dt>Examples:</dt><dd>AES-GCM <xref target="D07" format="default"/>,
       ChaCha20-Poly1305 <xref target="RFC8439" format="default"/>, OCB <xref
       target="RFC7253" format="default"/>, MGM <xref target="RFC9058"
       format="default"/>, AEGIS <xref target="I-D.irtf-cfrg-aegis-aead" format="default"/>.
					</t>
       format="default"/></dd>
     </dl>
   </section>
   <section anchor="StaticAD" numbered="true" toc="default">
     <name>Static Associated Data Efficient</name>
					<t>
						Definition: An
     <dl newline="true" spacing="normal">
       <dt>Definition:</dt><dd>An AEAD algorithm allows pre-computation precomputation for
       static (or repeating) associated data so that static associated data
       doesn't significantly contribute to the computational cost of encryption.
					</t>
					<t>
						Examples: AES-GCM
       encryption.</dd>
       <dt>Examples:</dt><dd>AES-GCM <xref target="D07" format="default"/>,
       ChaCha20-Poly1305 <xref target="RFC8439" format="default"/>, OCB <xref
       target="RFC7253" format="default"/>.
					</t> format="default"/></dd>
     </dl>
   </section>
   <section anchor="Online" numbered="true" toc="default">
     <name>Streamable</name>
					<t>
						Definition: An
     <dl newline="true" spacing="normal">
       <dt>Definition:</dt><dd>An AEAD algorithm encryption (decryption)
       operation can be implemented with constant memory usage and a single
       one-direction pass over the plaintext (ciphertext), writing out the
       result during that pass.
					</t>
					<t>
						Synonyms: Online.
					</t>
					<t>
						Examples: AES-GCM pass.</dd>
       <dt>Synonyms:</dt><dd>Online</dd>
       <dt>Examples:</dt><dd>AES-GCM <xref target="D07" format="default"/>,
       ChaCha20-Poly1305 <xref target="RFC8439" format="default"/>, OCB <xref
       target="RFC7253" format="default"/>, MGM <xref target="RFC9058"
       format="default"/>, AEGIS <xref target="I-D.irtf-cfrg-aegis-aead"
       format="default"/>, Ascon <xref target="DEMS21a" format="default"/><xref
       format="default"/> <xref target="DEMS21b" format="default"/>.
					</t>
					<t>
						Applications: Real-time format="default"/></dd>
       <dt>Applications:</dt><dd>Real-time streaming protocols, resource-constrained devices.
					</t>
					<t>
						Notes: Blockwise devices</dd>
       <dt>Notes:</dt><dd>Blockwise security (see <xref target="BWsec"
       format="default" />) and RUP integrity (see <xref target="RUP"
       format="default" />) might be relevant security properties for
       streamable AEAD algorithms in certain applications.
					</t>
					<t>
						Further reading: <xref applications.</dd>
       <dt>Further reading:</dt><dd><xref target="HRRV15" format="default" />,
       <xref target="FJMV2004" format="default" />.
					</t> /></dd>
     </dl>
   </section>
 </section>
</section>
<section anchor="Security" numbered="true" toc="default">
  <name>Security Considerations</name>
			<t>
				This document gives high-level definitions of AEAD properties. For each security property, we provide an informational reference to a game-based security notion (or security notions if there are separate notions for integrity and confidentiality) that formalizes the property. We only consider game-based notions and security properties that can be formalized using this approach. However, there are different approaches to formalizing AEAD security, like the indifferentiability framework <xref target="BM18" format="default" />; security in such notions should be studied separately.
			</t>
			<t>
				For some properties, examples of AEAD algorithms that provide them are given, with standardized AEAD algorithms preferred for commonly encountered properties. However, for certain properties, only non-standardized algorithms exist. Implementing such algorithms requires careful consideration, and it is advised to contact the algorithm designers for reference implementations and implementation guidelines.
			</t>

			<t>
			  Every claimed security property of an AEAD algorithm MUST
			  <bcp14>MUST</bcp14> undergo security analysis within
			  a relevant notion. It's RECOMMENDED <bcp14>RECOMMENDED</bcp14>
			  to use the security notions referenced in the
			  document. If an alternative notion is used, there MUST exist proof of
			  equivalence <bcp14>MUST</bcp14> exist, or it SHOULD be indicated that use of a
			  non-equivalent notion is used. <bcp14>SHOULD</bcp14> be
			  indicated. For security properties that extend
			  adversarial capabilities, consideration of integrity
			  and confidentiality separately may be relevant. If
			  the algorithm provides only one of these, that SHOULD
			  <bcp14>SHOULD</bcp14> be indicated.
			</t>

<!-- [rfced] How may we clarify "as should all trade-offs be"?

Original:
   In an
   application, the requirements for additional AEAD properties SHOULD
   be highly motivated and justified, as should all trade-offs be
   carefully considered.

Perhaps:
   In an
   application, the requirements for additional AEAD properties SHOULD
   be highly motivated and justified, and all trade-offs should be
   carefully considered.

Or:
   In an
   application, the requirements for additional AEAD properties SHOULD
   be highly motivated and justified, as all trade-offs should be
   carefully considered.
-->

			<t>
				When specifying security requirements for an AEAD algorithm in an application, it SHOULD <bcp14>SHOULD</bcp14> be indicated, for every required security property, whether only integrity or confidentiality is necessary. Additionally, for each security property, it SHOULD <bcp14>SHOULD</bcp14> be specified whether an analysis in an alternative security notion is required. We also note that some additional properties come with trade-offs in terms of classical security and efficiency, and they may only be supported in non-standardized or modified AEAD algorithms. This immediately implies challenges in deployment and interoperability. In an application, the requirements for additional AEAD properties SHOULD <bcp14>SHOULD</bcp14> be highly motivated and justified, as should all trade-offs be carefully considered.
			</t>
		</section>
		<section anchor="IANACON" numbered="true" toc="default">
			<name>IANA Considerations</name>
			<t>This document has no IANA actions.</t>
		</section>
	</middle>
	<back>

	  <displayreference target="I-D.irtf-cfrg-aead-limits" to="AEAD-LIMITS"/>
	  <displayreference target="I-D.irtf-cfrg-aegis-aead" to="AEGIS-AEAD"/>
	  <references>
	    <name>References</name>
	    <references>
	      <name>Normative References</name>
	      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml" href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml" />
	      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml" href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml" />
	      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5116.xml" href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5116.xml" />
	      <reference anchor="D07" target="https://csrc.nist.gov/pubs/sp/800/38/d/final">
		<front>
		  <title>Recommendation for Block Cipher Modes of Operation: Galois/Counter
		  Mode (GCM) and GMAC</title>
		  <author initials="M." surname="Dworkin" fullname="Morris Dworkin" />
		  <date year="2007" />
		</front>
		<seriesInfo name="NIST SP" value="800-38D"/>
		<seriesInfo name="DOI" value="10.6028/NIST.SP.800-38D" />
					<refcontent>NIST Special Publication 800-38D</refcontent>
	      </reference>
	    </references>
	    <references>
	      <name>Informative References</name>

	      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml" />
	      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4303.xml" />
	      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8221.xml" />
	      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9000.xml" />
<!--				<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5652.xml" />-->

	      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8439.xml" />
	      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8645.xml" />
	      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8452.xml" />
	      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7253.xml" />
	      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9058.xml" />

	      <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-irtf-cfrg-aead-limits.xml" href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.irtf-cfrg-aead-limits.xml" />

	      <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-irtf-cfrg-aegis-aead.xml" href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.irtf-cfrg-aegis-aead.xml" />

	      <reference anchor="R02">
		<front>
		  <title>Authenticated-encryption with associated-data</title>
		  <author initials="P." surname="Rogaway" fullname="Phillip Rogaway" />
		  <date year="2002" />
		</front>
		<seriesInfo name="DOI" value="10.1145/586110.586125" />
		<refcontent>Proceedings of the 9th ACM conference Conference on Computer and communications security Communications Security (CCS '02)</refcontent>
					<refcontent>Association for Computing Machinery, New York, NY, USA, 98–107</refcontent> '02), pp. 98-107</refcontent>
	      </reference>
<!-- [rfced] The URL in this reference entry points to a 2008 publication of
the paper, but the information in the reference entry is for a 2000
publication. Which would you like to cite?

2008 - https://doi.org/10.1007/s00145-008-9026-x
2000 - https://doi.org/10.1007/3-540-44448-3_41

Original:
   [BN2000]   Bellare, M. and C. Namprempre, "Authenticated Encryption:
              Relations among Notions and Analysis of the Generic
              Composition Paradigm", Proceedings of ASIACRYPT 2000,
              Springer-Verlag, LNCS 1976, pp. 531-545,
              DOI 10.1007/s00145-008-9026-x, 2000,
              <https://doi.org/10.1007/s00145-008-9026-x>.

Perhaps (1) - 2000 paper:
   [BN2000]   Bellare, M. and C. Namprempre, "Authenticated Encryption:
              Relations among Notions and Analysis of the Generic
              Composition Paradigm", Advances in Cryptology - ASIACRYPT
              2000, Lecture Notes in Computer Science, vol. 1976, pp.
              531-545, DOI 10.1007/3-540-44448-3_41, 2000,
              <https://doi.org/10.1007/3-540-44448-3_41>.

Perhaps (2) - 2008 paper:
   [BN2000]   Bellare, M. and C. Namprempre, "Authenticated Encryption:
              Relations among Notions and Analysis of the Generic
              Composition Paradigm", Journal of Cryptology, vol. 21,
              pp. 469–491,
              DOI 10.1007/s00145-008-9026-x, July 2008,
              <https://doi.org/10.1007/s00145-008-9026-x>.
-->
	      <reference anchor="BN2000">
		<front>
		  <title>Authenticated Encryption: Relations among Notions and Analysis of the Generic Composition Paradigm</title>
		  <author initials="M." surname="Bellare" fullname="Mihir Bellare" />
		  <author initials="C." surname="Namprempre" fullname="Chanathip Namprempre" />
		  <date year="2000" />
		</front>
		<seriesInfo name="DOI" value="10.1007/s00145-008-9026-x" />
					<refcontent>Proceedings of value="10.1007/3-540-44448-3_41"/>
		<refcontent>Advances in Cryptology - ASIACRYPT 2000, Springer-Verlag, LNCS Lecture Notes in Computer Science, vol. 1976, pp. 531-545</refcontent>
	      </reference>

	      <reference anchor="JMV2002">
		<front>
		  <title>Blockwise-Adaptive Attackers Revisiting the (In)Security of Some Provably Secure Encryption Modes: CBC, GEM, IACBC</title>
		  <author initials="A." surname="Joux" fullname="Antoine Joux" />
		  <author initials="G." surname="Martinet" fullname="Gwenaelle Martinet" />
		  <author initials="F." surname="Valette" fullname="Frederic Valette" />
		  <date year="2002" />
		</front>
		<seriesInfo name="DOI" value="10.1007/3-540-45708-9_2" />
		<refcontent>Advances in Cryptology — CRYPTO 2002. - CRYPTO 2002. 2002, Lecture Notes in Computer Science, vol 2442. Springer, Berlin, Heidelberg</refcontent> vol. 2442</refcontent>
	      </reference>

	      <reference anchor="FJMV2004">
		<front>
		  <title>Authenticated On-Line Encryption</title>
		  <author initials="PA." initials="P.-A." surname="Fouque" fullname="Pierre-Alain Fouque" />
		  <author initials="A." surname="Joux" fullname="Antoine Joux" />
		  <author initials="G." surname="Martinet" fullname="Gwenaelle Martinet" />
		  <author initials="F." surname="Valette" fullname="Frederic Valette" />
		  <date year="2004" />
		</front>
		<seriesInfo name="DOI" value="10.1007/978-3-540-24654-1_11" />
		<refcontent>Selected Areas in Cryptography. SAC 2003. Lecture Notes in Computer Science, vol 3006. Springer, Berlin, Heidelberg.</refcontent>
				</reference>
<!--				<reference anchor="BK2011">
					<front>
						<title>Authenticated and Misuse-Resistant Encryption of Key-Dependent Data</title>
						<author initials="M." surname="Bellare" fullname="Mihir Bellare" />
						<author initials="S." surname="Keelveedhi" fullname="Sriram Keelveedhi" />
						<date year="2011" />
					</front>
					<seriesInfo name="DOI" value="10.1007/978-3-642-22792-9_35" />
					<refcontent>Advances in Cryptology - CRYPTO 2011. CRYPTO 2011. Cryptography (SAC 2003), Lecture Notes in Computer Science, vol 6841. Springer, Berlin, Heidelberg.</refcontent> vol. 3006</refcontent>
	      </reference>
-->

	      <reference anchor="FOR17">
		<front>
		  <title>Security of Symmetric Primitives under Incorrect Usage of Keys</title>
		  <author initials="P." surname="Farshim" fullname="Pooya Farshim" />
		  <author initials="C." surname="Orlandi" fullname="Claudio Orlandi" />
		  <author initials="R." surname="Rosie" fullname="Razvan Rosie" />
		  <date year="2017" />
		</front>
		<seriesInfo name="DOI" value="10.13154/tosc.v2017.i1.449-473" />
		<refcontent>IACR Transactions on Symmetric Cryptology, 2017(1), 449–473.</refcontent> vol. 2017, no. 1, pp. 449-473</refcontent>
	      </reference>

	      <reference anchor="LGR21">
		<front>
		  <title>Partitioning Oracle Attacks</title>
		  <author initials="J." surname="Len" fullname="Julia Len" />
		  <author initials="P." surname="Grubbs" fullname="Paul Grubbs" />
		  <author initials="T." surname="Ristenpart" fullname="Thomas Ristenpart" />
		  <date year="2021" />
		</front>
		<refcontent>30th USENIX Security Symposium (USENIX Security 21), 195--212</refcontent> pp. 195-212</refcontent>
	      </reference>

	      <reference anchor="GLR17">
		<front>
		  <title>Message Franking via Committing Authenticated Encryption</title>
		  <author initials="P." surname="Grubbs" fullname="Paul Grubbs" />
		  <author initials="J." surname="Lu" fullname="Jiahui Lu" />
		  <author initials="T." surname="Ristenpart" fullname="Thomas Ristenpart" />
		  <date year="2017" />
		</front>
		<seriesInfo name="DOI" value="10.1007/978-3-319-63697-9_3" />
		<refcontent>Advances in Cryptology – CRYPTO 2017. - CRYPTO 2017. 2017, Lecture Notes in Computer Science, vol 10403. Springer, Cham</refcontent> vol. 10403, pp. 66-97</refcontent>
	      </reference>

	      <reference anchor="B20">
		<front>
		  <title>Mode-Level vs. Implementation-Level Physical Security in Symmetric Cryptography: A Practical Guide Through the Leakage-Resistance Jungle</title>
		  <author initials="D." surname="Bellizia" fullname="Davide Bellizia" />
		  <author initials="O." surname="Bronchain" fullname="Olivier Bronchain" />
		  <author initials="G." surname="Cassiers" fullname="Gaëtan Cassiers" />
		  <author initials="V." surname="Grosso" fullname="Vincent Grosso" />
		  <author initials="C." surname="Guo" fullname="Chun Guo" />
		  <author initials="C." surname="Momin" fullname="Charles Momin" />
		  <author initials="O." surname="Pereira" fullname="Olivier Pereira" />
		  <author initials="T." surname="Peters" fullname="Thomas Peters" />
		  <author initials="FX." initials="F.-X." surname="Standaert" fullname="François-Xavier Standaert" />
		  <date year="2020" />
		</front>
		<seriesInfo name="DOI" value="10.1007/978-3-030-56784-2_13" />
		<refcontent>Advances in Cryptology – CRYPTO 2020. - CRYPTO 2020. 2020, Lecture Notes in Computer Science, vol. 12170, pp. 369-400</refcontent>
	      </reference>

<!-- [rfced] FYI - We updated the title in the reference entry to match the
title in the provided URL.

Original;
   [GPPS19]   Guo, C., Pereira, O., Peters, T., and FX. Standaert,
              "Authenticated Encryption with Nonce Misuse and Physical
              Leakages: Definitions, Separation Results and Leveled
              Constructions", Progress in Cryptology - LATINCRYPT 2019.
              LATINCRYPT 2019. Lecture Notes in Computer Science, vol 12170.
              11774. Springer, Cham</refcontent>
				</reference> Cham, DOI 10.1007/978-3-030-30530-7_8,
              2019, <https://doi.org/10.1007/978-3-030-30530-7_8>.

Updated:
   [GPPS19]   Guo, C., Pereira, O., Peters, T., and F.-X. Standaert,
              "Authenticated Encryption with Nonce Misuse and Physical
              Leakages: Definitions, Separation Results and First
              Construction", Progress in Cryptology - LATINCRYPT 2019,
              Lecture Notes in Computer Science, vol. 11774, pp.
              150-172, DOI 10.1007/978-3-030-30530-7_8, 2019,
              <https://doi.org/10.1007/978-3-030-30530-7_8>.
-->
	      <reference anchor="GPPS19">
		<front>
		  <title>Authenticated Encryption with Nonce Misuse and Physical Leakages: Definitions, Separation Results and Leveled Constructions</title> First Construction</title>
		  <author initials="C." surname="Guo" fullname="Chun Guo" />
		  <author initials="O." surname="Pereira" fullname="Olivier Pereira" />
		  <author initials="T." surname="Peters" fullname="Thomas Peters" />
		  <author initials="FX." initials="F.-X." surname="Standaert" fullname="François-Xavier Standaert" />
		  <date year="2019" />
		</front>
		<seriesInfo name="DOI" value="10.1007/978-3-030-30530-7_8" />
		<refcontent>Progress in Cryptology - LATINCRYPT 2019. LATINCRYPT 2019. 2019, Lecture Notes in Computer Science, vol 11774. Springer, Cham</refcontent> vol. 11774, pp. 150-172</refcontent>
	      </reference>

	      <reference anchor="BT16">
		<front>
		  <title>The Multi-User Multi-user Security of Authenticated Encryption: AES-GCM in TLS 1.3</title>
		  <author initials="M." surname="Bellare" fullname="Mihir Bellare" />
		  <author initials="B." surname="Tackmann" fullname="Björn Tackmann" />
		  <date year="2016" />
		</front>
		<seriesInfo name="DOI" value="10.1007/978-3-662-53018-4_10" />
		<refcontent>Advances in Cryptology – CRYPTO 2016. - CRYPTO 2016. 2016, Lecture Notes in Computer Science, vol 9814. Springer, Berlin, Heidelberg</refcontent> vol. 9814, pp. 247-276</refcontent>
	      </reference>

	      <reference anchor="RS06">
		<front>
		  <title>A Provable-Security Treatment of the Key-Wrap Problem</title>
		  <author initials="R." surname="Rogaway" fullname="Phillip Rogaway" />
		  <author initials="T." surname="Shrimpton" fullname="Thomas Shrimpton" />
		  <date year="2016" />
		</front>
		<seriesInfo name="DOI" value="10.1007/11761679_23" />
		<refcontent>Advances in Cryptology - EUROCRYPT 2006. EUROCRYPT 2006. 2006, Lecture Notes in Computer Science, vol 4004. Springer, Berlin, Heidelberg</refcontent> vol. 4004, pp. 373-390</refcontent>
	      </reference>

	      <reference anchor="ADL17">
		<front>
		  <title>Boosting Authenticated Encryption Robustness with Minimal Modifications</title>
		  <author initials="T." surname="Ashur" fullname="Tomer Ashur" />
		  <author initials="O." surname="Dunkelman" fullname="Orr Dunkelman" />
		  <author initials="A." surname="Luykx" fullname="Atul Luykx" />
		  <date year="2017" />
		</front>
		<seriesInfo name="DOI" value="10.1007/978-3-319-63697-9_1" />
		<refcontent>Advances in Cryptology – CRYPTO 2017. - CRYPTO 2017. 2017, Lecture Notes in Computer Science, vol 10403. Springer, Cham</refcontent> vol. 10403, pp. 3-33</refcontent>
	      </reference>

	      <reference anchor="FLLW17">
		<front>
		  <title>Reforgeability of Authenticated Encryption Schemes</title>
		  <author initials="C." surname="Forler" fullname="Christian Forler" />
		  <author initials="E." surname="List" fullname="Eik List" />
		  <author initials="S." surname="Lucks" fullname="Stefan Lucks" />
		  <author initials="J." surname="Wenzel" fullname="Jakob Wenzel" />
		  <date year="2017" />
		</front>
		<seriesInfo name="DOI" value="10.1007/978-3-319-59870-3_2" />
		<refcontent>Information Security and Privacy. ACISP 2017. Privacy (ACISP 2017), Lecture Notes in Computer Science, vol 10343. Springer, Cham</refcontent> vol. 10343, pp. 19-37</refcontent>
	      </reference>

	      <reference anchor="BC09">
		<front>
		  <title>MAC Reforgeability</title>
		  <author initials="J." surname="Black" fullname="John Black" />
		  <author initials="M." surname="Cochran" fullname="Martin Cochran" />
		  <date year="2009" />
		</front>
		<seriesInfo name="DOI" value="10.1007/978-3-642-03317-9_21" />
		<refcontent>Fast Software Encryption. FSE 2009. Encryption (FSE 2009), Lecture Notes in Computer Science, vol 5665. Springer, Berlin, Heidelberg</refcontent> vol. 5665, pp. 345-362</refcontent>
	      </reference>

	      <reference anchor="A14">
		<front>
		  <title>How to Securely Release Unverified Plaintext in Authenticated Encryption</title>
		  <author initials="E." surname="Andreeva" fullname="Elena Andreeva" />
		  <author initials="A." surname="Bogdanov" fullname="Andrey Bogdanov" />
		  <author initials="A." surname="Luykx" fullname="Atul Luykx" />
		  <author initials="B." surname="Mennink" fullname="Bart Mennink" />
		  <author initials="N." surname="Mouha" fullname="Nicky Mouha" />
		  <author initials="K." surname="Yasuda" fullname="Kan Yasuda " />
		  <date year="2014" />
		</front>
		<seriesInfo name="DOI" value="10.1007/978-3-662-45611-8_6" />
		<refcontent>Advances in Cryptology – ASIACRYPT 2014. - ASIACRYPT 2014. 2014, Lecture Notes in Computer Science, vol 8873. Springer, Berlin, Heidelberg</refcontent> vol. 8873, pp. 105-125</refcontent>
	      </reference>

	      <reference anchor="MBTM17">
		<front>
		  <title>Report on Lightweight Cryptography</title>
		  <author initials="K." surname="McKay" fullname="Kerry A. McKay" />
		  <author initials="L." surname="Bassham" fullname="Larry Bassham" />
		  <author initials="MS." surname="Turan" fullname="Meltem Sönmez Turan" />
		  <author initials="N." surname="Mouha" fullname="Nicky Mouha" />
		  <date year="2017" />
		</front>
		<seriesInfo name="NISTIR" value="8114"/>
		<seriesInfo name="DOI" value="10.6028/NIST.IR.8114" />
	      </reference>

	      <reference anchor="HRRV15">
		<front>
		  <title>Online Authenticated-Encryption and its Nonce-Reuse Misuse-Resistance</title>
		  <author initials="VT." surname="Hoang" fullname="Viet Tung Hoang" />
		  <author initials="R." surname="Reyhanitabar" fullname="Reza Reyhanitabar" />
		  <author initials="P." surname="Rogaway" fullname="Phillip Rogaway" />
		  <author initials="D." surname="Vizár" fullname="Damian Vizár" />
		  <date year="2015" />
		</front>
		<seriesInfo name="DOI" value="10.1007/978-3-662-47989-6_24" />
		<refcontent>Advances in Cryptology -- CRYPTO 2015. CRYPTO 2015. 2015, Lecture Notes in Computer Science, vol 9215. Springer, Berlin, Heidelberg</refcontent> vol. 9215, pp. 493-517</refcontent>
	      </reference>

	      <reference anchor="C20">
		<front>
		  <title>INT-RUP Secure Lightweight Parallel AE Modes</title>
		  <author initials="A." surname="Chakraborti" fullname="Avik Chakraborti" />
		  <author initials="N." surname="Datta" fullname="Nilanjan Datta" />
		  <author initials="A." surname="Jha" fullname="Ashwin Jha" />
		  <author initials="C." surname="Mancillas-López" fullname="Cuauhtemoc Mancillas-López" />
		  <author initials="M." surname="Nandi" fullname="Mridul Nandi" />
		  <author initials="Y." surname="Sasaki" fullname="Yu Sasaki" />
		  <date year="2020" />
		</front>
		<seriesInfo name="DOI" value="10.13154/tosc.v2019.i4.81-118" />
		<refcontent>IACR Transactions on Symmetric Cryptology, 2019(4), 81–118</refcontent>
				</reference>
<!--
					<reference anchor="DGGK21">
					<front>
						<title>CIMINION: Symmetric Encryption Based on Toffoli-Gates over Large Finite Fields</title>
						<author initials="C." surname="Dobraunig" fullname="Christoph Dobraunig" />
						<author initials="L." surname="Grassi" fullname="Lorenzo Grassi" />
						<author initials="G." surname="Guinet" fullname="Anna Guinet" />
						<author initials="D." surname="Kuijsters" fullname="Daniël Kuijsters" />
						<date year="2021" />
					</front>
					<seriesInfo name="DOI" value="10.1007/978-3-030-77886-6_1" />
					<refcontent>Advances in Cryptology - EUROCRYPT 2021. EUROCRYPT 2021. Lecture Notes in Computer Science(), vol 12697. Springer, Cham</refcontent> vol. 2019, no.4, pp. 81-118</refcontent>
	      </reference>
-->

	      <reference anchor="BKY02">
		<front>
		  <title>Incremental Unforgeable Encryption</title>
		  <author initials="E." surname="Buonanno" fullname="Enrico Buonanno" />
		  <author initials="J." surname="Katz" fullname="Jonathan Katz" />
		  <author initials="M." surname="Yung" fullname="Moti Yung" />
		  <date year="2002" />
		</front>
		<seriesInfo name="DOI" value="10.1007/3-540-45473-X_9" />
		<refcontent>Fast Software Encryption. FSE 2001. Encryption (FSE 2001), Lecture Notes in Computer Science, vol 2355. Springer, Berlin, Heidelberg</refcontent> vol. 2355, pp. 109-124</refcontent>
	      </reference>

	      <reference anchor="SY16">
		<front>
		  <title>A New Mode of Operation for Incremental Authenticated Encryption with Associated Data</title>
		  <author initials="Y." surname="Sasaki" fullname="Yu Sasaki" />
		  <author initials="K." surname="Yasuda" fullname="Kan Yasuda" />
		  <date year="2016" />
		</front>
		<seriesInfo name="DOI" value="10.1007/978-3-319-31301-6_23" />
		<refcontent>Selected Areas in Cryptography – SAC 2015. - SAC 2015. 2015, Lecture Notes in Computer Science, vol 9566. Springer, Cham</refcontent> vol. 9566, pp. 397-416</refcontent>
	      </reference>

	      <reference anchor="BNT19">
		<front>
		  <title>Nonces Are Noticed: AEAD Revisited</title>
		  <author initials="M." surname="Bellare" fullname="Mihir Bellare" />
		  <author initials="R." surname="Ng" fullname="Ruth Ng" />
		  <author initials="B." surname="Tackmann" fullname="Björn Tackmann" />
		  <date year="2019" />
		</front>
		<seriesInfo name="DOI" value="10.1007/978-3-030-26948-7_9" />
		<refcontent>Advances in Cryptology – CRYPTO 2019. - CRYPTO 2019. 2019, Lecture Notes in Computer Science, vol 11692. Springer, Cham</refcontent> vol. 11692, pp. 235-265</refcontent>
	      </reference>

	      <reference anchor="BH22">
		<front>
		  <title>Efficient schemes Schemes for committing authenticated encryption</title> Committing Authenticated Encryption</title>
		  <author initials="M." surname="Bellare" fullname="Mihir Bellare" />
		  <author initials="V.T." surname="Hoang" fullname="Viet Tung Hoang" />
		  <date year="2022" />
		</front>
		<seriesInfo name="DOI" value="10.1007/978-3-031-07085-3_29" />
		<refcontent>Advances in Cryptology – EUROCRYPT 2022. - EUROCRYPT 2022. 2022, Lecture Notes in Computer Science, vol 13276. Springer, Cham.</refcontent> vol. 13276, pp. 845-875</refcontent>
	      </reference>

	      <reference anchor="CR22">
		<front>
		  <title>On Committing Authenticated-Encryption</title>
		  <author initials="J." surname="Chan" fullname="John Chan" />
		  <author initials="P." surname="Rogaway" fullname="Phillip Rogaway" />
		  <date year="2022" />
		</front>
		<seriesInfo name="DOI" value="10.1007/978-3-031-17146-8_14" />
		<refcontent>Computer Security – ESORICS 2022. ESORICS 2022. Lecture Notes in Computer Science, vol 13555. Springer, Cham.</refcontent>
				</reference>
<!--				<reference anchor="BFN98">
					<front>
						<title>A formal treatment of remotely keyed encryption</title>
						<author initials="M." surname="Blaze" fullname="Matt Blaze" />
						<author initials="J." surname="Feigenbaum" fullname="Joan Feigenbaum" />
						<author initials="M." surname="Naor" fullname="Moni Naor" />
						<date year="1998" />
					</front>
					<seriesInfo name="DOI" value="10.1007/BFb0054131" />
					<refcontent>Advances in Cryptology - EUROCRYPT'98. EUROCRYPT 1998. Lecture Notes in Computer Science, vol 1403. Springer, Berlin, Heidelberg</refcontent>
				</reference>
-->
<!--				<reference anchor="DA03">
					<front>
						<title>Concealment and Its Applications to Authenticated Encryption</title>
						<author initials="Y." surname="Dodis" fullname="Yevgeniy Dodis" />
						<author initials="JH." surname="An" fullname="Jee Hea An" />
						<date year="2003" />
					</front>
					<seriesInfo name="DOI" value="10.1007/3-540-39200-9_19" />
					<refcontent>Advances in Cryptology - EUROCRYPT 2003. EUROCRYPT 2003. ESORICS 2022, Lecture Notes in Computer Science, vol 2656. Springer, Berlin, Heidelberg</refcontent> vol. 13555, pp. 275-294</refcontent>
	      </reference>
-->

<reference anchor="HKR2015">
  <front>
    <title>Robust Authenticated-Encryption AEZ and the Problem That It Solves</title>
    <author initials="VT." initials="V.T." surname="Hoang" fullname="Viet Tung Hoang" />
    <author initials="T." surname="Krovetz" fullname="Ted Krovetz" />
    <author initials="P." surname="Rogaway" fullname="Phillip Rogaway" />
    <date year="2015" />
  </front>
  <seriesInfo name="DOI" value="10.1007/978-3-662-46800-5_2" />
  <refcontent>Advances in Cryptology -- EUROCRYPT 2015. EUROCRYPT 2015. 2015, Lecture Notes in Computer Science, vol 9056. Springer, Berlin, Heidelberg.</refcontent> vol. 9056, pp. 15-44</refcontent>
</reference>

<reference anchor="MLGR23">
  <front>
    <title>Context Discovery and Commitment Attacks: How to Break CCM, EAX, SIV, and More</title>
    <author initials="S." surname="Menda" fullname="Sanketh Menda" />
    <author initials="J." surname="Julia" fullname="Julia Len" />
    <author initials="P." surname="Grubbs" fullname="Paul Grubbs" />
    <author initials="T." surname="Ristenpart" fullname="Thomas Ristenpart" />
    <date year="2023" />
  </front>
  <seriesInfo name="DOI" value="10.1007/978-3-031-30634-1_13" />
  <refcontent>Advances in Cryptology – EUROCRYPT 2023. - EUROCRYPT 2023. 2023, Lecture Notes in Computer Science, vol 14007. Springer, Cham.</refcontent> vol. 14007, pp. 379-407</refcontent>
</reference>

<reference anchor="BBCLNSS21">
  <front>
    <title>QCB: Efficient Quantum-Secure Authenticated Encryption</title>
    <author initials="R." surname="Bhaumik" fullname="Ritam Bhaumik" />
    <author initials="X." surname="Bonnetain" fullname="Xavier Bonnetain" />
    <author initials="A." surname="Chailloux" fullname="André Chailloux" />
    <author initials="G." surname="Leurent" fullname="Gaëtan Leurent" />
    <author initials="M." surname="Naya-Plasencia" fullname="María Naya-Plasencia" />
    <author initials="A." surname="Schrottenlohe" surname="Schrottenloher" fullname="André Schrottenlohe" Schrottenloher" />
    <author initials="Y." surname="Seurin" fullname="Yannick Seurin" />
    <date year="2021" />
  </front>
  <seriesInfo name="DOI" value="10.1007/978-3-030-92062-3_23" />
  <refcontent>Advances in Cryptology – ASIACRYPT 2021. - ASIACRYPT 2021. 2021, Lecture Notes in Computer Science(), vol 13090. Springer, Cham.</refcontent> Science, vol. 13090, pp. 668-698</refcontent>
</reference>

<reference anchor="KLLNP16">
  <front>
    <title>Quantum Differential and Linear Cryptanalysis</title>
    <author initials="M." surname="Menda" fullname="Marc Kaplan" />
    <author initials="G." surname="Leurent" fullname="Gaëtan Leurent" />
    <author initials="A." surname="Leverrier" fullname="Anthony Leverrier" />
    <author initials="M." surname="Naya-Plasencia" fullname="María Naya-Plasencia" />
    <date year="2021" year="2016" />
  </front>
  <seriesInfo name="DOI" value="10.13154/tosc.v2016.i1.71-94" />
  <refcontent> IACR Transactions on Symmetric Cryptology, 2016(1), 71–94.</refcontent> vol. 2016, no.1, pp. 71-94</refcontent>
</reference>

<reference anchor="G17" target="https://tuprints.ulb.tu-darmstadt.de/6019/">
  <front>
    <title>Quantum Security of Cryptographic Primitives</title>
    <author initials="T." surname="Gagliardoni" fullname="Tommaso Gagliardoni"/>
    <date year="2017"/>
  </front>
  <refcontent>Ph.D. Thesis, Technische Universität Darmstadt</refcontent>
</reference>

<!-- [rfced] FYI - Per the provided URL, the date for this reference is "2017"
rather than "2016". We updated the reference entry accordingly and also
updated the citation tag from from "[EV16]" to "[EV17]".

Original:
   [EV16]     Endignoux, G. and D. Vizár, "Linking Online Misuse-
              Resistant Authenticated Encryption and Blockwise Attack
              Models", IACR Transactions on Symmetric Cryptology,
              DOI 10.13154/TOSC.V2016.I2.125-144, 2016,
              <https://doi.org/10.13154/TOSC.V2016.I2.125-144>.

Perhaps:
   [EV17]     Endignoux, G. and D. Vizár, "Linking Online Misuse-
              Resistant Authenticated Encryption and Blockwise Attack
              Models", IACR Transactions on Symmetric Cryptology, vol.
              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>.
 -->
<reference anchor="EV16"> anchor="EV17">
  <front>
    <title>Linking Online Misuse-Resistant Authenticated Encryption and Blockwise Attack Models</title>
    <author initials="G." surname="Endignoux" fullname="Guillaume Endignoux"/>
    <author initials="D." surname="Vizár" fullname="Damian Vizár"/>
    <date year="2016"/> year="2017"/>
  </front>
  <seriesInfo name="DOI" value="10.13154/TOSC.V2016.I2.125-144" />
  <refcontent>IACR Transactions on Symmetric Cryptology</refcontent> Cryptology, vol. 2016, no. 2, pp. 125-144</refcontent>
</reference>

<reference anchor="FFL12">
  <front>
    <title>McOE: A family Family of almost foolproof on-line authenticated encryption schemes</title> Almost Foolproof On-Line Authenticated Encryption Schemes</title>
    <author initials="E." surname="Fleischmann" fullname="Ewan Fleischmann"/>
    <author initials="C." surname="Forler" fullname="Christian Forler"/>
    <author initials="S." surname="Lucks" fullname="Stefan Lucks"/>
    <date year="2012"/>
  </front>
  <seriesInfo name="DOI" value="10.1007/978-3-642-34047-5_12" />
  <refcontent>Fast Software Encryption: 19th International Workshop, FSE 2012, Washington, DC, USA, March 19-21, 2012. Revised Selected Papers. Springer Berlin Heidelberg, 2012</refcontent> Encryption (FSE 2012), Lecture Notes in Computer Science, vol. 7549, pp. 196-215</refcontent>
</reference>

<reference anchor="ABV21">
  <front>
						<title>Nonce-misuse security
    <title>Nonce-Misuse Security of the SAEF authenticated encryption mode</title> Authenticated Encryption Mode</title>
    <author initials="E." surname="Andreeva" fullname="Elena Andreeva"/>
    <author initials="A.S." surname="Bhati" fullname="Amit Singh Bhati"/>
    <author initials="D." surname="Vizár" fullname="Damian Vizár"/>
    <date year="2021"/>
  </front>
  <seriesInfo name="DOI" value="10.1007/978-3-030-81652-0_20" />
  <refcontent>Selected Areas in Cryptography: 27th International Conference, Halifax, NS, Canada (Virtual Event), October 21-23, 2020, Revised Selected Papers 27. Springer International Publishing, 2021</refcontent> Cryptography (SAC 2020), Lecture Notes in Computer Science, vol. 12804, pp. 512-534</refcontent>
</reference>

<reference anchor="YSS23">
  <front>
    <title>Committing Security of Ascon: Cryptanalysis on Primitive and Proof on Mode</title>
    <author initials="Y." surname="Naito" fullname="Yusuke Naito"/>
    <author initials="Y." surname="Sasaki" fullname="Yu Sasaki"/>
    <author initials="T." surname="Sugawara" fullname="Takeshi Sugawara"/>
    <date year="2023"/>
  </front>
  <seriesInfo name="DOI" value="10.46586/tosc.v2023.i4.420-451" />
  <refcontent>IACR Transactions on Symmetric Cryptology Cryptology, vol. 2023, no. 4 (2023): 4, pp. 420-451</refcontent>
</reference>

<reference anchor="ADGKLS22">
  <front>
    <title>How to abuse Abuse and fix authenticated encryption without key commitment</title> Fix Authenticated Encryption Without Key Commitment</title>
    <author initials="A." surname="Albertini" fullname="Ange Albertini"/>
    <author initials="T." surname="Duong" fullname="Thai Duong"/>
    <author initials="S." surname="Gueron" fullname="Shay Gueron"/>
    <author initials="S." surname="Kölbl" fullname="Stefan Kölbl"/>
    <author initials="A." surname="Luykx" fullname="Atul Luykx"/>
    <author initials="S." surname="Schmieg" fullname="Sophie Schmieg"/>
    <date year="2022"/>
  </front>
					<refcontent>1st
  <refcontent>31st USENIX Security Symposium (USENIX Security 22), pp. 3291-3308. 2022</refcontent> 3291-3308</refcontent>
</reference>

<reference anchor="BPPS17">
  <front>
    <title>On leakage-resilient authenticated encryption Leakage-Resilient Authenticated Encryption with decryption leakages</title> Decryption Leakages</title>
    <author initials="F." surname="Berti" fullname="Francesco Berti" />
    <author initials="O." surname="Pereira" fullname="Olivier Pereira" />
    <author initials="T." surname="Peters" fullname="Thomas Peters" />
    <author initials="F.X." initials="F.-X." surname="Standaert" fullname="François-Xavier Standaert" />
    <date year="2017" />
  </front>
  <seriesInfo name="DOI" value="10.13154/tosc.v2017.i3.271-293" />
  <refcontent>IACR Transactions on Symmetric Cryptology (2017): Cryptology, vol. 2017, no. 3, pp. 271-293</refcontent>
</reference>

<reference anchor="HTT18">
  <front>
    <title>The multi-user security Multi-user Security of GCM, revisited: Revisited: Tight bounds Bounds for nonce randomization</title> Nonce Randomization</title>
    <author initials="V.T." surname="Hoang" fullname="Viet Tung Hoang" />
    <author initials="S." surname="Tessaro" fullname="Stefano Tessaro" />
    <author initials="A." surname="Thiruvengadam" fullname="Aishwarya Thiruvengadam" />
    <date year="2018" />
  </front>
  <seriesInfo name="DOI" value="10.1145/3243734.3243816" />
  <refcontent>Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security, Security (CCS '18), pp. 1429-1440. 2018</refcontent> 1429-1440</refcontent>
</reference>

<reference anchor="BHT18">
  <front>
    <title>Revisiting AES-GCM-SIV: multi-user security, faster key derivation, Multi-user Security, Faster Key Derivation, and better bounds</title> Better Bounds</title>
    <author initials="P." surname="Bose" fullname="Priyanka Bose" />
    <author initials="V.T." surname="Hoang" fullname="Viet Tung Hoang" />
    <author initials="S." surname="Tessaro" fullname="Stefano Tessaro" />
    <date year="2018" />
  </front>
  <seriesInfo name="DOI" value="10.1007/978-3-319-78381-9_18" />
					<refcontent>Annual International Conference on the Theory and Applications of Cryptographic Techniques,
  <refcontent>Advances in Cryptology - EUROCRYPT 2018, Lecture Notes in Computer Science, vol. 10820, pp. 468-499. Cham: Springer International Publishing, 2018</refcontent> 468-499</refcontent>
</reference>

<reference anchor="LMP17">
  <front>
    <title>Analyzing multi-key security degradation</title> Multi-key Security Degradation</title>
    <author initials="A." surname="Luykx" fullname="Atul Luykx" />
    <author initials="B." surname="Mennink" fullname="Bart Mennink" />
    <author initials="K." surname="Paterson" fullname="Kenneth G. Paterson" />
    <date year="2017" />
  </front>
  <seriesInfo name="DOI" value="10.1007/978-3-319-70697-9_20" />
					<refcontent>Conference on the Theory and Applications of
  <refcontent>Advances in Cryptology and Information Security, Hong Kong, China, December 3-7, - ASIACRYPT 2017, Proceedings, Part II 23, Lecture Notes in Computer Science, vol. 10625, pp. 575-605. Springer International Publishing, 2017.</refcontent> 575-605</refcontent>
</reference>

<reference anchor="DGGP21">
  <front>
    <title>The security Security of ChaCha20-Poly1305 in the multi-user setting</title> Multi-User Setting</title>
    <author initials="J.P." surname="Degabriele" fullname="Jean Paul Degabriele" />
    <author initials="J." surname="Govinden" fullname="Jérôme Govinden" />
    <author initials="F." surname="Günther" fullname="Felix Günther" />
    <author initials="K." surname="Paterson" fullname="Kenneth G. Paterson" />
    <date year="2021" />
  </front>
  <seriesInfo name="DOI" value="10.1145/3460120.3484814" />
					<refcontent>In Proceedings
  <refcontent>Proceedings of the 2021 ACM SIGSAC Conference on Computer and Communications Security, Security (CCS '21), pp. 1981-2003. 2021.</refcontent> 1981-2003</refcontent>
</reference>

<reference anchor="B13" target="https://groups.google.com/d/msg/crypto-competitions/n5ECGwYr6Vk/bsEfPWqSAU4J">
  <front>
    <title>Re: wondering the secret message numbers</title> number</title>
    <author initials="D. J. " surname="Bernstein" fullname="Daniel J. Bernstein" />
    <date year="2013" />
  </front>
  <refcontent>Message in to the Cryptographic Competitions Google group on cryptographic competitions, October 2013.</refcontent> Group</refcontent>
</reference>

<reference anchor="BM18">
  <front>
    <title>Indifferentiable authenticated encryption</title> Authenticated Encryption</title>
    <author initials="M." surname="Barbosa" fullname="Manuel Barbosa" />
    <author initials="P." surname="Farshim" fullname="Pooya Farshim" />
    <date year="2018" />
  </front>
  <seriesInfo name="DOI" value="10.1007/978-3-319-96884-1_7" />
  <refcontent>Advances in Cryptology–CRYPTO 2018: 38th Annual International Cryptology Conference, Santa Barbara, CA, USA, August 19–23, - CRYPTO 2018, Proceedings, Part I 38, Lecture Notes in Computer Science, vol. 10991, pp. 187-220. Springer International Publishing, 2018. </refcontent> 187-220</refcontent>
</reference>

<reference anchor="JNPS21">
  <front>
    <title>The Deoxys AEAD family</title>
    <author initials="M." surname="Jean" fullname="Jérémy Jean" />
    <author initials="I." surname="Nikolić" fullname="Ivica Nikolić" />
    <author initials="T." surname="Peyrin" fullname="Thomas Peyrin" />
    <author initials="Y." surname="Seurin" fullname="Yannick Seurin" />
    <date year="2021" />
  </front>
  <seriesInfo name="DOI" value="10.1007/s00145-021-09397-w" />
  <refcontent>Journal of Cryptology Cryptology, vol. 34, no. 3 (2021): 31.</refcontent> 31</refcontent>
</reference>

<reference anchor="DEMS21a">
  <front>
    <title>Ascon v1.2: Lightweight Authenticated Encryption and Hashing</title>
    <author initials="C." surname="Dobraunig" fullname="Christoph Dobraunig" />
    <author initials="M." surname="Eichlseder" fullname="Maria Eichlseder" />
    <author initials="F." surname="Mendel" fullname="Florian Mendel" />
    <author initials="M." surname="Schläffer" fullname="Martin Schläffer" />
    <date year="2021" />
  </front>
  <seriesInfo name="DOI" value="10.1007/s00145-021-09398-9" />
  <refcontent>Journal of Cryptology 34 (2021): 1-42.</refcontent> Cryptology, vol. 34, no. 33</refcontent>
</reference>

<reference anchor="DEMS21b">
  <front>
    <title>Ascon v1.2</title>
    <author initials="C." surname="Dobraunig" fullname="Christoph Dobraunig" />
    <author initials="M." surname="Eichlseder" fullname="Maria Eichlseder" />
    <author initials="F." surname="Mendel" fullname="Florian Mendel" />
    <author initials="M." surname="Schläffer" fullname="Martin Schläffer" />
    <date year="2021" />
  </front>
  <refcontent>Submission to the NIST LWC Competition</refcontent>
</reference>

<reference anchor="CJRR99">
  <front>
    <title>Towards sound approaches Sound Approaches to counteract power-analysis attacks.</title> Counteract Power-Analysis Attacks</title>
    <author initials="S." surname="Chari" fullname="Suresh Chari" />
    <author initials="C.S." surname="Jutla" fullname="Charanjit S. Jutla" />
    <author initials="J.R." surname="Rao" fullname="Josyula R. Rao" />
    <author initials="P." surname="Rohatgi" fullname="Pankaj Rohatgi" />
    <date year="1999" />
  </front>
  <seriesInfo name="DOI" value="10.1007/3-540-48405-1_26" />
  <refcontent>Advances in Cryptology—CRYPTO'99: 19th Annual International Cryptology Conference Santa Barbara, California, USA, August 15–19, 1999 Proceedings 19, - CRYPTO'99, Lecture Notes in Computer Science, vol. 1666, pp. 398-412. Springer Berlin Heidelberg, 1999.</refcontent> 398-412</refcontent>
</reference>

<reference anchor="M05">
  <front>
    <title>Efficient authentication of large, dynamic data sets using Galois/Counter Mode (GCM).</title> (GCM)</title>
    <author initials="D." surname="McGrew" fullname="David McGrew" />
    <date year="2005" />
  </front>
  <seriesInfo name="DOI" value="10.1109/SISW.2005.3" />
  <refcontent>Third IEEE International Security in Storage Workshop (SISW'05), pp. 6-pp. IEEE, 2005.</refcontent> 6-94</refcontent>
</reference>

<reference anchor="S04" target="https://eprint.iacr.org/2004/272">
  <front>
    <title>A Characterization of Authenticated-Encryption as a Form of Chosen-Ciphertext Security</title>
    <author initials="T." surname="Shrimpton" fullname="Tom Shrimpton" />
    <date year="2004" />
  </front>
  <refcontent>Cryptology ePrint Archive, Paper 2004/272</refcontent>
</reference>

<reference anchor="BMOS17">
  <front>
    <title>Authenticated encryption Encryption in the face Face of protocol Protocol and side channel leakage.</title> Side Channel Leakage</title>
    <author initials="G." surname="Barwell" fullname="Guy Barwell" />
    <author initials="D.P." surname="Martin" fullname="Daniel P. Martin" />
    <author initials="E." surname="Oswald" fullname="Elisabeth Oswald" />
    <author initials="M." surname="Stam" fullname="Martijn Stam" />
    <date year="2017" />
  </front>
  <seriesInfo name="DOI" value="10.1007/978-3-319-70694-8_24" />
  <refcontent>Advances in Cryptology – ASIACRYPT 2017. - ASIACRYPT 2017. 2017, Lecture Notes in Computer Science, vol 10624. Springer, Cham</refcontent> vol. 10624, pp. 693-723</refcontent>
</reference>
</references>
</references>

<section anchor="AddProp" numbered="true" toc="default">
			<name>AEAD Algorithms with Additional Functionality</name>
			<t>
				In this section, we briefly discuss AEAD algorithms that provide additional functionality. As noted in <xref target="Classification" format="default" />, each additional functionality requires a redefinition of the conventional AEAD interface; thus, each additional functionality property defines a new class of cryptographic algorithms.
			</t>

			<t>
				Most importantly, for every Additional Functionality AEAD class, class with additional functionality, conventional security properties must be redefined concerning the targeted additional functionality and the new interface. Although it might be possible to consider a particular Additional Functionality AEAD algorithm with additional functionality as a conventional AEAD algorithm and study it for the conventional confidentiality and integrity, security (or insecurity) in that sense won't be sufficient to label that algorithm as a secure (or insecure) Additional Functionality additional functionality AEAD. Only security in the sense of the redefined conventional properties would suffice.
			</t>
			<t>
				For the examples given in this section, we leave it out of scope how to concretely redefine conventional security for these classes; we only briefly describe the additional functionality they offer and provide further references.
			</t>
 <section anchor="Incremental" numbered="true" toc="default">
   <name>Incremental Authenticated Encryption</name>
				<t>
					Definition:
   <dl spacing="normal" newline="true">

<!-- [rfced] May we update this sentence for clarity?

Original:
   An AEAD algorithm allows re-encrypting and authenticating a
   message (associated data and a plaintext pair), which only partly
   differs from some previous message, faster than processing it from
   scratch.
				</t>
				<t>
					Examples: Incremental

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

     <dt>Definition:</dt><dd>An AEAD algorithm allows re-encrypting and
     authenticating a message (associated data and a plaintext pair), which
     only partly differs from some previous message, faster than processing it
     from scratch.</dd>
     <dt>Examples:</dt><dd>Incremental AEAD algorithm of <xref target="SY16" format="default" />.
				</t>
				<t>
					Security notion: Privacy, Authenticity /></dd>
     <dt>Security notion:</dt><dd>Privacy, authenticity <xref target="SY16" format="default" />.
				</t>
				<t>
					Notes: The /></dd>

     <dt>Notes:</dt><dd>When compared with conventional AEAD, the interface of an incremental AEAD algorithm is
     usually expanded, when compared with conventional AEAD, expanded with several
     operations, which perform different types of updates. For example, one
     can consider such operations such as "Append" or "Chop", which provide a
     straightforward additional functionality. A comprehensive definition of
     an incremental AEAD interface is provided in <xref target="SY16"
     format="default" />.
				</t>
				<t>
					Further reading:
					<xref />.</dd>
     <dt>Further reading:</dt><dd><xref target="SY16" format="default" />,
     <xref target="M05" format="default" />, <xref target="BKY02"
     format="default" />.
				</t> /></dd>
   </dl>

 </section>
 <section anchor="Robust" numbered="true" toc="default">
   <name>Robust Authenticated Encryption</name>
				<t>
					Definition: An
   <dl spacing="normal" newline="true">
     <dt>Definition:</dt><dd>An AEAD algorithm allows users to choose a
     desired ciphertext expansion (the difference between the length of
     plaintext and corresponding ciphertext) along with an input to the
     encryption operation. This feature enables the regulation of desired data
     integrity guarantees, which depend on ciphertext expansion, for each
     particular application while using the same algorithm implementation.
				</t>
				<t>
					Examples: AEZ
     implementation.</dd>
     <dt>Examples:</dt><dd>AEZ <xref target="HKR2015" format="default" />.
				</t>
				<t>
					Security notion: RAE /></dd>
     <dt>Security notion:</dt><dd>RAE <xref target="HKR2015" format="default" />.
				</t>
				<t>
					Notes: The /></dd>
     <dt>Notes:</dt><dd>The security goal of robust AEAD algorithms is to
     ensure the best possible security, even with small ciphertext expansion
     (referred to as stretch). For instance, analyzing any AEAD algorithm with
     a one-byte stretch for conventional integrity reveals insecurity, as the
     probability of forging a ciphertext is no less than 1/256. Nonetheless,
     from the robust AEAD perspective, an algorithm with such forgery
     probability for a one-byte ciphertext expansion is secure, representing
     the best achievable security in that scenario.
				</t>
				<t>
					Further reading:
					<xref scenario.</dd>
     <dt>Further reading:</dt><dd><xref target="HKR2015" format="default" />.
				</t> /></dd>
   </dl>
 </section>
</section>

<section anchor="Acknowledgments" numbered="false" toc="default">
  <name>Acknowledgments</name>
			<t>
				This
  <t>This document benefited greatly from the comments received from the CFRG
  community, for which we are very grateful. We would also like to extend
  special appreciation to Liliya Akhmetzyanova, Evgeny Alekseev, Alexandra Babueva, Frank Denis, Kirill Kutsenok, Sergey Kyazhin, Samuel Lucas, Grigory Marshalko, Christopher Patton, and Christopher Wood <contact fullname="Liliya Akhmetzyanova"/>, <contact
  fullname="Evgeny Alekseev"/>, <contact fullname="Alexandra Babueva"/>,
  <contact fullname="Frank Denis"/>, <contact fullname="Kirill Kutsenok"/>,
  <contact fullname="Sergey Kyazhin"/>, <contact fullname="Samuel Lucas"/>,
  <contact fullname="Grigory Marshalko"/>, <contact fullname="Christopher
  Patton"/>, and <contact fullname="Christopher Wood"/> for their thoughtful
  comments, proposals, and discussions.
			</t> discussions.</t>
</section>

<!-- [rfced] We updated "Additional Functionality AEAD class" and "Additional
Functionality AEAD algorithm" as follows. Please review.

Original:
   Most importantly, for every Additional Functionality AEAD class,
   conventional security properties must be redefined concerning the
   targeted additional functionality and the new interface.
   ...
   Although it
   might be possible to consider a particular Additional Functionality
   AEAD algorithm as a conventional AEAD algorithm ...

Updated:
   Most importantly, for every AEAD class with additional functionality,
   conventional security properties must be redefined concerning the
   targeted additional functionality and the new interface.
   ...
   Although it
   might be possible to consider a particular
   AEAD algorithm with additional functionality as a conventional AEAD algorithm ...
-->

<!-- [rfced] Abbreviations

a) FYI - We have added expansions for the following abbreviations
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correctness.

Encapsulating Security Payload (ESP)
Secure Real-time Transport Protocol (SRTP)
Voice over IP (VoIP)
Multilinear Galois Mode (MGM)
Synthetic Initialization Vector (SIV)
Galois/Counter Mode (GCM)

b) How should "CCA" be expanded here? As "Congestion Control Algorithm (CCA)"
or something else? Also, how should "CPA" be expanded here? As "Certification
Path Advertisement (CPA)"?

Original:
   Security notion: CPA resilience (confidentiality), authenticity
   resilience (integrity), CCA resilience (authenticated encryption)
   [ADL17].

c) How should "RAE" be expanded? As "Robust Authenticated Encryption" or
something else?

Original:
   Security notion: RAE [HKR2015].

c) Should any of the following be expanded or defined? Are these names of
things rather than abbreviations that should be expanded?

Note that these do not appear on our Abbreviations List at
https://www.rfc-editor.org/rpc/wiki/doku.php?id=abbrev_list. Also note that we
do not expand fixed names for things (e.g., algorithms like AES-GCM).

IND-CPA
IND-CTXT
D-LORS-BCPA
B-INT-CTXT
INT-RUP
GCM-RUP
SAEF
CMT
CMT-4
CMT-1
CIL1
CCAL1
CCAmL2
TEDT
MRAE
QCB
AEZ
mu-ind
-->

<!-- [rfced] Lists in Sections 4.4 and Appendix A

a) May we update "Security notion:" to "Security notions:" (plural)
throughout? We see that "Examples:" and "Applications:" are plural.

b) We used newline="true" for these lists; let us know if you would like to
use newline="false" instead.

Example of newline="true":
   Definition:
      An AEAD algorithm guarantees that the plaintext is not available
      to an active, nonce-respecting adversary.

   Security notion:
      IND-CCA [BN2000] (or IND-CCA2 [S04])

   Synonyms:
      Message privacy

Example of newline="false":
   Definition:  An AEAD algorithm allows one to ensure that the
      ciphertext and the associated data have not been changed or forged
      by an active, nonce-respecting adversary.

   Security notion:  IND-CTXT [BN2000] (or AUTH [R02])

   Synonyms:  Message authentication, authenticity
-->

<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers.

Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
-->

</back>

</rfc>