<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" docName="draft-irtf-cfrg-aead-properties-09" number="9771" ipr="trust200902" obsoletes="" updates="" submissionType="IRTF" category="info" consensus="true" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" prepTime="2025-05-07T16:01:38" indexInclude="true" scripts="Common,Latin">
  <link href="https://datatracker.ietf.org/doc/draft-irtf-cfrg-aead-properties-09" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9771" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="Properties of AEAD Algorithms">Properties of Authenticated Encryption with Associated Data (AEAD) Algorithms</title>
    <seriesInfo name="RFC" value="9771" stream="IRTF"/>
    <author fullname="Andrey Bozhko" initials="A" role="editor" surname="Bozhko">
      <organization showOnFrontPage="true">CryptoPro</organization>
      <address>
        <email>andbogc@gmail.com</email>
      </address>
    </author>
    <date month="05" year="2025"/>
    <workgroup>Crypto Forum</workgroup>
    <keyword>authenticated encryption</keyword>
    <keyword>mode of operation</keyword>
    <keyword>AEAD</keyword>
    <keyword>properties</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1"> Authenticated Encryption with Associated Data (AEAD) algorithms
      provide both confidentiality and integrity of data. The widespread use
      of AEAD algorithms in various applications has led to an increased
      demand for AEAD algorithms with additional properties, driving research
      in the field. This document provides definitions for the most common of
      those properties and aims to improve consistency in the terminology used
      in documentation. This document is a product of the Crypto Forum
      Research Group.
      </t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This document is not an Internet Standards Track specification; it is
            published for informational purposes.  
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Research Task Force
            (IRTF).  The IRTF publishes the results of Internet-related
            research and development activities.  These results might not be
            suitable for deployment.  This RFC represents the consensus of the Crypto Forum
            Research Group of the Internet Research Task Force (IRTF).
            Documents approved for publication by the IRSG are not
            candidates for any level of Internet Standard; see Section 2 of RFC
            7841.   
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9771" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2025 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.1.2">
              <li pn="section-toc.1-1.1.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><xref derivedContent="1.1" format="counter" sectionFormat="of" target="section-1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-background">Background</xref></t>
              </li>
              <li pn="section-toc.1-1.1.2.2">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.2.1"><xref derivedContent="1.2" format="counter" sectionFormat="of" target="section-1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-scope">Scope</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-conventions-used-in-this-do">Conventions Used in This Document</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-aead-algorithms">AEAD Algorithms</xref></t>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-aead-properties">AEAD Properties</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2">
              <li pn="section-toc.1-1.4.2.1">
                <t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-classification-of-additiona">Classification of Additional AEAD Properties</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.2">
                <t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent="4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-conventional-properties">Conventional Properties</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.2.2">
                  <li pn="section-toc.1-1.4.2.2.2.1">
                    <t indent="0" pn="section-toc.1-1.4.2.2.2.1.1"><xref derivedContent="4.2.1" format="counter" sectionFormat="of" target="section-4.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-confidentiality">Confidentiality</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.2.2.2">
                    <t indent="0" pn="section-toc.1-1.4.2.2.2.2.1"><xref derivedContent="4.2.2" format="counter" sectionFormat="of" target="section-4.2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-data-integrity">Data Integrity</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.2.2.3">
                    <t indent="0" pn="section-toc.1-1.4.2.2.2.3.1"><xref derivedContent="4.2.3" format="counter" sectionFormat="of" target="section-4.2.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-authenticated-encryption-se">Authenticated Encryption Security</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.4.2.3">
                <t indent="0" pn="section-toc.1-1.4.2.3.1"><xref derivedContent="4.3" format="counter" sectionFormat="of" target="section-4.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-properties">Security Properties</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.3.2">
                  <li pn="section-toc.1-1.4.2.3.2.1">
                    <t indent="0" pn="section-toc.1-1.4.2.3.2.1.1"><xref derivedContent="4.3.1" format="counter" sectionFormat="of" target="section-4.3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-blockwise-security">Blockwise Security</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.3.2.2">
                    <t indent="0" pn="section-toc.1-1.4.2.3.2.2.1"><xref derivedContent="4.3.2" format="counter" sectionFormat="of" target="section-4.3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-full-commitment">Full Commitment</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.3.2.3">
                    <t indent="0" pn="section-toc.1-1.4.2.3.2.3.1"><xref derivedContent="4.3.3" format="counter" sectionFormat="of" target="section-4.3.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-key-commitment">Key Commitment</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.3.2.4">
                    <t indent="0" pn="section-toc.1-1.4.2.3.2.4.1"><xref derivedContent="4.3.4" format="counter" sectionFormat="of" target="section-4.3.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-leakage-resistance">Leakage Resistance</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.3.2.5">
                    <t indent="0" pn="section-toc.1-1.4.2.3.2.5.1"><xref derivedContent="4.3.5" format="counter" sectionFormat="of" target="section-4.3.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-multi-user-security">Multi-user Security</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.3.2.6">
                    <t indent="0" pn="section-toc.1-1.4.2.3.2.6.1"><xref derivedContent="4.3.6" format="counter" sectionFormat="of" target="section-4.3.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-nonce-hiding">Nonce Hiding</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.3.2.7">
                    <t indent="0" pn="section-toc.1-1.4.2.3.2.7.1"><xref derivedContent="4.3.7" format="counter" sectionFormat="of" target="section-4.3.7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-nonce-misuse">Nonce Misuse</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.3.2.8">
                    <t indent="0" pn="section-toc.1-1.4.2.3.2.8.1"><xref derivedContent="4.3.8" format="counter" sectionFormat="of" target="section-4.3.8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-quantum-security">Quantum Security</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.3.2.9">
                    <t indent="0" pn="section-toc.1-1.4.2.3.2.9.1"><xref derivedContent="4.3.9" format="counter" sectionFormat="of" target="section-4.3.9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-reforgeability-resilience">Reforgeability Resilience</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.3.2.10">
                    <t indent="0" pn="section-toc.1-1.4.2.3.2.10.1"><xref derivedContent="4.3.10" format="counter" sectionFormat="of" target="section-4.3.10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-release-of-unverified-plain">Release of Unverified Plaintext (RUP) Integrity</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.4.2.4">
                <t indent="0" pn="section-toc.1-1.4.2.4.1"><xref derivedContent="4.4" format="counter" sectionFormat="of" target="section-4.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-implementation-properties">Implementation Properties</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.4.2">
                  <li pn="section-toc.1-1.4.2.4.2.1">
                    <t indent="0" pn="section-toc.1-1.4.2.4.2.1.1"><xref derivedContent="4.4.1" format="counter" sectionFormat="of" target="section-4.4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-hardware-efficient">Hardware Efficient</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.4.2.2">
                    <t indent="0" pn="section-toc.1-1.4.2.4.2.2.1"><xref derivedContent="4.4.2" format="counter" sectionFormat="of" target="section-4.4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-inverse-free">Inverse-Free</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.4.2.3">
                    <t indent="0" pn="section-toc.1-1.4.2.4.2.3.1"><xref derivedContent="4.4.3" format="counter" sectionFormat="of" target="section-4.4.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-lightweight">Lightweight</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.4.2.4">
                    <t indent="0" pn="section-toc.1-1.4.2.4.2.4.1"><xref derivedContent="4.4.4" format="counter" sectionFormat="of" target="section-4.4.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-parallelizable">Parallelizable</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.4.2.5">
                    <t indent="0" pn="section-toc.1-1.4.2.4.2.5.1"><xref derivedContent="4.4.5" format="counter" sectionFormat="of" target="section-4.4.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-setup-free">Setup-Free</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.4.2.6">
                    <t indent="0" pn="section-toc.1-1.4.2.4.2.6.1"><xref derivedContent="4.4.6" format="counter" sectionFormat="of" target="section-4.4.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-single-pass">Single Pass</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.4.2.7">
                    <t indent="0" pn="section-toc.1-1.4.2.4.2.7.1"><xref derivedContent="4.4.7" format="counter" sectionFormat="of" target="section-4.4.7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-static-associated-data-effi">Static Associated Data Efficient</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.4.2.8">
                    <t indent="0" pn="section-toc.1-1.4.2.4.2.8.1"><xref derivedContent="4.4.8" format="counter" sectionFormat="of" target="section-4.4.8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-streamable">Streamable</xref></t>
                  </li>
                </ul>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2">
              <li pn="section-toc.1-1.7.2.1">
                <t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent="7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.2">
                <t indent="0" pn="section-toc.1-1.7.2.2.1"><xref derivedContent="7.2" format="counter" sectionFormat="of" target="section-7.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="Appendix A" format="default" sectionFormat="of" target="section-appendix.a"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-aead-algorithms-with-additi">AEAD Algorithms with Additional Functionality</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.8.2">
              <li pn="section-toc.1-1.8.2.1">
                <t indent="0" pn="section-toc.1-1.8.2.1.1"><xref derivedContent="A.1" format="counter" sectionFormat="of" target="section-appendix.a.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-incremental-authenticated-e">Incremental Authenticated Encryption</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.2">
                <t indent="0" pn="section-toc.1-1.8.2.2.1"><xref derivedContent="A.2" format="counter" sectionFormat="of" target="section-appendix.a.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-robust-authenticated-encryp">Robust Authenticated Encryption</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgments">Acknowledgments</xref></t>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.c"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-address">Author's Address</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="Introduction" numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">An Authenticated Encryption with Associated Data (AEAD) algorithm provides confidentiality for the plaintext to be encrypted and integrity for the plaintext and some associated data (sometimes called "Header"). AEAD algorithms play a crucial role in various applications and have emerged as a significant focus in cryptographic research.</t>
      <section anchor="IntBack" numbered="true" toc="include" removeInRFC="false" pn="section-1.1">
        <name slugifiedName="name-background">Background</name>
        <t indent="0" pn="section-1.1-1">
					AEAD algorithms are formally defined in <xref target="RFC5116" format="default" sectionFormat="of" derivedContent="RFC5116"/>. The main benefit of AEAD algorithms is that they simultaneously provide data confidentiality and integrity and have a simple unified interface. In contrast to generic compositions of Message Authentication Code (MAC) and encryption algorithms, an AEAD algorithm allows for a reduction in key and state sizes, improving the data processing speed. Most AEAD algorithms come with security analysis, usage guidelines, and reference implementations. Consequently, their integration into high-level schemes and protocols is highly transparent. For instance, AEAD algorithms are mandatory in TLS 1.3 <xref target="RFC8446" format="default" sectionFormat="of" derivedContent="RFC8446"/>, IPsec Encapsulating Security Payload (ESP) <xref target="RFC4303" format="default" sectionFormat="of" derivedContent="RFC4303"/> <xref target="RFC8221" format="default" sectionFormat="of" derivedContent="RFC8221"/>, and QUIC <xref target="RFC9000" format="default" sectionFormat="of" derivedContent="RFC9000"/>.
        </t>
        <t indent="0" pn="section-1.1-2">
					While confidentiality and data integrity (the conventional properties of AEAD algorithms) suffice for many applications, some environments demand other uncommon cryptographic properties. These often require additional analysis and research. As the number of such properties and corresponding research papers grows, inevitable misunderstandings and confusion arise. This is a common situation when related but formally different properties are named identically or when some security properties only have folklore understanding and are not formally defined. Consequently, the risk of misusing AEAD algorithms increases, potentially resulting in security issues.
        </t>
      </section>
      <section anchor="IntScope" numbered="true" toc="include" removeInRFC="false" pn="section-1.2">
        <name slugifiedName="name-scope">Scope</name>
        <t indent="0" pn="section-1.2-1">
					In <xref target="Properties" format="default" sectionFormat="of" derivedContent="Section 4"/> of this document, we provide a list of the most common additional properties of AEAD algorithms. The properties are divided into two categories, namely, security properties (see <xref target="SecurityProp" format="default" sectionFormat="of" derivedContent="Section 4.3"/>) and implementation properties (see <xref target="ImpProp" format="default" sectionFormat="of" derivedContent="Section 4.4"/>).

					We provide a high-level definition for each property. For security properties, we also reference an informative source where a formal game-based security notion is defined; we do not consider security properties for which no game-based formalization exists. When possible, we offer additional information: synonymous names, examples of algorithms that provide the property, applications that might necessitate the property from an AEAD algorithm, references for further reading, and additional notes containing information outside these categories.
        </t>
        <t indent="0" pn="section-1.2-2">
					The objective of this document is to enhance clarity and establish a common language in the field. In particular, the primary application of the document lies in the following two use cases within the document development process in the IRTF and IETF:
        </t>
        <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-1.2-3">
          <li pn="section-1.2-3.1">
            <t indent="0" pn="section-1.2-3.1.1">For an RFC or I-D that defines an AEAD algorithm, it is recommended to use the notations in <xref target="Properties" format="default" sectionFormat="of" derivedContent="Section 4"/> when listing additional properties of the algorithm.</t>
          </li>
          <li pn="section-1.2-3.2">
            <t indent="0" pn="section-1.2-3.2.1">For an RFC or I-D that defines a generic protocol based on an AEAD algorithm, it is recommended to use the notations in <xref target="Properties" format="default" sectionFormat="of" derivedContent="Section 4"/> if any additional properties are required from the algorithm.</t>
          </li>
        </ul>
        <t indent="0" pn="section-1.2-4">
					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="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-conventions-used-in-this-do">Conventions Used in This Document</name>
      <t indent="0" pn="section-2-1">
    The key words "<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 "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> 
    when, and only when, they appear in all capitals, as shown here.
      </t>
    </section>
    <section anchor="AEAD" numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-aead-algorithms">AEAD Algorithms</name>
      <t indent="0" pn="section-3-1"> This section gives a conventional definition of an AEAD
	  algorithm following <xref target="RFC5116" format="default" sectionFormat="of" derivedContent="RFC5116"/>. </t>
      <dl newline="true" spacing="normal" indent="3" pn="section-3-2">
        <dt pn="section-3-2.1">Definition:</dt>
        <dd pn="section-3-2.2">
          <t indent="0" pn="section-3-2.2.1">An AEAD algorithm is defined by two operations, which are
	    authenticated encryption and authenticated decryption:</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3-2.2.2">
            <li pn="section-3-2.2.2.1">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 <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.</li>
            <li pn="section-3-2.2.2.2">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.</li>
          </ul>
        </dd>
      </dl>
      <t indent="0" pn="section-3-3">We note that specifications of AEAD algorithms that use authentication tags
     to ensure integrity may define the authentication tag as an
     independent output of the encryption operation and an independent input of
     the decryption operation. Throughout this document, by default, we consider
     the authentication tag as part of the ciphertext.
      </t>
      <t indent="0" pn="section-3-4">
				For more details on the AEAD definition, please refer to <xref target="RFC5116" format="default" sectionFormat="of" derivedContent="RFC5116"/>.
      </t>
      <t indent="0" pn="section-3-5">
				Throughout this document, by default, we consider nonce-based AEAD algorithms, which have an interface as defined above, and we give no other restrictions on their structure. However, some properties considered in the document apply only to particular classes of such algorithms, like AEAD algorithms based on block ciphers (such algorithms use a block cipher as a building block). If that is the case, we explicitly point that out in the corresponding section.
      </t>
    </section>
    <section anchor="Properties" numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-aead-properties">AEAD Properties</name>
      <section anchor="Classification" numbered="true" toc="include" removeInRFC="false" pn="section-4.1">
        <name slugifiedName="name-classification-of-additiona">Classification of Additional AEAD Properties</name>
        <t indent="0" pn="section-4.1-1">In this document, we employ a high-level classification of
	    additional properties. This classification aims to provide insight
	    into how one can benefit from each property. The additional
	    properties are categorized into one of these two
	    groups:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.1-2">
          <li pn="section-4.1-2.1">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.</li>
          <li pn="section-4.1-2.2">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.</li>
        </ul>
        <t indent="0" pn="section-4.1-3"> We note that some additional properties of AEAD algorithms
	    found in the literature could not be allocated to either of these
	    two groups. The observation is that such properties require an
	    extension of the conventional AEAD interface. We refer to these
	    properties as "additional functionality properties" and define the
	    corresponding group as follows:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.1-4">
          <li pn="section-4.1-4.1">Additional functionality properties: We classify a property
	      as an additional functionality property if it introduces new
	      features in addition to the standard AEAD.</li>
        </ul>
        <t indent="0" pn="section-4.1-5"> 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" sectionFormat="of" derivedContent="Appendix A"/>, we
	    briefly present two classes of AEAD algorithms with additional
	    functionality.
        </t>
      </section>
      <section anchor="Base" numbered="true" toc="include" removeInRFC="false" pn="section-4.2">
        <name slugifiedName="name-conventional-properties">Conventional Properties</name>
        <t indent="0" pn="section-4.2-1">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 indent="0" pn="section-4.2-2">
     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="include" removeInRFC="false" pn="section-4.2.1">
          <name slugifiedName="name-confidentiality">Confidentiality</name>
          <dl spacing="normal" newline="true" indent="3" pn="section-4.2.1-1">
            <dt pn="section-4.2.1-1.1">Definition:</dt>
            <dd pn="section-4.2.1-1.2">An AEAD algorithm guarantees that the plaintext is not
       available to an active, nonce-respecting adversary.</dd>
            <dt pn="section-4.2.1-1.3">Security notions:</dt>
            <dd pn="section-4.2.1-1.4">IND-CCA <xref target="BN08" format="default" sectionFormat="of" derivedContent="BN08"/> (or IND-CCA2 <xref target="S04" format="default" sectionFormat="of" derivedContent="S04"/>)</dd>
            <dt pn="section-4.2.1-1.5">Synonyms:</dt>
            <dd pn="section-4.2.1-1.6">Message privacy</dd>
            <dt pn="section-4.2.1-1.7">Notes:</dt>
            <dd pn="section-4.2.1-1.8">Confidentiality against passive adversaries can also
       be considered. The corresponding security notion is IND-CPA <xref target="BN08" format="default" sectionFormat="of" derivedContent="BN08"/> <xref target="R02" format="default" sectionFormat="of" derivedContent="R02"/>.</dd>
            <dt pn="section-4.2.1-1.9">Further reading:</dt>
            <dd pn="section-4.2.1-1.10">
              <xref target="R02" format="default" sectionFormat="of" derivedContent="R02"/>,
       <xref target="BN08" format="default" sectionFormat="of" derivedContent="BN08"/>, <xref target="S04" format="default" sectionFormat="of" derivedContent="S04"/></dd>
          </dl>
        </section>
        <section anchor="Int" numbered="true" toc="include" removeInRFC="false" pn="section-4.2.2">
          <name slugifiedName="name-data-integrity">Data Integrity</name>
          <dl spacing="normal" newline="true" indent="3" pn="section-4.2.2-1">
            <dt pn="section-4.2.2-1.1">Definition:</dt>
            <dd pn="section-4.2.2-1.2">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.</dd>
            <dt pn="section-4.2.2-1.3">Security notions:</dt>
            <dd pn="section-4.2.2-1.4">INT-CTXT <xref target="BN08" format="default" sectionFormat="of" derivedContent="BN08"/> (or AUTH <xref target="R02" format="default" sectionFormat="of" derivedContent="R02"/>)</dd>
            <dt pn="section-4.2.2-1.5">Synonyms:</dt>
            <dd pn="section-4.2.2-1.6">Message authentication, authenticity</dd>
            <dt pn="section-4.2.2-1.7">Further reading:</dt>
            <dd pn="section-4.2.2-1.8">
              <xref target="R02" format="default" sectionFormat="of" derivedContent="R02"/>,
       <xref target="BN08" format="default" sectionFormat="of" derivedContent="BN08"/>, <xref target="S04" format="default" sectionFormat="of" derivedContent="S04"/></dd>
          </dl>
        </section>
        <section anchor="AE" numbered="true" toc="include" removeInRFC="false" pn="section-4.2.3">
          <name slugifiedName="name-authenticated-encryption-se">Authenticated Encryption Security</name>
          <dl newline="true" spacing="normal" indent="3" pn="section-4.2.3-1">
            <dt pn="section-4.2.3-1.1">Definition:</dt>
            <dd pn="section-4.2.3-1.2">An AEAD algorithm provides confidentiality
	 and data integrity against active, nonce-respecting adversaries.</dd>
            <dt pn="section-4.2.3-1.3">Security notions:</dt>
            <dd pn="section-4.2.3-1.4">IND-CPA and INT-CTXT <xref target="BN08" format="default" sectionFormat="of" derivedContent="BN08"/> <xref target="R02" format="default" sectionFormat="of" derivedContent="R02"/> (or equivalently, IND-CCA3 <xref target="S04" format="default" sectionFormat="of" derivedContent="S04"/>)</dd>
            <dt pn="section-4.2.3-1.5">Notes:</dt>
            <dd pn="section-4.2.3-1.6">Please refer to <xref target="I-D.irtf-cfrg-aead-limits" format="default" sectionFormat="of" derivedContent="AEAD-LIMITS"/> for usage
	 limits on modern AEAD algorithms used in IETF protocols.</dd>
            <dt pn="section-4.2.3-1.7">Further reading:</dt>
            <dd pn="section-4.2.3-1.8">
              <xref target="R02" format="default" sectionFormat="of" derivedContent="R02"/>,
	 <xref target="BN08" format="default" sectionFormat="of" derivedContent="BN08"/>, <xref target="S04" format="default" sectionFormat="of" derivedContent="S04"/></dd>
          </dl>
        </section>
      </section>
      <section anchor="SecurityProp" numbered="true" toc="include" removeInRFC="false" pn="section-4.3">
        <name slugifiedName="name-security-properties">Security Properties</name>
        <section anchor="BWsec" numbered="true" toc="include" removeInRFC="false" pn="section-4.3.1">
          <name slugifiedName="name-blockwise-security">Blockwise Security</name>
          <dl newline="true" spacing="normal" indent="3" pn="section-4.3.1-1">
            <dt pn="section-4.3.1-1.1">Definition:</dt>
            <dd pn="section-4.3.1-1.2">An AEAD algorithm provides security even if an
       adversary can adaptively choose the next part of the plaintext
       depending on already-computed ciphertext parts during an encryption
       operation.</dd>
            <dt pn="section-4.3.1-1.3">Security notions:</dt>
            <dd pn="section-4.3.1-1.4">D-LORS-BCPA for confidentiality against
       passive adversaries, B-INT-CTXT for integrity <xref target="EV17" format="default" sectionFormat="of" derivedContent="EV17"/>; OAE1 <xref target="HRRV15" format="default" sectionFormat="of" derivedContent="HRRV15"/> (a
       stronger notion; originally OAE (Online Authenticated Encryption) in
       <xref target="FFL12" format="default" sectionFormat="of" derivedContent="FFL12"/>)</dd>
            <dt pn="section-4.3.1-1.5">Examples:</dt>
            <dd pn="section-4.3.1-1.6">Deoxys <xref target="JNPS21" format="default" sectionFormat="of" derivedContent="JNPS21"/>,
       SAEF <xref target="ABV21" format="default" sectionFormat="of" derivedContent="ABV21"/></dd>
            <dt pn="section-4.3.1-1.7">Notes:</dt>
            <dd pn="section-4.3.1-1.8">Blockwise security is highly relevant for streamable
       AEAD algorithms (see <xref target="Online" format="default" sectionFormat="of" derivedContent="Section 4.4.8"/>). The
       OAE1 security notion <xref target="HRRV15" format="default" sectionFormat="of" derivedContent="HRRV15"/> and the
       OAE2 notion <xref target="HRRV15" format="default" sectionFormat="of" derivedContent="HRRV15"/> are tailored for
       streamable AEAD algorithms. OAE1 was first defined in <xref target="FFL12" format="default" sectionFormat="of" derivedContent="FFL12"/> under the name OAE; however, it
       contained a glitch, and the reformulated definition was presented in
       <xref target="HRRV15" format="default" sectionFormat="of" derivedContent="HRRV15"/>. Blockwise security follows
       from security in the OAE notion <xref target="EV17" format="default" sectionFormat="of" derivedContent="EV17"/>. For a discussion on security notions for streamable
       AEAD algorithms, see <xref target="HRRV15" format="default" sectionFormat="of" derivedContent="HRRV15"/>.</dd>
            <dt pn="section-4.3.1-1.9">Applications:</dt>
            <dd pn="section-4.3.1-1.10">Real-time streaming protocols, encryption on
       resource-constrained devices</dd>
            <dt pn="section-4.3.1-1.11">Further reading:</dt>
            <dd pn="section-4.3.1-1.12">
              <xref target="EV17" format="default" sectionFormat="of" derivedContent="EV17"/>,
       <xref target="JMV2002" format="default" sectionFormat="of" derivedContent="JMV2002"/>, <xref target="FJMV2004" format="default" sectionFormat="of" derivedContent="FJMV2004"/>, <xref target="HRRV15" format="default" sectionFormat="of" derivedContent="HRRV15"/></dd>
          </dl>
        </section>
        <section anchor="FullComm" numbered="true" toc="include" removeInRFC="false" pn="section-4.3.2">
          <name slugifiedName="name-full-commitment">Full Commitment</name>
          <dl spacing="normal" newline="true" indent="3" pn="section-4.3.2-1">
            <dt pn="section-4.3.2-1.1">Definition:</dt>
            <dd pn="section-4.3.2-1.2">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.</dd>
            <dt pn="section-4.3.2-1.3">Security notions:</dt>
            <dd pn="section-4.3.2-1.4">CMT-4 <xref target="BH22" format="default" sectionFormat="of" derivedContent="BH22"/>, generalized CMT for a restricted setting (see the
       notes below) <xref target="MLGR23" format="default" sectionFormat="of" derivedContent="MLGR23"/></dd>
            <dt pn="section-4.3.2-1.5">Examples:</dt>
            <dd pn="section-4.3.2-1.6">Ascon <xref target="DEMS21a" format="default" sectionFormat="of" derivedContent="DEMS21a"/> <xref target="DEMS21b" format="default" sectionFormat="of" derivedContent="DEMS21b"/> <xref target="YSS23" format="default" sectionFormat="of" derivedContent="YSS23"/>, full committing versions of Galois/Counter Mode (GCM) and
       GCM-SIV <xref target="BH22" format="default" sectionFormat="of" derivedContent="BH22"/>, generic constructions
       <xref target="BH22" format="default" sectionFormat="of" derivedContent="BH22"/> and <xref target="CR22" format="default" sectionFormat="of" derivedContent="CR22"/></dd>
            <dt pn="section-4.3.2-1.7">Notes:</dt>
            <dd pn="section-4.3.2-1.8">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" sectionFormat="of" derivedContent="MLGR23"/>. For
       instance, an adversary must find tuples that all share the same
       associated data value. In such cases, an AEAD algorithm is said to
       provide full commitment in a restricted setting. The imposed
       restrictions <bcp14>MUST</bcp14> be listed.</dd>
            <dt pn="section-4.3.2-1.9">Applications:</dt>
            <dd pn="section-4.3.2-1.10">Message franking <xref target="GLR17" format="default" sectionFormat="of" derivedContent="GLR17"/></dd>
            <dt pn="section-4.3.2-1.11">Further reading:</dt>
            <dd pn="section-4.3.2-1.12">
              <xref target="BH22" format="default" sectionFormat="of" derivedContent="BH22"/>,
       <xref target="CR22" format="default" sectionFormat="of" derivedContent="CR22"/>, <xref target="MLGR23" format="default" sectionFormat="of" derivedContent="MLGR23"/></dd>
          </dl>
        </section>
        <section anchor="KeyComm" numbered="true" toc="include" removeInRFC="false" pn="section-4.3.3">
          <name slugifiedName="name-key-commitment">Key Commitment</name>
          <dl spacing="normal" newline="true" indent="3" pn="section-4.3.3-1">
            <dt pn="section-4.3.3-1.1">Definition:</dt>
            <dd pn="section-4.3.3-1.2">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.</dd>
            <dt pn="section-4.3.3-1.3">Security notions:</dt>
            <dd pn="section-4.3.3-1.4">CMT-1 <xref target="BH22" format="default" sectionFormat="of" derivedContent="BH22"/></dd>
            <dt pn="section-4.3.3-1.5">Synonyms:</dt>
            <dd pn="section-4.3.3-1.6">Key robustness, key collision resistance</dd>
            <dt pn="section-4.3.3-1.7">Examples:</dt>
            <dd pn="section-4.3.3-1.8">Ascon <xref target="DEMS21a" format="default" sectionFormat="of" derivedContent="DEMS21a"/> <xref target="DEMS21b" format="default" sectionFormat="of" derivedContent="DEMS21b"/> <xref target="YSS23" format="default" sectionFormat="of" derivedContent="YSS23"/>, generic constructions from <xref target="BH22" format="default" sectionFormat="of" derivedContent="BH22"/> and <xref target="CR22" format="default" sectionFormat="of" derivedContent="CR22"/></dd>
            <dt pn="section-4.3.3-1.9">Notes:</dt>
            <dd pn="section-4.3.3-1.10">Key commitment follows from full commitment. Full
       commitment does not follow from key commitment <xref target="BH22" format="default" sectionFormat="of" derivedContent="BH22"/>.</dd>
            <dt pn="section-4.3.3-1.11">Applications:</dt>
            <dd pn="section-4.3.3-1.12">Password-Authenticated Key Exchange,
       password-based encryption <xref target="LGR21" format="default" sectionFormat="of" derivedContent="LGR21"/>, key
       rotation, envelope encryption <xref target="ADGKLS22" format="default" sectionFormat="of" derivedContent="ADGKLS22"/></dd>
            <dt pn="section-4.3.3-1.13">Further reading:</dt>
            <dd pn="section-4.3.3-1.14">
              <xref target="BH22" format="default" sectionFormat="of" derivedContent="BH22"/>, <xref target="CR22" format="default" sectionFormat="of" derivedContent="CR22"/>, <xref target="FOR17" format="default" sectionFormat="of" derivedContent="FOR17"/>, <xref target="LGR21" format="default" sectionFormat="of" derivedContent="LGR21"/>, <xref target="GLR17" format="default" sectionFormat="of" derivedContent="GLR17"/></dd>
          </dl>
        </section>
        <section anchor="Leakage" numbered="true" toc="include" removeInRFC="false" pn="section-4.3.4">
          <name slugifiedName="name-leakage-resistance">Leakage Resistance</name>
          <dl spacing="normal" newline="true" indent="3" pn="section-4.3.4-1">
            <dt pn="section-4.3.4-1.1">Definition:</dt>
            <dd pn="section-4.3.4-1.2">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.</dd>
            <dt pn="section-4.3.4-1.3">Security notions:</dt>
            <dd pn="section-4.3.4-1.4">CIL1 <xref target="GPPS19" format="default" sectionFormat="of" derivedContent="GPPS19"/> (CIML2 <xref target="BPPS17" format="default" sectionFormat="of" derivedContent="BPPS17"/>
       with leakages in decryption) for integrity, CCAL1 <xref target="GPPS19" format="default" sectionFormat="of" derivedContent="GPPS19"/> (CCAmL2 <xref target="GPPS19" format="default" sectionFormat="of" derivedContent="GPPS19"/>
       with leakages in decryption) for authenticated encryption
       security</dd>
            <dt pn="section-4.3.4-1.5">Examples:</dt>
            <dd pn="section-4.3.4-1.6">Ascon <xref target="DEMS21a" format="default" sectionFormat="of" derivedContent="DEMS21a"/> <xref target="DEMS21b" format="default" sectionFormat="of" derivedContent="DEMS21b"/> (security
       under CIML2 and CCAL1 notions <xref target="B20" format="default" sectionFormat="of" derivedContent="B20"/>),
       TEDT <xref target="GPPS19" format="default" sectionFormat="of" derivedContent="GPPS19"/></dd>
            <dt pn="section-4.3.4-1.7">Notes:</dt>
            <dd pn="section-4.3.4-1.8">
              <t indent="0" pn="section-4.3.4-1.8.1">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" sectionFormat="of" derivedContent="CJRR99"/>), meaning
       the adversary doesn't gain any additional information about the
       algorithm's computation via side-channel leakages. We say that an AEAD
       algorithm doesn't provide leakage resistance if it can only achieve leakage
       resistance with such an implementation. Leakage-resistant AEAD
       algorithms aim to place requirements on implementations that are as mild as
       possible to achieve leakage resistance. These requirements
       <bcp14>SHOULD</bcp14> be listed.</t>
              <t indent="0" pn="section-4.3.4-1.8.2">Confidentiality of plaintext in the presence of leakages in the
       encryption operation is unachievable if an adversary can repeat the
       nonce used to encrypt the plaintext in other encryption
       queries. Confidentiality can be achieved only for plaintexts encrypted
       with fresh nonces (analogously to nonce-misuse resilience; see <xref target="NM" format="default" sectionFormat="of" derivedContent="Section 4.3.7"/>). For further discussions, see <xref target="GPPS19" format="default" sectionFormat="of" derivedContent="GPPS19"/> and <xref target="B20" format="default" sectionFormat="of" derivedContent="B20"/>.</t>
              <t indent="0" pn="section-4.3.4-1.8.3">For primitive-based AEAD algorithms, key evolution (internal
       re-keying <xref target="RFC8645" format="default" sectionFormat="of" derivedContent="RFC8645"/>) can contribute to
       achieving leakage resistance with leakages in
       encryption. Confidentiality in the presence of decryption leakages can
       be achieved by two-pass AEAD algorithms with key evolution, which
       compute independent ephemeral key values for encryption and tag
       generation, where the computation of these keys is implemented without
       any leakages. For more discussion on achieving leakage resistance, see
       <xref target="B20" format="default" sectionFormat="of" derivedContent="B20"/>.</t>
              <t indent="0" pn="section-4.3.4-1.8.4">Leakage Resilience, a well-known weaker property introduced in
       <xref target="BMOS17" format="default" sectionFormat="of" derivedContent="BMOS17"/>, can also be
       considered. However, following the framework established in
       <xref target="GPPS19" format="default" sectionFormat="of" derivedContent="GPPS19"/> and <xref target="B20" format="default" sectionFormat="of" derivedContent="B20"/>, this document makes a conscious choice to focus on
       the stronger Leakage Resistance for its enhanced practicality and
       comprehensiveness.</t>
            </dd>
            <dt pn="section-4.3.4-1.9">Applications:</dt>
            <dd pn="section-4.3.4-1.10">Encryption on smart cards, Internet-of-Things
       devices, or other constrained devices</dd>
            <dt pn="section-4.3.4-1.11">Further reading:</dt>
            <dd pn="section-4.3.4-1.12">
              <xref target="GPPS19" format="default" sectionFormat="of" derivedContent="GPPS19"/>,
       <xref target="B20" format="default" sectionFormat="of" derivedContent="B20"/>, <xref target="BPPS17" format="default" sectionFormat="of" derivedContent="BPPS17"/>, <xref target="BMOS17" format="default" sectionFormat="of" derivedContent="BMOS17"/></dd>
          </dl>
        </section>
        <section anchor="Mu-sec" numbered="true" toc="include" removeInRFC="false" pn="section-4.3.5">
          <name slugifiedName="name-multi-user-security">Multi-user Security</name>
          <dl newline="true" spacing="normal" indent="3" pn="section-4.3.5-1">
            <dt pn="section-4.3.5-1.1">Definition:</dt>
            <dd pn="section-4.3.5-1.2">The security of an AEAD algorithm degrades slower than
       linearly with an increase in the number of users.</dd>
            <dt pn="section-4.3.5-1.3">Security notions:</dt>
            <dd pn="section-4.3.5-1.4">mu-ind  <xref target="BT16" format="default" sectionFormat="of" derivedContent="BT16"/></dd>
            <dt pn="section-4.3.5-1.5">Examples:</dt>
            <dd pn="section-4.3.5-1.6">AES-GCM <xref target="D07" format="default" sectionFormat="of" derivedContent="D07"/>,
       ChaCha20-Poly1305 <xref target="RFC8439" format="default" sectionFormat="of" derivedContent="RFC8439"/>,
       AES-GCM-SIV <xref target="RFC8452" format="default" sectionFormat="of" derivedContent="RFC8452"/>, AEGIS <xref target="I-D.irtf-cfrg-aegis-aead" format="default" sectionFormat="of" derivedContent="AEGIS-AEAD"/></dd>
            <dt pn="section-4.3.5-1.7">Notes:</dt>
            <dd pn="section-4.3.5-1.8">
              <t indent="0" pn="section-4.3.5-1.8.1">For any AEAD algorithm, security
       degrades no worse than linearly with an increase in the number of users
       <xref target="BT16" format="default" sectionFormat="of" derivedContent="BT16"/>. However, for some applications
       with a significant number of users, better multi-user guarantees are
       required. For example, in the TLS 1.3 protocol, 
       AEAD algorithms are used with a randomized nonce (deterministically
       derived from a traffic secret and a sequence number) to address this issue. Using nonce
       randomization in block cipher counter-based AEAD modes can contribute
       to multi-user security <xref target="BT16" format="default" sectionFormat="of" derivedContent="BT16"/>. Multi-user usage limits for AES-GCM and ChaCha20-Poly1305 are
       provided in <xref target="I-D.irtf-cfrg-aead-limits" format="default" sectionFormat="of" derivedContent="AEAD-LIMITS"/>.</t>
              <t indent="0" pn="section-4.3.5-1.8.2">A weaker security notion, multi-user key recovery, is also
       introduced and thoroughly studied in <xref target="BT16" format="default" sectionFormat="of" derivedContent="BT16"/>. While this document focuses on
       indistinguishability for security notions, key recovery might be
       relevant and valuable to study alongside indistinguishability.</t>
            </dd>
            <dt pn="section-4.3.5-1.9">Applications:</dt>
            <dd pn="section-4.3.5-1.10">Data transmission layer of secure
       communication protocols (e.g., TLS, IPsec, the Secure Real-time Transport Protocol (SRTP), etc.)</dd>
            <dt pn="section-4.3.5-1.11">Further reading:</dt>
            <dd pn="section-4.3.5-1.12">
              <xref target="BT16" format="default" sectionFormat="of" derivedContent="BT16"/>,
       <xref target="HTT18" format="default" sectionFormat="of" derivedContent="HTT18"/>, <xref target="LMP17" format="default" sectionFormat="of" derivedContent="LMP17"/>, <xref target="DGGP21" format="default" sectionFormat="of" derivedContent="DGGP21"/>, <xref target="BHT18" format="default" sectionFormat="of" derivedContent="BHT18"/></dd>
          </dl>
        </section>
        <section anchor="NonceHiding" numbered="true" toc="include" removeInRFC="false" pn="section-4.3.6">
          <name slugifiedName="name-nonce-hiding">Nonce Hiding</name>
          <dl spacing="normal" newline="true" indent="3" pn="section-4.3.6-1">
            <dt pn="section-4.3.6-1.1">Definition:</dt>
            <dd pn="section-4.3.6-1.2">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.</dd>
            <dt pn="section-4.3.6-1.3">Security notions:</dt>
            <dd pn="section-4.3.6-1.4">AE2 <xref target="BNT19" format="default" sectionFormat="of" derivedContent="BNT19"/></dd>
            <dt pn="section-4.3.6-1.5">Examples:</dt>
            <dd pn="section-4.3.6-1.6">Hide-Nonce (HN) transforms <xref target="BNT19" format="default" sectionFormat="of" derivedContent="BNT19"/></dd>
            <dt pn="section-4.3.6-1.7">Notes:</dt>
            <dd pn="section-4.3.6-1.8">As discussed in <xref target="BNT19" format="default" sectionFormat="of" derivedContent="BNT19"/>, adversary-visible nonces might compromise message
       and user privacy, similar to the way any metadata might. As pointed
       out in <xref target="B13" format="default" sectionFormat="of" derivedContent="B13"/>, even using a counter as
       a nonce value might compromise privacy. Designing a privacy-preserving
       way to manage nonces might be a challenging problem for an application.</dd>
            <dt pn="section-4.3.6-1.9">Applications:</dt>
            <dd pn="section-4.3.6-1.10">Any application that can't rely on a secure
       "out-of-band" nonce communication</dd>
            <dt pn="section-4.3.6-1.11">Further reading:</dt>
            <dd pn="section-4.3.6-1.12">
              <xref target="BNT19" format="default" sectionFormat="of" derivedContent="BNT19"/></dd>
          </dl>
        </section>
        <section anchor="NM" numbered="true" toc="include" removeInRFC="false" pn="section-4.3.7">
          <name slugifiedName="name-nonce-misuse">Nonce Misuse</name>
          <dl spacing="normal" newline="true" indent="3" pn="section-4.3.7-1">
            <dt pn="section-4.3.7-1.1">Definition:</dt>
            <dd pn="section-4.3.7-1.2">
              <t indent="0" pn="section-4.3.7-1.2.1">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>
              <dl newline="false" spacing="normal" indent="3" pn="section-4.3.7-1.2.2">
                <dt pn="section-4.3.7-1.2.2.1">Nonce misuse resilience:</dt>
                <dd pn="section-4.3.7-1.2.2.2">
                  <t indent="0" pn="section-4.3.7-1.2.2.2.1">Security is provided for messages
	 encrypted with non-repeated (fresh) nonces (correctly encrypted
	 messages).</t>
                  <dl newline="true" spacing="normal" indent="3" pn="section-4.3.7-1.2.2.2.2">
                    <dt pn="section-4.3.7-1.2.2.2.2.1">Security notions:</dt>
                    <dd pn="section-4.3.7-1.2.2.2.2.2">Chosen-Plaintext Attack (CPA) resilience (confidentiality),
	 authenticity resilience (integrity), Chosen-Ciphertext Attack (CCA) resilience (authenticated
	 encryption) <xref target="ADL17" format="default" sectionFormat="of" derivedContent="ADL17"/></dd>
                    <dt pn="section-4.3.7-1.2.2.2.2.3">Examples:</dt>
                    <dd pn="section-4.3.7-1.2.2.2.2.4">ChaCha20-Poly1305 <xref target="RFC8439" format="default" sectionFormat="of" derivedContent="RFC8439"/>, AES-GCM <xref target="D07" format="default" sectionFormat="of" derivedContent="D07"/>
	 (only confidentiality)</dd>
                  </dl>
                </dd>
                <dt pn="section-4.3.7-1.2.2.3">Nonce misuse resistance:</dt>
                <dd pn="section-4.3.7-1.2.2.4">
                  <t indent="0" pn="section-4.3.7-1.2.2.4.1">Security is provided for all
       	 messages that were not encrypted with the same nonce value more than
       	 once.</t>
                  <dl newline="true" spacing="normal" indent="3" pn="section-4.3.7-1.2.2.4.2">
                    <dt pn="section-4.3.7-1.2.2.4.2.1">Security notions:</dt>
                    <dd pn="section-4.3.7-1.2.2.4.2.2">MRAE <xref target="RS06" format="default" sectionFormat="of" derivedContent="RS06"/></dd>
                    <dt pn="section-4.3.7-1.2.2.4.2.3">Examples:</dt>
                    <dd pn="section-4.3.7-1.2.2.4.2.4">AES-GCM-SIV <xref target="RFC8452" format="default" sectionFormat="of" derivedContent="RFC8452"/>, Deoxys-II <xref target="JNPS21" format="default" sectionFormat="of" derivedContent="JNPS21"/></dd>
                    <dt pn="section-4.3.7-1.2.2.4.2.5">Notes:</dt>
                    <dd pn="section-4.3.7-1.2.2.4.2.6">Synthetic Initialization Vector (SIV) construction <xref target="RS06" format="default" sectionFormat="of" derivedContent="RS06"/> is a generic construction that provides nonce
	 misuse resistance.</dd>
                  </dl>
                </dd>
              </dl>
            </dd>
            <dt pn="section-4.3.7-1.3">Notes:</dt>
            <dd pn="section-4.3.7-1.4">Nonce misuse resilience follows from nonce misuse
     resistance. Nonce misuse resistance does not follow from nonce misuse
     resilience.</dd>
            <dt pn="section-4.3.7-1.5">Applications:</dt>
            <dd pn="section-4.3.7-1.6">Any application where nonce uniqueness can't be
     guaranteed, security against fault-injection attacks and malfunctions,
     processes parallelization, full disk encryption</dd>
            <dt pn="section-4.3.7-1.7">Further reading:</dt>
            <dd pn="section-4.3.7-1.8">
              <xref target="RS06" format="default" sectionFormat="of" derivedContent="RS06"/>,
     <xref target="ADL17" format="default" sectionFormat="of" derivedContent="ADL17"/>, <xref target="IIM25" format="default" sectionFormat="of" derivedContent="IIM25"/></dd>
          </dl>
        </section>
        <section anchor="Quantum" numbered="true" toc="include" removeInRFC="false" pn="section-4.3.8">
          <name slugifiedName="name-quantum-security">Quantum Security</name>
          <dl spacing="normal" newline="true" indent="3" pn="section-4.3.8-1">
            <dt pn="section-4.3.8-1.1">Definition:</dt>
            <dd pn="section-4.3.8-1.2">
              <t indent="0" pn="section-4.3.8-1.2.1">An AEAD algorithm provides security (in a Q1
       or Q2 model) against a quantum adversary. Q1 and Q2 models are defined
       as follows:</t>
              <dl spacing="normal" newline="false" indent="3" pn="section-4.3.8-1.2.2">
                <dt pn="section-4.3.8-1.2.2.1">Q1 model:</dt>
                <dd pn="section-4.3.8-1.2.2.2">
                  <t indent="0" pn="section-4.3.8-1.2.2.2.1">An adversary has access to local quantum
	 computational power. It has classical access to encryption and
	 decryption oracles.</t>
                  <dl spacing="normal" newline="true" indent="3" pn="section-4.3.8-1.2.2.2.2">
                    <dt pn="section-4.3.8-1.2.2.2.2.1">Synonyms:</dt>
                    <dd pn="section-4.3.8-1.2.2.2.2.2">Post-quantum security</dd>
                    <dt pn="section-4.3.8-1.2.2.2.2.3">Examples:</dt>
                    <dd pn="section-4.3.8-1.2.2.2.2.4"> AES-GCM <xref target="D07" format="default" sectionFormat="of" derivedContent="D07"/>,
	 ChaCha20-Poly1305 <xref target="RFC8439" format="default" sectionFormat="of" derivedContent="RFC8439"/>, OCB
	 <xref target="RFC7253" format="default" sectionFormat="of" derivedContent="RFC7253"/>, Multilinear Galois Mode (MGM) <xref target="RFC9058" format="default" sectionFormat="of" derivedContent="RFC9058"/>, AES-GCM-SIV <xref target="RFC8452" format="default" sectionFormat="of" derivedContent="RFC8452"/>, AEGIS <xref target="I-D.irtf-cfrg-aegis-aead" format="default" sectionFormat="of" derivedContent="AEGIS-AEAD"/></dd>
                  </dl>
                </dd>
                <dt pn="section-4.3.8-1.2.2.3">Q2 model:</dt>
                <dd pn="section-4.3.8-1.2.2.4">
                  <t indent="0" pn="section-4.3.8-1.2.2.4.1">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>
                  <dl spacing="normal" newline="true" indent="3" pn="section-4.3.8-1.2.2.4.2">
                    <dt pn="section-4.3.8-1.2.2.4.2.1">Synonyms:</dt>
                    <dd pn="section-4.3.8-1.2.2.4.2.2"> Superposition-based quantum security</dd>
                    <dt pn="section-4.3.8-1.2.2.4.2.3">Examples:</dt>
                    <dd pn="section-4.3.8-1.2.2.4.2.4"> QCB <xref target="BBCLNSS21" format="default" sectionFormat="of" derivedContent="BBCLNSS21"/></dd>
                  </dl>
                </dd>
              </dl>
            </dd>
            <dt pn="section-4.3.8-1.3">Notes:</dt>
            <dd pn="section-4.3.8-1.4">Most symmetric cryptographic algorithms that are secure in
     the classical model provide quantum security in the Q1 model, i.e., they
     are post-quantum secure. Security in the Q1 setting corresponds to
     security against "harvest now, decrypt later" attacks. Security in Q1
     follows from security in Q2; the converse does not hold. For discussions
     on the relevance of the Q2 model, please see <xref target="G17" format="default" sectionFormat="of" derivedContent="G17"/>.</dd>
            <dt pn="section-4.3.8-1.5">Further reading:</dt>
            <dd pn="section-4.3.8-1.6">
              <xref target="KLLNP16" format="default" sectionFormat="of" derivedContent="KLLNP16"/>,
     <xref target="BBCLNSS21" format="default" sectionFormat="of" derivedContent="BBCLNSS21"/>, <xref target="G17" format="default" sectionFormat="of" derivedContent="G17"/></dd>
          </dl>
        </section>
        <section anchor="Reforg" numbered="true" toc="include" removeInRFC="false" pn="section-4.3.9">
          <name slugifiedName="name-reforgeability-resilience">Reforgeability Resilience</name>
          <dl newline="true" spacing="normal" indent="3" pn="section-4.3.9-1">
            <dt pn="section-4.3.9-1.1">Definition:</dt>
            <dd pn="section-4.3.9-1.2">An AEAD algorithm guarantees that once a
       successful forgery for the algorithm has been found, it is still hard
       to find any subsequent forgery.</dd>
            <dt pn="section-4.3.9-1.3">Security notions:</dt>
            <dd pn="section-4.3.9-1.4">j-Int-CTXT <xref target="FLLW17" format="default" sectionFormat="of" derivedContent="FLLW17"/></dd>
            <dt pn="section-4.3.9-1.5">Examples:</dt>
            <dd pn="section-4.3.9-1.6">Deoxys <xref target="JNPS21" format="default" sectionFormat="of" derivedContent="JNPS21"/>,
       AEGIS <xref target="I-D.irtf-cfrg-aegis-aead" format="default" sectionFormat="of" derivedContent="AEGIS-AEAD"/>, Ascon
       <xref target="DEMS21a" format="default" sectionFormat="of" derivedContent="DEMS21a"/> <xref target="DEMS21b" format="default" sectionFormat="of" derivedContent="DEMS21b"/></dd>
            <dt pn="section-4.3.9-1.7">Applications:</dt>
            <dd pn="section-4.3.9-1.8">Voice over IP (VoIP), real-time streaming in a lightweight
       setting, applications that require small ciphertext expansion (i.e.,
       short tags)</dd>
            <dt pn="section-4.3.9-1.9">Further reading:</dt>
            <dd pn="section-4.3.9-1.10">
              <xref target="BC09" format="default" sectionFormat="of" derivedContent="BC09"/>, <xref target="FLLW17" format="default" sectionFormat="of" derivedContent="FLLW17"/></dd>
          </dl>
        </section>
        <section anchor="RUP" numbered="true" toc="include" removeInRFC="false" pn="section-4.3.10">
          <name slugifiedName="name-release-of-unverified-plain">Release of Unverified Plaintext (RUP) Integrity</name>
          <dl spacing="normal" newline="true" indent="3" pn="section-4.3.10-1">
            <dt pn="section-4.3.10-1.1">Definition:</dt>
            <dd pn="section-4.3.10-1.2">An AEAD algorithm provides data integrity even
       if plaintext is released for every ciphertext, including those with
       failed integrity verification.</dd>
            <dt pn="section-4.3.10-1.3">Security notions:</dt>
            <dd pn="section-4.3.10-1.4">INT-RUP <xref target="A14" format="default" sectionFormat="of" derivedContent="A14"/></dd>
            <dt pn="section-4.3.10-1.5">Examples:</dt>
            <dd pn="section-4.3.10-1.6">GCM <xref target="IIM25" format="default" sectionFormat="of" derivedContent="IIM25"/>, GCM-RUP <xref target="ADL17" format="default" sectionFormat="of" derivedContent="ADL17"/></dd>
            <dt pn="section-4.3.10-1.7">Applications:</dt>
            <dd pn="section-4.3.10-1.8">Decryption with limited memory <xref target="FJMV2004" format="default" sectionFormat="of" derivedContent="FJMV2004"/>, real-time streaming protocols</dd>
            <dt pn="section-4.3.10-1.9">Notes:</dt>
            <dd pn="section-4.3.10-1.10">
              <t indent="0" pn="section-4.3.10-1.10.1">In <xref target="ADL17" format="default" sectionFormat="of" derivedContent="ADL17"/>, a generic
       approach to achieve INT-RUP security is introduced.</t>
              <t indent="0" pn="section-4.3.10-1.10.2">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" sectionFormat="of" derivedContent="A14"/>, the notion of
       "Plaintext Awareness" is introduced, capturing the best possible
       confidentiality under RUP in the following sense: "the adversary cannot
       gain any additional knowledge about the plaintext from decryption
       queries besides what it can derive from encryption queries".</t>
            </dd>
            <dt pn="section-4.3.10-1.11">Further reading:</dt>
            <dd pn="section-4.3.10-1.12">
              <xref target="A14" format="default" sectionFormat="of" derivedContent="A14"/>,
     <xref target="ADL17" format="default" sectionFormat="of" derivedContent="ADL17"/>, <xref target="IIM25" format="default" sectionFormat="of" derivedContent="IIM25"/></dd>
          </dl>
        </section>
      </section>
      <section anchor="ImpProp" numbered="true" toc="include" removeInRFC="false" pn="section-4.4">
        <name slugifiedName="name-implementation-properties">Implementation Properties</name>
        <section anchor="HardEff" numbered="true" toc="include" removeInRFC="false" pn="section-4.4.1">
          <name slugifiedName="name-hardware-efficient">Hardware Efficient</name>
          <dl newline="true" spacing="normal" indent="3" pn="section-4.4.1-1">
            <dt pn="section-4.4.1-1.1">Definition:</dt>
            <dd pn="section-4.4.1-1.2">An AEAD algorithm ensures optimal performance
       when operating on hardware that complies with the specified
       requirements.</dd>
            <dt pn="section-4.4.1-1.3">Notes:</dt>
            <dd pn="section-4.4.1-1.4">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 <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.</dd>
          </dl>
        </section>
        <section anchor="Inverse" numbered="true" toc="include" removeInRFC="false" pn="section-4.4.2">
          <name slugifiedName="name-inverse-free">Inverse-Free</name>
          <dl newline="true" spacing="normal" indent="3" pn="section-4.4.2-1">
            <dt pn="section-4.4.2-1.1">Definition:</dt>
            <dd pn="section-4.4.2-1.2">An AEAD algorithm based on a given primitive
       can be implemented without invoking the inverse of that primitive.</dd>
            <dt pn="section-4.4.2-1.3">Examples:</dt>
            <dd pn="section-4.4.2-1.4">AES-GCM <xref target="D07" format="default" sectionFormat="of" derivedContent="D07"/>,
       ChaCha20-Poly1305 <xref target="RFC8439" format="default" sectionFormat="of" derivedContent="RFC8439"/>, 
       MGM <xref target="RFC9058" format="default" sectionFormat="of" derivedContent="RFC9058"/>, 
       AEGIS <xref target="I-D.irtf-cfrg-aegis-aead" format="default" sectionFormat="of" derivedContent="AEGIS-AEAD"/></dd>
            <dt pn="section-4.4.2-1.5">Notes:</dt>
            <dd pn="section-4.4.2-1.6">In a sponge-based AEAD algorithm, an underlying
       permutation is viewed as a primitive.</dd>
          </dl>
        </section>
        <section anchor="Lightweight" numbered="true" toc="include" removeInRFC="false" pn="section-4.4.3">
          <name slugifiedName="name-lightweight">Lightweight</name>
          <dl newline="true" spacing="normal" indent="3" pn="section-4.4.3-1">
            <dt pn="section-4.4.3-1.1">Definition:</dt>
            <dd pn="section-4.4.3-1.2">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" sectionFormat="of" derivedContent="MBTM17"/>.</dd>
            <dt pn="section-4.4.3-1.3">Examples:</dt>
            <dd pn="section-4.4.3-1.4">OCB <xref target="RFC7253" format="default" sectionFormat="of" derivedContent="RFC7253"/>,
       Ascon <xref target="DEMS21a" format="default" sectionFormat="of" derivedContent="DEMS21a"/> <xref target="DEMS21b" format="default" sectionFormat="of" derivedContent="DEMS21b"/></dd>
            <dt pn="section-4.4.3-1.5">Further reading:</dt>
            <dd pn="section-4.4.3-1.6">
              <xref target="MBTM17" format="default" sectionFormat="of" derivedContent="MBTM17"/></dd>
          </dl>
        </section>
        <section anchor="Parallelizable" numbered="true" toc="include" removeInRFC="false" pn="section-4.4.4">
          <name slugifiedName="name-parallelizable">Parallelizable</name>
          <dl newline="true" spacing="normal" indent="3" pn="section-4.4.4-1">
            <dt pn="section-4.4.4-1.1">Definition:</dt>
            <dd pn="section-4.4.4-1.2">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.</dd>
            <dt pn="section-4.4.4-1.3">Synonyms:</dt>
            <dd pn="section-4.4.4-1.4">Pipelineable</dd>
            <dt pn="section-4.4.4-1.5">Examples:</dt>
            <dd pn="section-4.4.4-1.6">AES-GCM <xref target="D07" format="default" sectionFormat="of" derivedContent="D07"/>,
       ChaCha20-Poly1305 <xref target="RFC8439" format="default" sectionFormat="of" derivedContent="RFC8439"/>, OCB <xref target="RFC7253" format="default" sectionFormat="of" derivedContent="RFC7253"/>, MGM <xref target="RFC9058" format="default" sectionFormat="of" derivedContent="RFC9058"/>, AEGIS <xref target="I-D.irtf-cfrg-aegis-aead" format="default" sectionFormat="of" derivedContent="AEGIS-AEAD"/></dd>
            <dt pn="section-4.4.4-1.7">Further reading:</dt>
            <dd pn="section-4.4.4-1.8">
              <xref target="C20" format="default" sectionFormat="of" derivedContent="C20"/></dd>
          </dl>
        </section>
        <section anchor="SetupFree" numbered="true" toc="include" removeInRFC="false" pn="section-4.4.5">
          <name slugifiedName="name-setup-free">Setup-Free</name>
          <dl newline="true" spacing="normal" indent="3" pn="section-4.4.5-1">
            <dt pn="section-4.4.5-1.1">Definition:</dt>
            <dd pn="section-4.4.5-1.2">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.</dd>
            <dt pn="section-4.4.5-1.3">Examples:</dt>
            <dd pn="section-4.4.5-1.4">ChaCha20-Poly1305 <xref target="RFC8439" format="default" sectionFormat="of" derivedContent="RFC8439"/>, AEGIS <xref target="I-D.irtf-cfrg-aegis-aead" format="default" sectionFormat="of" derivedContent="AEGIS-AEAD"/>, Ascon <xref target="DEMS21a" format="default" sectionFormat="of" derivedContent="DEMS21a"/> <xref target="DEMS21b" format="default" sectionFormat="of" derivedContent="DEMS21b"/></dd>
          </dl>
        </section>
        <section anchor="SinglePass" numbered="true" toc="include" removeInRFC="false" pn="section-4.4.6">
          <name slugifiedName="name-single-pass">Single Pass</name>
          <dl newline="true" spacing="normal" indent="3" pn="section-4.4.6-1">
            <dt pn="section-4.4.6-1.1">Definition:</dt>
            <dd pn="section-4.4.6-1.2">An AEAD algorithm encryption (decryption)
       operation can be implemented with a single pass over the plaintext
       (ciphertext).</dd>
            <dt pn="section-4.4.6-1.3">Examples:</dt>
            <dd pn="section-4.4.6-1.4">AES-GCM <xref target="D07" format="default" sectionFormat="of" derivedContent="D07"/>,
       ChaCha20-Poly1305 <xref target="RFC8439" format="default" sectionFormat="of" derivedContent="RFC8439"/>, OCB <xref target="RFC7253" format="default" sectionFormat="of" derivedContent="RFC7253"/>, MGM <xref target="RFC9058" format="default" sectionFormat="of" derivedContent="RFC9058"/>, AEGIS <xref target="I-D.irtf-cfrg-aegis-aead" format="default" sectionFormat="of" derivedContent="AEGIS-AEAD"/></dd>
          </dl>
        </section>
        <section anchor="StaticAD" numbered="true" toc="include" removeInRFC="false" pn="section-4.4.7">
          <name slugifiedName="name-static-associated-data-effi">Static Associated Data Efficient</name>
          <dl newline="true" spacing="normal" indent="3" pn="section-4.4.7-1">
            <dt pn="section-4.4.7-1.1">Definition:</dt>
            <dd pn="section-4.4.7-1.2">An AEAD algorithm allows precomputation for
       static (or repeating) associated data so that static associated data
       doesn't significantly contribute to the computational cost of
       encryption.</dd>
            <dt pn="section-4.4.7-1.3">Examples:</dt>
            <dd pn="section-4.4.7-1.4">AES-GCM <xref target="D07" format="default" sectionFormat="of" derivedContent="D07"/>,
       ChaCha20-Poly1305 <xref target="RFC8439" format="default" sectionFormat="of" derivedContent="RFC8439"/>, OCB <xref target="RFC7253" format="default" sectionFormat="of" derivedContent="RFC7253"/></dd>
          </dl>
        </section>
        <section anchor="Online" numbered="true" toc="include" removeInRFC="false" pn="section-4.4.8">
          <name slugifiedName="name-streamable">Streamable</name>
          <dl newline="true" spacing="normal" indent="3" pn="section-4.4.8-1">
            <dt pn="section-4.4.8-1.1">Definition:</dt>
            <dd pn="section-4.4.8-1.2">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.</dd>
            <dt pn="section-4.4.8-1.3">Synonyms:</dt>
            <dd pn="section-4.4.8-1.4">Online</dd>
            <dt pn="section-4.4.8-1.5">Examples:</dt>
            <dd pn="section-4.4.8-1.6">AES-GCM <xref target="D07" format="default" sectionFormat="of" derivedContent="D07"/>,
       ChaCha20-Poly1305 <xref target="RFC8439" format="default" sectionFormat="of" derivedContent="RFC8439"/>, OCB <xref target="RFC7253" format="default" sectionFormat="of" derivedContent="RFC7253"/>, MGM <xref target="RFC9058" format="default" sectionFormat="of" derivedContent="RFC9058"/>, AEGIS <xref target="I-D.irtf-cfrg-aegis-aead" format="default" sectionFormat="of" derivedContent="AEGIS-AEAD"/>, Ascon <xref target="DEMS21a" format="default" sectionFormat="of" derivedContent="DEMS21a"/> <xref target="DEMS21b" format="default" sectionFormat="of" derivedContent="DEMS21b"/></dd>
            <dt pn="section-4.4.8-1.7">Applications:</dt>
            <dd pn="section-4.4.8-1.8">Real-time streaming protocols, resource-constrained devices</dd>
            <dt pn="section-4.4.8-1.9">Notes:</dt>
            <dd pn="section-4.4.8-1.10">Blockwise security (see <xref target="BWsec" format="default" sectionFormat="of" derivedContent="Section 4.3.1"/>) and RUP integrity (see <xref target="RUP" format="default" sectionFormat="of" derivedContent="Section 4.3.10"/>) might be relevant security properties for
       streamable AEAD algorithms in certain applications.</dd>
            <dt pn="section-4.4.8-1.11">Further reading:</dt>
            <dd pn="section-4.4.8-1.12">
              <xref target="HRRV15" format="default" sectionFormat="of" derivedContent="HRRV15"/>,
       <xref target="FJMV2004" format="default" sectionFormat="of" derivedContent="FJMV2004"/></dd>
          </dl>
        </section>
      </section>
    </section>
    <section anchor="Security" numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-5-1">
				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" sectionFormat="of" derivedContent="BM18"/>; security in such notions should be studied separately. 
      </t>
      <t indent="0" pn="section-5-2">	
				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 indent="0" pn="section-5-3">
			  Every claimed security property of an AEAD algorithm
			  <bcp14>MUST</bcp14> undergo security analysis within
			  a relevant notion. It's <bcp14>RECOMMENDED</bcp14>
			  to use the security notions referenced in the
			  document. If an alternative notion is used, proof of
			  equivalence <bcp14>MUST</bcp14> exist, or use of a
			  non-equivalent notion <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
			  <bcp14>SHOULD</bcp14> be indicated.
      </t>
      <t indent="0" pn="section-5-4">
				When specifying security requirements for an AEAD algorithm in an application, it <bcp14>SHOULD</bcp14> be indicated, for every required security property, whether only integrity or confidentiality is necessary. Additionally, for each security property, it <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 <bcp14>SHOULD</bcp14> be highly motivated and justified, and all trade-offs should be carefully considered.
      </t>
    </section>
    <section anchor="IANACON" numbered="true" toc="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-6-1">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 pn="section-7">
      <name slugifiedName="name-references">References</name>
      <references pn="section-7.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="D07" target="https://csrc.nist.gov/pubs/sp/800/38/d/final" quoteTitle="true" derivedAnchor="D07">
          <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"/>
        </reference>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t indent="0">In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC5116" target="https://www.rfc-editor.org/info/rfc5116" quoteTitle="true" derivedAnchor="RFC5116">
          <front>
            <title>An Interface and Algorithms for Authenticated Encryption</title>
            <author fullname="D. McGrew" initials="D." surname="McGrew"/>
            <date month="January" year="2008"/>
            <abstract>
              <t indent="0">This document defines algorithms for Authenticated Encryption with Associated Data (AEAD), and defines a uniform interface and a registry for such algorithms. The interface and registry can be used as an application-independent set of cryptoalgorithm suites. This approach provides advantages in efficiency and security, and promotes the reuse of crypto implementations. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5116"/>
          <seriesInfo name="DOI" value="10.17487/RFC5116"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t indent="0">RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
      </references>
      <references pn="section-7.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="A14" quoteTitle="true" target="https://doi.org/10.1007/978-3-662-45611-8_6" derivedAnchor="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, Lecture Notes in Computer Science, vol. 8873, pp. 105-125</refcontent>
        </reference>
        <reference anchor="ABV21" quoteTitle="true" target="https://doi.org/10.1007/978-3-030-81652-0_20" derivedAnchor="ABV21">
          <front>
            <title>Nonce-Misuse Security of the SAEF 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 (SAC 2020), Lecture Notes in Computer Science, vol. 12804, pp. 512-534</refcontent>
        </reference>
        <reference anchor="ADGKLS22" quoteTitle="true" derivedAnchor="ADGKLS22">
          <front>
            <title>How to Abuse and 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>31st USENIX Security Symposium (USENIX Security 22), pp. 3291-3308</refcontent>
        </reference>
        <reference anchor="ADL17" quoteTitle="true" target="https://doi.org/10.1007/978-3-319-63697-9_1" derivedAnchor="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, Lecture Notes in Computer Science, vol. 10403, pp. 3-33</refcontent>
        </reference>
        <reference anchor="I-D.irtf-cfrg-aead-limits" target="https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-aead-limits-10" quoteTitle="true" derivedAnchor="AEAD-LIMITS">
          <front>
            <title>Usage Limits on AEAD Algorithms</title>
            <author fullname="Felix Günther" initials="F." surname="Günther">
              <organization showOnFrontPage="true">IBM Research Europe - Zurich</organization>
            </author>
            <author fullname="Martin Thomson" initials="M." surname="Thomson">
              <organization showOnFrontPage="true">Mozilla</organization>
            </author>
            <author fullname="Christopher A. Wood" initials="C. A." surname="Wood">
              <organization showOnFrontPage="true">Cloudflare</organization>
            </author>
            <date day="8" month="April" year="2025"/>
            <abstract>
              <t indent="0">An Authenticated Encryption with Associated Data (AEAD) algorithm provides confidentiality and integrity. Excessive use of the same key can give an attacker advantages in breaking these properties. This document provides simple guidance for users of common AEAD functions about how to limit the use of keys in order to bound the advantage given to an attacker. It considers limits in both single- and multi-key settings.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-irtf-cfrg-aead-limits-10"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="I-D.irtf-cfrg-aegis-aead" target="https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-aegis-aead-16" quoteTitle="true" derivedAnchor="AEGIS-AEAD">
          <front>
            <title>The AEGIS Family of Authenticated Encryption Algorithms</title>
            <author fullname="Frank Denis" initials="F." surname="Denis">
              <organization showOnFrontPage="true">Fastly Inc.</organization>
            </author>
            <author fullname="Samuel Lucas" initials="S." surname="Lucas">
              <organization showOnFrontPage="true">Individual Contributor</organization>
            </author>
            <date day="17" month="February" year="2025"/>
            <abstract>
              <t indent="0">This document describes the AEGIS-128L, AEGIS-256, AEGIS-128X, and AEGIS-256X AES-based authenticated encryption algorithms designed for high-performance applications. The document is a product of the Crypto Forum Research Group (CFRG). It is not an IETF product and is not a standard. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/cfrg/draft-irtf-cfrg-aegis-aead.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-irtf-cfrg-aegis-aead-16"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="B13" target="https://groups.google.com/d/msg/crypto-competitions/n5ECGwYr6Vk/bsEfPWqSAU4J" quoteTitle="true" derivedAnchor="B13">
          <front>
            <title>Re: wondering the secret message number</title>
            <author initials="D. J." surname="Bernstein" fullname="Daniel J. Bernstein"/>
            <date year="2013"/>
          </front>
          <refcontent>Message to the Cryptographic Competitions Google Group</refcontent>
        </reference>
        <reference anchor="B20" quoteTitle="true" target="https://doi.org/10.1007/978-3-030-56784-2_13" derivedAnchor="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="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, Lecture Notes in Computer Science, vol. 12170, pp. 369-400</refcontent>
        </reference>
        <reference anchor="BBCLNSS21" quoteTitle="true" target="https://doi.org/10.1007/978-3-030-92062-3_23" derivedAnchor="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="Schrottenloher" fullname="André 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, Lecture Notes in Computer Science, vol. 13090, pp. 668-698</refcontent>
        </reference>
        <reference anchor="BC09" quoteTitle="true" target="https://doi.org/10.1007/978-3-642-03317-9_21" derivedAnchor="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), Lecture Notes in Computer Science, vol. 5665, pp. 345-362</refcontent>
        </reference>
        <reference anchor="BH22" quoteTitle="true" target="https://doi.org/10.1007/978-3-031-07085-3_29" derivedAnchor="BH22">
          <front>
            <title>Efficient Schemes for 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, Lecture Notes in Computer Science, vol. 13276, pp. 845-875</refcontent>
        </reference>
        <reference anchor="BHT18" quoteTitle="true" target="https://doi.org/10.1007/978-3-319-78381-9_18" derivedAnchor="BHT18">
          <front>
            <title>Revisiting AES-GCM-SIV: Multi-user Security, Faster Key Derivation, and 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>Advances in Cryptology - EUROCRYPT 2018, Lecture Notes in Computer Science, vol. 10820, pp. 468-499</refcontent>
        </reference>
        <reference anchor="BKY02" quoteTitle="true" target="https://doi.org/10.1007/3-540-45473-X_9" derivedAnchor="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), Lecture Notes in Computer Science, vol. 2355, pp. 109-124</refcontent>
        </reference>
        <reference anchor="BM18" quoteTitle="true" target="https://doi.org/10.1007/978-3-319-96884-1_7" derivedAnchor="BM18">
          <front>
            <title>Indifferentiable 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, Lecture Notes in Computer Science, vol. 10991, pp. 187-220</refcontent>
        </reference>
        <reference anchor="BMOS17" quoteTitle="true" target="https://doi.org/10.1007/978-3-319-70694-8_24" derivedAnchor="BMOS17">
          <front>
            <title>Authenticated Encryption in the Face of Protocol and 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, Lecture Notes in Computer Science, vol. 10624, pp. 693-723</refcontent>
        </reference>
        <reference anchor="BN08" quoteTitle="true" target="https://doi.org/10.1007/s00145-008-9026-x" derivedAnchor="BN08">
          <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="2008"/>
          </front>
          <seriesInfo name="DOI" value="10.1007/s00145-008-9026-x"/>
          <refcontent>Journal of Cryptology, vol. 21, pp. 469-491</refcontent>
        </reference>
        <reference anchor="BNT19" quoteTitle="true" target="https://doi.org/10.1007/978-3-030-26948-7_9" derivedAnchor="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, Lecture Notes in Computer Science, vol. 11692, pp. 235-265</refcontent>
        </reference>
        <reference anchor="BPPS17" quoteTitle="true" target="https://doi.org/10.13154/tosc.v2017.i3.271-293" derivedAnchor="BPPS17">
          <front>
            <title>On Leakage-Resilient Authenticated Encryption with 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." 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, vol. 2017, no. 3, pp. 271-293</refcontent>
        </reference>
        <reference anchor="BT16" quoteTitle="true" target="https://doi.org/10.1007/978-3-662-53018-4_10" derivedAnchor="BT16">
          <front>
            <title>The 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, Lecture Notes in Computer Science, vol. 9814, pp. 247-276</refcontent>
        </reference>
        <reference anchor="C20" quoteTitle="true" target="https://doi.org/10.13154/tosc.v2019.i4.81-118" derivedAnchor="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, vol. 2019, no.4, pp. 81-118</refcontent>
        </reference>
        <reference anchor="CJRR99" quoteTitle="true" target="https://doi.org/10.1007/3-540-48405-1_26" derivedAnchor="CJRR99">
          <front>
            <title>Towards Sound Approaches to 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, Lecture Notes in Computer Science, vol. 1666, pp. 398-412</refcontent>
        </reference>
        <reference anchor="CR22" quoteTitle="true" target="https://doi.org/10.1007/978-3-031-17146-8_14" derivedAnchor="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, Lecture Notes in Computer Science, vol. 13555, pp. 275-294</refcontent>
        </reference>
        <reference anchor="DEMS21a" quoteTitle="true" target="https://doi.org/10.1007/s00145-021-09398-9" derivedAnchor="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, vol. 34, no. 33</refcontent>
        </reference>
        <reference anchor="DEMS21b" quoteTitle="true" derivedAnchor="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="DGGP21" quoteTitle="true" target="https://doi.org/10.1145/3460120.3484814" derivedAnchor="DGGP21">
          <front>
            <title>The Security of ChaCha20-Poly1305 in the 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>Proceedings of the 2021 ACM SIGSAC Conference on Computer and Communications Security (CCS '21), pp. 1981-2003</refcontent>
        </reference>
        <reference anchor="EV17" quoteTitle="true" target="https://doi.org/10.13154/TOSC.V2016.I2.125-144" derivedAnchor="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="2017"/>
          </front>
          <seriesInfo name="DOI" value="10.13154/TOSC.V2016.I2.125-144"/>
          <refcontent>IACR Transactions on Symmetric Cryptology, vol. 2016, no. 2, pp. 125-144</refcontent>
        </reference>
        <reference anchor="FFL12" quoteTitle="true" target="https://doi.org/10.1007/978-3-642-34047-5_12" derivedAnchor="FFL12">
          <front>
            <title>McOE: A Family of 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 (FSE 2012), Lecture Notes in Computer Science, vol. 7549, pp. 196-215</refcontent>
        </reference>
        <reference anchor="FJMV2004" quoteTitle="true" target="https://doi.org/10.1007/978-3-540-24654-1_11" derivedAnchor="FJMV2004">
          <front>
            <title>Authenticated On-Line Encryption</title>
            <author 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</refcontent>
        </reference>
        <reference anchor="FLLW17" quoteTitle="true" target="https://doi.org/10.1007/978-3-319-59870-3_2" derivedAnchor="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), Lecture Notes in Computer Science, vol. 10343, pp. 19-37</refcontent>
        </reference>
        <reference anchor="FOR17" quoteTitle="true" target="https://doi.org/10.13154/tosc.v2017.i1.449-473" derivedAnchor="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, vol. 2017, no. 1, pp. 449-473</refcontent>
        </reference>
        <reference anchor="G17" target="https://tuprints.ulb.tu-darmstadt.de/6019/" quoteTitle="true" derivedAnchor="G17">
          <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>
        <reference anchor="GLR17" quoteTitle="true" target="https://doi.org/10.1007/978-3-319-63697-9_3" derivedAnchor="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, Lecture Notes in Computer Science, vol. 10403, pp. 66-97</refcontent>
        </reference>
        <reference anchor="GPPS19" quoteTitle="true" target="https://doi.org/10.1007/978-3-030-30530-7_8" derivedAnchor="GPPS19">
          <front>
            <title>Authenticated Encryption with Nonce Misuse and Physical Leakages: Definitions, Separation Results and 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="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, Lecture Notes in Computer Science, vol. 11774, pp. 150-172</refcontent>
        </reference>
        <reference anchor="HKR2015" quoteTitle="true" target="https://doi.org/10.1007/978-3-662-46800-5_2" derivedAnchor="HKR2015">
          <front>
            <title>Robust Authenticated-Encryption AEZ and the Problem That It Solves</title>
            <author 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, Lecture Notes in Computer Science, vol. 9056, pp. 15-44</refcontent>
        </reference>
        <reference anchor="HRRV15" quoteTitle="true" target="https://doi.org/10.1007/978-3-662-47989-6_24" derivedAnchor="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, Lecture Notes in Computer Science, vol. 9215, pp. 493-517</refcontent>
        </reference>
        <reference anchor="HTT18" quoteTitle="true" target="https://doi.org/10.1145/3243734.3243816" derivedAnchor="HTT18">
          <front>
            <title>The Multi-user Security of GCM, Revisited: Tight Bounds for 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 (CCS '18), pp. 1429-1440</refcontent>
        </reference>
        <reference anchor="IIM25" quoteTitle="true" target="https://doi.org/10.1007/978-3-031-88661-4_4" derivedAnchor="IIM25">
          <front>
            <title>Comprehensive Robustness Analysis of GCM, CCM, and OCB3</title>
            <author initials="A." surname="Inoue" fullname="Akiko Inoue"/>
            <author initials="T." surname="Iwata" fullname="Tetsu Iwata"/>
            <author initials="K." surname="Minematsu" fullname="Kazuhiko Minematsu"/>
            <date year="2025"/>
          </front>
          <seriesInfo name="DOI" value="10.1007/978-3-031-88661-4_4"/>
          <refcontent>Topics in Cryptology - CT-RSA 2025, Lecture Notes in Computer Science, vol. 15598</refcontent>
        </reference>
        <reference anchor="JMV2002" quoteTitle="true" target="https://doi.org/10.1007/3-540-45708-9_2" derivedAnchor="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, Lecture Notes in Computer Science, vol. 2442</refcontent>
        </reference>
        <reference anchor="JNPS21" quoteTitle="true" target="https://doi.org/10.1007/s00145-021-09397-w" derivedAnchor="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, vol. 34, no. 31</refcontent>
        </reference>
        <reference anchor="KLLNP16" quoteTitle="true" target="https://doi.org/10.13154/tosc.v2016.i1.71-94" derivedAnchor="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="2016"/>
          </front>
          <seriesInfo name="DOI" value="10.13154/tosc.v2016.i1.71-94"/>
          <refcontent> IACR Transactions on Symmetric Cryptology, vol. 2016, no.1, pp. 71-94</refcontent>
        </reference>
        <reference anchor="LGR21" quoteTitle="true" derivedAnchor="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), pp. 195-212</refcontent>
        </reference>
        <reference anchor="LMP17" quoteTitle="true" target="https://doi.org/10.1007/978-3-319-70697-9_20" derivedAnchor="LMP17">
          <front>
            <title>Analyzing 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>Advances in Cryptology - ASIACRYPT 2017, Lecture Notes in Computer Science, vol. 10625, pp. 575-605</refcontent>
        </reference>
        <reference anchor="M05" quoteTitle="true" target="https://doi.org/10.1109/SISW.2005.3" derivedAnchor="M05">
          <front>
            <title>Efficient authentication of large, dynamic data sets using Galois/Counter Mode (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-94</refcontent>
        </reference>
        <reference anchor="MBTM17" quoteTitle="true" target="https://doi.org/10.6028/NIST.IR.8114" derivedAnchor="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="MLGR23" quoteTitle="true" target="https://doi.org/10.1007/978-3-031-30634-1_13" derivedAnchor="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, Lecture Notes in Computer Science, vol. 14007, pp. 379-407</refcontent>
        </reference>
        <reference anchor="R02" quoteTitle="true" target="https://doi.org/10.1145/586110.586125" derivedAnchor="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 on Computer and Communications Security (CCS '02), pp. 98-107</refcontent>
        </reference>
        <reference anchor="RFC4303" target="https://www.rfc-editor.org/info/rfc4303" quoteTitle="true" derivedAnchor="RFC4303">
          <front>
            <title>IP Encapsulating Security Payload (ESP)</title>
            <author fullname="S. Kent" initials="S." surname="Kent"/>
            <date month="December" year="2005"/>
            <abstract>
              <t indent="0">This document describes an updated version of the Encapsulating Security Payload (ESP) protocol, which is designed to provide a mix of security services in IPv4 and IPv6. ESP is used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and limited traffic flow confidentiality. This document obsoletes RFC 2406 (November 1998). [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4303"/>
          <seriesInfo name="DOI" value="10.17487/RFC4303"/>
        </reference>
        <reference anchor="RFC7253" target="https://www.rfc-editor.org/info/rfc7253" quoteTitle="true" derivedAnchor="RFC7253">
          <front>
            <title>The OCB Authenticated-Encryption Algorithm</title>
            <author fullname="T. Krovetz" initials="T." surname="Krovetz"/>
            <author fullname="P. Rogaway" initials="P." surname="Rogaway"/>
            <date month="May" year="2014"/>
            <abstract>
              <t indent="0">This document specifies OCB, a shared-key blockcipher-based encryption scheme that provides confidentiality and authenticity for plaintexts and authenticity for associated data. This document is a product of the Crypto Forum Research Group (CFRG).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7253"/>
          <seriesInfo name="DOI" value="10.17487/RFC7253"/>
        </reference>
        <reference anchor="RFC8221" target="https://www.rfc-editor.org/info/rfc8221" quoteTitle="true" derivedAnchor="RFC8221">
          <front>
            <title>Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)</title>
            <author fullname="P. Wouters" initials="P." surname="Wouters"/>
            <author fullname="D. Migault" initials="D." surname="Migault"/>
            <author fullname="J. Mattsson" initials="J." surname="Mattsson"/>
            <author fullname="Y. Nir" initials="Y." surname="Nir"/>
            <author fullname="T. Kivinen" initials="T." surname="Kivinen"/>
            <date month="October" year="2017"/>
            <abstract>
              <t indent="0">This document replaces RFC 7321, "Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)". The goal of this document is to enable ESP and AH to benefit from cryptography that is up to date while making IPsec interoperable.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8221"/>
          <seriesInfo name="DOI" value="10.17487/RFC8221"/>
        </reference>
        <reference anchor="RFC8439" target="https://www.rfc-editor.org/info/rfc8439" quoteTitle="true" derivedAnchor="RFC8439">
          <front>
            <title>ChaCha20 and Poly1305 for IETF Protocols</title>
            <author fullname="Y. Nir" initials="Y." surname="Nir"/>
            <author fullname="A. Langley" initials="A." surname="Langley"/>
            <date month="June" year="2018"/>
            <abstract>
              <t indent="0">This document defines the ChaCha20 stream cipher as well as the use of the Poly1305 authenticator, both as stand-alone algorithms and as a "combined mode", or Authenticated Encryption with Associated Data (AEAD) algorithm.</t>
              <t indent="0">RFC 7539, the predecessor of this document, was meant to serve as a stable reference and an implementation guide. It was a product of the Crypto Forum Research Group (CFRG). This document merges the errata filed against RFC 7539 and adds a little text to the Security Considerations section.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8439"/>
          <seriesInfo name="DOI" value="10.17487/RFC8439"/>
        </reference>
        <reference anchor="RFC8446" target="https://www.rfc-editor.org/info/rfc8446" quoteTitle="true" derivedAnchor="RFC8446">
          <front>
            <title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
            <author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
            <date month="August" year="2018"/>
            <abstract>
              <t indent="0">This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t>
              <t indent="0">This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8446"/>
          <seriesInfo name="DOI" value="10.17487/RFC8446"/>
        </reference>
        <reference anchor="RFC8452" target="https://www.rfc-editor.org/info/rfc8452" quoteTitle="true" derivedAnchor="RFC8452">
          <front>
            <title>AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption</title>
            <author fullname="S. Gueron" initials="S." surname="Gueron"/>
            <author fullname="A. Langley" initials="A." surname="Langley"/>
            <author fullname="Y. Lindell" initials="Y." surname="Lindell"/>
            <date month="April" year="2019"/>
            <abstract>
              <t indent="0">This memo specifies two authenticated encryption algorithms that are nonce misuse resistant -- that is, they do not fail catastrophically if a nonce is repeated.</t>
              <t indent="0">This document is the product of the Crypto Forum Research Group.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8452"/>
          <seriesInfo name="DOI" value="10.17487/RFC8452"/>
        </reference>
        <reference anchor="RFC8645" target="https://www.rfc-editor.org/info/rfc8645" quoteTitle="true" derivedAnchor="RFC8645">
          <front>
            <title>Re-keying Mechanisms for Symmetric Keys</title>
            <author fullname="S. Smyshlyaev" initials="S." role="editor" surname="Smyshlyaev"/>
            <date month="August" year="2019"/>
            <abstract>
              <t indent="0">A certain maximum amount of data can be safely encrypted when encryption is performed under a single key. This amount is called the "key lifetime". This specification describes a variety of methods for increasing the lifetime of symmetric keys. It provides two types of re-keying mechanisms based on hash functions and block ciphers that can be used with modes of operations such as CTR, GCM, CBC, CFB, and OMAC.</t>
              <t indent="0">This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8645"/>
          <seriesInfo name="DOI" value="10.17487/RFC8645"/>
        </reference>
        <reference anchor="RFC9000" target="https://www.rfc-editor.org/info/rfc9000" quoteTitle="true" derivedAnchor="RFC9000">
          <front>
            <title>QUIC: A UDP-Based Multiplexed and Secure Transport</title>
            <author fullname="J. Iyengar" initials="J." role="editor" surname="Iyengar"/>
            <author fullname="M. Thomson" initials="M." role="editor" surname="Thomson"/>
            <date month="May" year="2021"/>
            <abstract>
              <t indent="0">This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9000"/>
          <seriesInfo name="DOI" value="10.17487/RFC9000"/>
        </reference>
        <reference anchor="RFC9058" target="https://www.rfc-editor.org/info/rfc9058" quoteTitle="true" derivedAnchor="RFC9058">
          <front>
            <title>Multilinear Galois Mode (MGM)</title>
            <author fullname="S. Smyshlyaev" initials="S." role="editor" surname="Smyshlyaev"/>
            <author fullname="V. Nozdrunov" initials="V." surname="Nozdrunov"/>
            <author fullname="V. Shishkin" initials="V." surname="Shishkin"/>
            <author fullname="E. Griboedova" initials="E." surname="Griboedova"/>
            <date month="June" year="2021"/>
            <abstract>
              <t indent="0">Multilinear Galois Mode (MGM) is an Authenticated Encryption with Associated Data (AEAD) block cipher mode based on the Encrypt-then-MAC (EtM) principle. MGM is defined for use with 64-bit and 128-bit block ciphers.</t>
              <t indent="0">MGM has been standardized in Russia. It is used as an AEAD mode for the GOST block cipher algorithms in many protocols, e.g., TLS 1.3 and IPsec. This document provides a reference for MGM to enable review of the mechanisms in use and to make MGM available for use with any block cipher.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9058"/>
          <seriesInfo name="DOI" value="10.17487/RFC9058"/>
        </reference>
        <reference anchor="RS06" quoteTitle="true" target="https://doi.org/10.1007/11761679_23" derivedAnchor="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, Lecture Notes in Computer Science, vol. 4004, pp. 373-390</refcontent>
        </reference>
        <reference anchor="S04" target="https://eprint.iacr.org/2004/272" quoteTitle="true" derivedAnchor="S04">
          <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="SY16" quoteTitle="true" target="https://doi.org/10.1007/978-3-319-31301-6_23" derivedAnchor="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, Lecture Notes in Computer Science, vol. 9566, pp. 397-416</refcontent>
        </reference>
        <reference anchor="YSS23" quoteTitle="true" target="https://doi.org/10.46586/tosc.v2023.i4.420-451" derivedAnchor="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, vol. 2023, no. 4, pp. 420-451</refcontent>
        </reference>
      </references>
    </references>
    <section anchor="AddProp" numbered="true" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-aead-algorithms-with-additi">AEAD Algorithms with Additional Functionality</name>
      <t indent="0" pn="section-appendix.a-1">
				In this section, we briefly discuss AEAD algorithms that provide additional functionality. As noted in <xref target="Classification" format="default" sectionFormat="of" derivedContent="Section 4.1"/>, each additional functionality requires a redefinition of the conventional AEAD interface; thus, each additional functionality property defines a new class of cryptographic algorithms.
      </t>
      <t indent="0" pn="section-appendix.a-2">
				Most importantly, for every AEAD class with additional functionality, conventional security properties must be redefined concerning the targeted additional functionality and the new interface. Although it might be possible to consider a particular AEAD algorithm with additional functionality as a conventional AEAD algorithm and study it for the conventional confidentiality and integrity, security (or insecurity) in that sense won't be sufficient to label that algorithm as a secure (or insecure) additional functionality AEAD. Only security in the sense of the redefined conventional properties would suffice.
      </t>
      <t indent="0" pn="section-appendix.a-3">
				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="include" removeInRFC="false" pn="section-appendix.a.1">
        <name slugifiedName="name-incremental-authenticated-e">Incremental Authenticated Encryption</name>
        <dl spacing="normal" newline="true" indent="3" pn="section-appendix.a.1-1">
          <dt pn="section-appendix.a.1-1.1">Definition:</dt>
          <dd pn="section-appendix.a.1-1.2">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.</dd>
          <dt pn="section-appendix.a.1-1.3">Examples:</dt>
          <dd pn="section-appendix.a.1-1.4">Incremental AEAD algorithm of <xref target="SY16" format="default" sectionFormat="of" derivedContent="SY16"/></dd>
          <dt pn="section-appendix.a.1-1.5">Security notions:</dt>
          <dd pn="section-appendix.a.1-1.6">Privacy, authenticity <xref target="SY16" format="default" sectionFormat="of" derivedContent="SY16"/></dd>
          <dt pn="section-appendix.a.1-1.7">Notes:</dt>
          <dd pn="section-appendix.a.1-1.8">When compared with conventional AEAD, the interface of an incremental AEAD algorithm is
     usually expanded with several
     operations, which perform different types of updates. For example, one
     can consider operations such as "Append" or "Chop", which provide a
     straightforward additional functionality. A comprehensive definition of
     an incremental AEAD interface is provided in <xref target="SY16" format="default" sectionFormat="of" derivedContent="SY16"/>.</dd>
          <dt pn="section-appendix.a.1-1.9">Further reading:</dt>
          <dd pn="section-appendix.a.1-1.10">
            <xref target="SY16" format="default" sectionFormat="of" derivedContent="SY16"/>,
     <xref target="M05" format="default" sectionFormat="of" derivedContent="M05"/>, <xref target="BKY02" format="default" sectionFormat="of" derivedContent="BKY02"/></dd>
        </dl>
      </section>
      <section anchor="Robust" numbered="true" toc="include" removeInRFC="false" pn="section-appendix.a.2">
        <name slugifiedName="name-robust-authenticated-encryp">Robust Authenticated Encryption</name>
        <dl spacing="normal" newline="true" indent="3" pn="section-appendix.a.2-1">
          <dt pn="section-appendix.a.2-1.1">Definition:</dt>
          <dd pn="section-appendix.a.2-1.2">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.</dd>
          <dt pn="section-appendix.a.2-1.3">Examples:</dt>
          <dd pn="section-appendix.a.2-1.4">AEZ <xref target="HKR2015" format="default" sectionFormat="of" derivedContent="HKR2015"/></dd>
          <dt pn="section-appendix.a.2-1.5">Security notions:</dt>
          <dd pn="section-appendix.a.2-1.6">Robust Authenticated Encryption (RAE) <xref target="HKR2015" format="default" sectionFormat="of" derivedContent="HKR2015"/></dd>
          <dt pn="section-appendix.a.2-1.7">Notes:</dt>
          <dd pn="section-appendix.a.2-1.8">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.</dd>
          <dt pn="section-appendix.a.2-1.9">Further reading:</dt>
          <dd pn="section-appendix.a.2-1.10">
            <xref target="HKR2015" format="default" sectionFormat="of" derivedContent="HKR2015"/></dd>
        </dl>
      </section>
    </section>
    <section anchor="Acknowledgments" numbered="false" toc="include" removeInRFC="false" pn="section-appendix.b">
      <name slugifiedName="name-acknowledgments">Acknowledgments</name>
      <t indent="0" pn="section-appendix.b-1">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 <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>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.c">
      <name slugifiedName="name-authors-address">Author's Address</name>
      <author fullname="Andrey Bozhko" initials="A" role="editor" surname="Bozhko">
        <organization showOnFrontPage="true">CryptoPro</organization>
        <address>
          <email>andbogc@gmail.com</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
