rfc9771.original.xml   rfc9771.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-irtf-cfrg-aead-pr
operties-09" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" cat <rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-irtf-cfrg-aead-pr
egory="info" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRef operties-09" number="9771" ipr="trust200902" obsoletes="" updates="" submissionT
s="true" version="3"> ype="IRTF" category="info" consensus="true" xml:lang="en" tocInclude="true" tocD
<front> epth="4" symRefs="true" sortRefs="true" version="3">
<title abbrev="Properties of AEAD algorithms">Properties of AEAD
Algorithms</title> <!-- [rfced] Please note that the title of the document has been updated as
<seriesInfo name="Internet-Draft" value="draft-irtf-cfrg-aead-pro follows. Abbreviations have been expanded per Section 3.6 of RFC 7322 ("RFC
perties-09" /> Style Guide"). Please review.
<author fullname="Andrey Bozhko" initials="A.A." role="editor" su
rname="Bozhko"> Original:
<organization>CryptoPro</organization> Properties of AEAD Algorithms
<address>
<email>andbogc@gmail.com</email> Current:
</address> Properties of Authenticated Encryption with Associated Data (AEAD)
</author> Algorithms
<date year="2024" /> -->
<area>General</area>
<workgroup>Crypto Forum</workgroup> <front>
<keyword>authenticated encryption, mode of operation, AEAD, prope <title abbrev="Properties of AEAD Algorithms">Properties of Authenticated En
rties</keyword> cryption with Associated Data (AEAD) Algorithms</title>
<abstract> <seriesInfo name="RFC" value="9771"/>
<t> <author fullname="Andrey Bozhko" initials="A" role="editor" surname="Bozhko"
Authenticated Encryption with Associated Data (AE >
AD) algorithms provide both confidentiality and integrity of data. The widesprea <organization>CryptoPro</organization>
d use of AEAD algorithms in various applications has led to an increased demand <address>
for AEAD algorithms with additional properties, driving research in the field. T <email>andbogc@gmail.com</email>
his document provides definitions for the most common of those properties, aimin </address>
g to improve consistency in the terminology used in documentation. This document </author>
is a product of the Crypto Forum Research Group. <date year="2025" month="April"/>
<workgroup>Crypto Forum</workgroup>
<keyword>authenticated encryption</keyword>
<keyword>mode of operation</keyword>
<keyword>AEAD</keyword>
<keyword>properties</keyword>
<!-- [rfced] Please ensure that the guidelines listed in Section 2.1 of RFC
5743 have been adhered to in this document. See
https://www.rfc-editor.org/rfc/rfc5743.html#section-2.1.
-->
<abstract>
<t> Authenticated Encryption with Associated Data (AEAD) algorithms
provide both confidentiality and integrity of data. The widespread use
of AEAD algorithms in various applications has led to an increased
demand for AEAD algorithms with additional properties, driving research
in the field. This document provides definitions for the most common of
those properties and aims to improve consistency in the terminology used
in documentation. This document is a product of the Crypto Forum
Research Group.
</t> </t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="Introduction" numbered="true" toc="default"> <section anchor="Introduction" numbered="true" toc="default">
<name>Introduction</name> <name>Introduction</name>
<t>An Authenticated Encryption with Associated Data (AEAD ) algorithm provides confidentiality for the plaintext to be encrypted and integ rity for the plaintext and some associated data (sometimes called Header). AEAD algorithms play a crucial role in various applications and have emerged as a sig nificant focus in cryptographic research.</t> <t>An Authenticated Encryption with Associated Data (AEAD ) algorithm provides confidentiality for the plaintext to be encrypted and integ rity for the plaintext and some associated data (sometimes called "Header"). AEA D algorithms play a crucial role in various applications and have emerged as a s ignificant focus in cryptographic research.</t>
<section anchor="IntBack" numbered="true" toc="default"> <section anchor="IntBack" numbered="true" toc="default">
<name>Background</name> <name>Background</name>
<t> <t>
AEAD algorithms are formally defined in < xref target="RFC5116" format="default"/>. The main benefit of AEAD algorithms is that they simultaneously provide data confidentiality and integrity and have a simple unified interface. In contrast to generic compositions of Message Authent ication Code (MAC) and encryption algorithms, an AEAD algorithm allows for a red uction in key and state sizes, improving the data processing speed. Most AEAD al gorithms come with security analysis, usage guidelines, and reference implementa tions. Consequently, their integration into high-level schemes and protocols is highly transparent. For instance, AEAD algorithms are mandatory in TLS 1.3 <xref target="RFC8446" format="default" />, IPsec ESP <xref target="RFC4303" format=" default" /><xref target="RFC8221" format="default" />, and QUIC <xref target="RF C9000" format="default" />. AEAD algorithms are formally defined in < xref target="RFC5116" format="default"/>. The main benefit of AEAD algorithms is that they simultaneously provide data confidentiality and integrity and have a simple unified interface. In contrast to generic compositions of Message Authent ication Code (MAC) and encryption algorithms, an AEAD algorithm allows for a red uction in key and state sizes, improving the data processing speed. Most AEAD al gorithms come with security analysis, usage guidelines, and reference implementa tions. Consequently, their integration into high-level schemes and protocols is highly transparent. For instance, AEAD algorithms are mandatory in TLS 1.3 <xref target="RFC8446" format="default" />, IPsec Encapsulating Security Payload (ESP ) <xref target="RFC4303" format="default" /> <xref target="RFC8221" format="defa ult" />, and QUIC <xref target="RFC9000" format="default" />.
</t> </t>
<t> <t>
While confidentiality and data integrity, being the conventional properties of AEAD algorithms, suffice for many applicat ions, some environments demand other uncommon cryptographic properties. These of ten require additional analysis and research. As the number of such properties a nd corresponding research papers grows, inevitable misunderstandings and confusi on arise. It is a common situation when related but formally different propertie s are named identically, or some security properties only have folklore understa nding and are not formally defined. Consequently, the risk of misusing AEAD algo rithms increases, potentially resulting in security issues. While confidentiality and data integrity (the conventional properties of AEAD algorithms) suffice for many applications, some environments demand other uncommon cryptographic properties. These often re quire additional analysis and research. As the number of such properties and cor responding research papers grows, inevitable misunderstandings and confusion ari se. This is a common situation when related but formally different properties ar e named identically or when some security properties only have folklore understa nding and are not formally defined. Consequently, the risk of misusing AEAD algo rithms increases, potentially resulting in security issues.
</t> </t>
</section> </section>
<section anchor="IntScope" numbered="true" toc="default"> <section anchor="IntScope" numbered="true" toc="default">
<name>Scope</name> <name>Scope</name>
<t> <t>
In this document, in <xref target="Proper ties" format="default"/>, we provide the list of the most common additional prop erties of AEAD algorithms. The properties are divided into two categories, namel y security properties (see <xref target="SecurityProp" format="default"/>) and i mplementation properties (see <xref target="ImpProp" format="default"/>). In <xref target="Properties" format="defa ult"/> of this document, we provide a list of the most common additional propert ies of AEAD algorithms. The properties are divided into two categories, namely, security properties (see <xref target="SecurityProp" format="default"/>) and imp lementation properties (see <xref target="ImpProp" format="default"/>).
We provide a high-level definition for ea ch property. For security properties, we also reference an informative source wh ere 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 t he property, applications that might necessitate such property from an AEAD algo rithm, references for further reading, and additional notes containing informati on outside these categories. We provide a high-level definition for ea ch property. For security properties, we also reference an informative source wh ere 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 t he property, applications that might necessitate the property from an AEAD algor ithm, references for further reading, and additional notes containing informatio n outside these categories.
</t> </t>
<t> <t>
The objective of this document is to enha nce clarity and establish a common language in the field. In particular, the pri mary application of the document lies in the following two use cases within the IRTF or the IETF documents development process: The objective of this document is to enha nce clarity and establish a common language in the field. In particular, the pri mary application of the document lies in the following two use cases within the document development process in the IRTF and IETF:
</t> </t>
<ul> <ul>
<li> <li>
<t>For an RFC or I-D that defines an AEAD algorithm, it is recommended to use the notations of <xref target="Prop erties" format="default"/> when listing additional properties of the algorithm.< /t> <t>For an RFC or I-D that defines an AEAD algorithm, it is recommended to use the notations in <xref target="Prop erties" format="default"/> when listing additional properties of the algorithm.< /t>
</li> </li>
<li> <li>
<t>For an RFC or I-D that defines a generic protocol based on an AEAD algorithm, it is recommended to use the not ations of <xref target="Properties" format="default"/> if any additional propert ies are required from the algorithm.</t> <t>For an RFC or I-D that defines a generic protocol based on an AEAD algorithm, it is recommended to use the not ations in <xref target="Properties" format="default"/> if any additional propert ies are required from the algorithm.</t>
</li> </li>
</ul> </ul>
<t> <t>
This document represents the consensus of the Crypto Forum Research Group (CFRG). This document is not an IETF product an d is not a standard. This document represents the consensus of the Crypto Forum Research Group (CFRG). This document is not an IETF product an d is not a standard.
</t> </t>
</section> </section>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Conventions Used in This Document</name> <name>Conventions Used in This Document</name>
<t> <t>
The key words "MUST", "MUST NOT", "REQUIRED", "SH The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
ALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MA IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
Y", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
<xref target="RFC2119" format="default" /><xref target="RFC8174" format="defaul RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
t" /> when, and only when, they appear in all capitals, as shown here. "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
</t> be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section> </section>
<section anchor="AEAD" numbered="true" toc="default"> <section anchor="AEAD" numbered="true" toc="default">
<name>AEAD Algorithms</name> <name>AEAD Algorithms</name>
<t>
This section gives a conventional definition of a <t> This section gives a conventional definition of an AEAD
n AEAD algorithm following <xref target="RFC5116" format="default"/>. algorithm following <xref target="RFC5116" format="default"/>. </t>
</t>
<t> <dl newline="true" spacing="normal">
Definition: An AEAD algorithm is defined by two o <dt>Definition:</dt>
perations, which are authenticated encryption and authenticated decryption: <dd><t>An AEAD algorithm is defined by two operations, which are
</t> authenticated encryption and authenticated decryption:</t>
<ul> <ul spacing="normal">
<li> <li>A deterministic operation of authenticated encryption
<t>A deterministic operation of a has four inputs, each a binary string: a secret key K of a fixed
uthenticated encryption has four inputs, each a binary string: a secret key K of bit length, a nonce N, associated data A, and a plaintext P. The
a fixed bit length, a nonce N, associated data A, and a plaintext P. The plaint plaintext contains the data to be encrypted and authenticated,
ext contains the data to be encrypted and authenticated, and the associated data and the associated data contains the data to be authenticated
contains the data to be authenticated only. Each nonce value MUST be unique in only. Each nonce value <bcp14>MUST</bcp14> be unique in every
every distinct invocation of the operation for any particular value of the key. distinct invocation of the operation for any particular value of
The authenticated encryption operation outputs a ciphertext C.</t> the key. The authenticated encryption operation outputs a
</li> ciphertext C.</li>
<li> <li>A deterministic operation of authenticated decryption has
<t>A deterministic operation of a four inputs, each a binary string: a secret key K of a fixed bit
uthenticated decryption has four inputs, each a binary string: a secret key K of length, a nonce N, associated data A, and a ciphertext C. The
a fixed bit length, a nonce N, associated data A, and a ciphertext C. The opera operation verifies the integrity of the ciphertext and
tion verifies the integrity of the ciphertext and associated data and decrypts t associated data and decrypts the ciphertext. It returns a
he ciphertext. It returns a special symbol FAIL if the inputs are not authentic; special symbol FAIL if the inputs are not authentic; otherwise,
otherwise, the operation returns a plaintext P.</t> the operation returns a plaintext P.</li>
</li> </ul>
</ul> </dd>
<t> </dl>
We note that specifications of AEAD algorithms th <!-- [rfced] Will readers understand what "it" refers to here?
at use authentication tags to ensure integrity MAY define it as an independent o
utput of the encryption operation and as an independent input of the decryption Original:
operation. Throughout this document, by default, we will consider the authentica We note that specifications of AEAD algorithms that use
tion tag as part of the ciphertext. authentication tags to ensure integrity MAY define it as an
independent output of the encryption operation and as an independent
input of the decryption operation.
-->
<t>We note that specifications of AEAD algorithms that use
authentication tags to ensure integrity <bcp14>MAY</bcp14> define
it as an independent output of the encryption operation and as an
independent input of the decryption operation. Throughout this
document, by default, we consider the authentication tag as
part of the ciphertext.
</t> </t>
<t> <t>
For more details on the AEAD definition, please r efer to <xref target="RFC5116" format="default" />. For more details on the AEAD definition, please r efer to <xref target="RFC5116" format="default" />.
</t> </t>
<t> <t>
Throughout this document, by default, we will con sider nonce-based AEAD algorithms, which have an interface from the definition a bove, and give no other restrictions on their structure. However, some propertie s considered in the document apply only to particular classes of such algorithms , like block cipher-based AEAD algorithms (such algorithms use block cipher as a building block). If that is the case, we explicitly point that out in the corre sponding section. Throughout this document, by default, we consider nonce-based AEAD algorithms, which have an interface as defined above, and we g ive no other restrictions on their structure. However, some properties considere d 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 buil ding block). If that is the case, we explicitly point that out in the correspond ing section.
</t> </t>
</section> </section>
<section anchor="Properties" numbered="true" toc="default"> <section anchor="Properties" numbered="true" toc="default">
<name>AEAD Properties</name> <name>AEAD Properties</name>
<section anchor="Classification" numbered="true" toc="def <section anchor="Classification" numbered="true" toc="default">
ault"> <name>Classification of Additional AEAD Properties</name>
<name>Classification of additional AEAD Propertie <t>In this document, we employ a high-level classification of
s</name> additional properties. This classification aims to provide insight
<t> into how one can benefit from each property. The additional
In this document, we employ a high-level properties are categorized into one of these two
classification of additional properties. This classification aims to provide ins groups:</t>
ight into how one can benefit from each property. The additional properties in t <ul spacing="normal">
his section are categorized into one of these two groups: <li>Security properties: We classify a property as a security
</t> property if it either takes into account new threats or extends
<ul> adversarial capabilities, in addition to those posed by the
<li> typical nonce-respecting adversary whose goal is to compromise
<t> confidentiality or data integrity.</li>
Security properties: We c <li>Implementation properties: We classify a property as an
lassify a property as a security property if it either takes into account new th implementation property if it enables more efficient
reats or extends adversarial capabilities, in addition to those posed by the typ implementations of the AEAD algorithm in specific cases or
ical nonce-respecting adversary whose goal is to compromise confidentiality or d environments.</li>
ata integrity. </ul>
</t> <t> We note that some additional properties of AEAD algorithms
</li> found in the literature could not be allocated to either of these
<li> two groups. The observation is that such properties require an
<t> extension of the conventional AEAD interface. We refer to these
Implementation properties properties as "additional functionality properties" and define the
: We classify a property as an implementation property if it enables more effici corresponding group as follows:</t>
ent implementations of the AEAD algorithm in specific cases or environments. <ul spacing="normal">
</t> <li>Additional functionality properties: We classify a property
</li> as an additional functionality property if it introduces new
</ul> features in addition to the standard AEAD.</li>
<t> </ul>
We note that some additional properties o <t> With the extension of the conventional AEAD interface, each
f AEAD algorithms found in the literature could not be allocated to either of th additional functionality property defines a new class of
ese two groups. The observation is that such properties require an extension of cryptographic algorithms. Consequently, the basic threats and
the conventional AEAD interface. We refer to these properties as 'additional fun adversarial capabilities must be redefined for each class. As a
ctionality properties' and define the corresponding group as follows: result, additional functionality properties consider the basic
</t> threats and adversarial capabilities for their class of
<ul> algorithms, in contrast to security properties, which consider the
extended ones. For this reason, we do not focus on additional
<li> functionality properties in this document. However, for the sake
<t> of completeness, in <xref target="AddProp" format="default"/>, we
Additional functionality briefly present two classes of AEAD algorithms with additional
properties: We classify a property as an additional functionality property if it functionality.
introduces new features in addition to the standard authenticated encryption wi
th associated data.
</t>
</li>
</ul>
<t>
With the extension of the conventional AE
AD interface, each additional functionality property defines a new class of cryp
tographic algorithms. Consequently, the basic threats and adversarial capabiliti
es must be redefined for each class. As a result, additional functionality prope
rties consider the basic threats and adversarial capabilities for their class of
algorithms, in contrast to security properties, which consider the extended one
s. For this reason, we do not focus on additional functionality properties in th
is document. However, for the sake of completeness, in <xref target="AddProp" fo
rmat="default"/>, we briefly present two classes of AEAD algorithms with additio
nal functionality.
</t> </t>
</section> </section>
<section anchor="Base" numbered="true" toc="default"> <section anchor="Base" numbered="true" toc="default">
<name>Conventional Properties</name> <name>Conventional Properties</name>
<t> <t>In this section, we recall the conventional properties of an AEAD
In this section, we recall the convention algorithm. Active nonce-respecting adversaries in a single-key setting are
al properties of an AEAD algorithm. Active nonce-respecting adversaries in a sin considered.
gle-key setting are considered. </t>
</t> <t>
<t> We say that an AEAD algorithm provides security if it provides the conventi
We say that an AEAD algorithm provides se onal properties listed in this section.
curity if it provides conventional properties listed in this section. </t>
</t> <section anchor="Conf" numbered="true" toc="default">
<section anchor="Conf" numbered="true" toc="defau <name>Confidentiality</name>
lt">
<name>Confidentiality</name>
<t>
Definition: An AEAD algorithm gua
rantees that the plaintext is not available to an active, nonce-respecting adver
sary.
</t>
<t>
Security notion: IND-CCA <xref ta
rget="BN2000" format="default"/> (or IND-CCA2 <xref target="S04" format="default
"/>).
</t>
<t>
Synonyms: Message privacy.
</t>
<t>
Notes: Confidentiality against pa
ssive adversaries can also be considered. The corresponding security notion is I
ND-CPA <xref target="BN2000" format="default"/><xref target="R02" format="defaul
t"/>.
</t>
<t>
Further reading: <xref target="R0
2" format="default"/>, <xref target="BN2000" format="default"/>, <xref target="S
04" format="default"/>.
</t>
</section>
<section anchor="Int" numbered="true" toc="defaul <dl spacing="normal" newline="true">
t"> <dt>Definition:</dt><dd>An AEAD algorithm guarantees that the plaintext i
<name>Data Integrity</name> s not
<t> available to an active, nonce-respecting adversary.</dd>
Definition: An AEAD algorithm all <dt>Security notion:</dt><dd>IND-CCA <xref target="BN2000"
ows one to ensure that the ciphertext and the associated data have not been chan format="default"/> (or IND-CCA2 <xref target="S04" format="default"/>)</d
ged or forged by an active, nonce-respecting adversary. d>
</t> <dt>Synonyms:</dt><dd>Message privacy</dd>
<t> <dt>Notes:</dt><dd>Confidentiality against passive adversaries can also
Security notion: IND-CTXT <xref t be considered. The corresponding security notion is IND-CPA <xref
arget="BN2000" format="default"/> (or AUTH <xref target="R02" format="default"/> target="BN2000" format="default"/> <xref target="R02"
). format="default"/>.</dd>
</t> <dt>Further reading:</dt><dd><xref target="R02" format="default"/>,
<t> <xref target="BN2000" format="default"/>, <xref target="S04"
Synonyms: Message authentication, format="default"/></dd>
authenticity. </dl>
</t> </section>
<t>
Further reading: <xref target="R0
2" format="default"/>, <xref target="BN2000" format="default"/>, <xref target="S
04" format="default"/>.
</t>
</section>
<section anchor="AE" numbered="true" toc="default <!-- [rfced] Please confirm that "IND-CTXT" is correct here. We ask because we
"> do not see "IND-CTXT" in [BN2000], but we do see "INT-CTXT".
<name>Authenticated Encryption Security</
name>
<t>
Definition: An AEAD algorithm pro
vides confidentiality and data integrity against active, nonce-respecting advers
aries.
</t>
<t>
Security notion: IND-CPA and IND-
CTXT <xref target="BN2000" format="default"/><xref target="R02" format="default"
/> (or equivalently IND-CCA3 <xref target="S04" format="default"/>).
</t>
<t>
Notes: Please refer to <xref targ
et="I-D.irtf-cfrg-aead-limits" format="default"/> for usage limits on modern AEA
D algorithms used in IETF protocols.
</t>
<t>
Further reading: <xref target="R0
2" format="default"/>, <xref target="BN2000" format="default"/>, <xref target="S
04" format="default"/>.
</t>
</section>
</section> Original:
Security notion: IND-CTXT [BN2000] (or AUTH [R02]).
<section anchor="SecurityProp" numbered="true" toc="defau Security notion: IND-CPA and IND-CTXT [BN2000][R02] (or equivalently
lt"> IND-CCA3 [S04]).
<name>Security Properties</name> -->
<section anchor="BWsec" numbered="true" toc="defa
ult">
<name>Blockwise Security</name>
<t>
Definition: An AEAD algorithm pro
vides security even if an adversary can adaptively choose the next part of the p
laintext depending on already computed ciphertext parts during an encryption ope
ration.
</t>
<t>
Security notion: D-LORS-BCPA for
confidentiality against passive adversaries, B-INT-CTXT for integrity <xref targ
et="EV16" format="default"/>; OAE1 <xref target="HRRV15" format="default"/> (a s
tronger notion; originally OAE (Online Authenticated Encryption) in <xref target
="FFL12" format="default"/>).
</t>
<t>
Examples: Deoxys <xref target="JN
PS21" format="default"/>, SAEF <xref target="ABV21" format="default"/>.
</t>
<t>
Notes: Blockwise security is high
ly relevant for streamable AEAD algorithms (see <xref target="Online" format="de
fault"/>). The OAE1 security notion <xref target="HRRV15" format="default"/>, an
d the OAE2 notion <xref target="HRRV15" format="default"/> are tailored for stre
amable AEAD algorithms. OAE1 was first defined in <xref target="FFL12" format="d
efault"/> under the name OAE; however, it contained a glitch, and the reformulat
ed definition was presented in <xref target="HRRV15" format="default"/>. Blockwi
se security follows from security in the OAE notion <xref target="EV16" format="
default"/>. For a discussion on security notions for streamable AEAD algorithms
see <xref target="HRRV15" format="default"/>.
</t>
<t>
Applications: Real-time streaming
protocols, encryption on resource-constrained devices.
</t>
<t>
Further reading: <xref target="EV
16" format="default"/>, <xref target="JMV2002" format="default"/>, <xref target=
"FJMV2004" format="default"/>, <xref target="HRRV15" format="default"/>.
</t>
</section>
<section anchor="FullComm" numbered="true" toc="d <section anchor="Int" numbered="true" toc="default">
efault"> <name>Data Integrity</name>
<name>Full Commitment</name> <dl spacing="normal" newline="true">
<t> <dt>Definition:</dt><dd>An AEAD algorithm allows one to ensure that the
Definition: An AEAD algorithm gua ciphertext and the associated data have not been changed or forged by
rantees that it is hard to find two or more different tuples of the key, nonce, an active, nonce-respecting adversary.</dd>
associated data, and plaintext such that they encrypt to the same ciphertext. In <dt>Security notion:</dt><dd>IND-CTXT <xref target="BN2000"
other words, an AEAD scheme guarantees that a ciphertext is a commitment to all format="default"/> (or AUTH <xref target="R02"
inputs of an authenticated encryption operation. format="default"/>)</dd>
</t> <dt>Synonyms:</dt><dd>Message authentication, authenticity</dd>
<t> <dt>Further reading:</dt><dd><xref target="R02" format="default"/>,
Security notion: CMT-4 <xref targ <xref target="BN2000" format="default"/>, <xref target="S04"
et="BH22" format="default"/>, generalized CMT for a restricted setting (see the format="default"/></dd>
notes below) <xref target="MLGR23" format="default" />. </dl>
</t> </section>
<t>
Examples: Ascon <xref target="DEM
S21a" format="default"/><xref target="DEMS21b" format="default"/><xref target="Y
SS23" format="default"/>, full committing versions of GCM and GCM-SIV <xref targ
et="BH22" format="default"/>, generic constructions <xref target="BH22" format="
default"/><xref target="CR22" format="default" />.
</t>
<t>
Notes: Full commitment can be con
sidered in a weaker setting, where certain restrictions on the tuples produced b
y an adversary are imposed <xref target="MLGR23" format="default" />. For instan
ce, 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 restri
cted setting. The imposed restrictions MUST be listed.
</t>
<t>
Applications: Message franking <x
ref target="GLR17" format="default" />.
</t>
<t>
Further reading:
<xref target="BH22" format="defau
lt" />, <xref target="CR22" format="default" />, <xref target="MLGR23" format="d
efault" />.
</t>
</section>
<section anchor="KeyComm" numbered="true" toc="de
fault">
<name>Key Commitment</name>
<t>
Definition: An AEAD algorithm gua
rantees that it is hard to find two or more different keys and the same number o
f potentially equal triples of nonce, associated data, and plaintext such that t
hey encrypt to the same ciphertext under corresponding keys. In other words, an
AEAD scheme guarantees that a ciphertext is a commitment to the key used for an
authenticated encryption operation.
</t>
<t>
Security notion: CMT-1 <xref targ
et="BH22" format="default"/>.
</t>
<t>
Synonyms: Key-robustness, key co
llision resistance.
</t>
<t>
Examples: Ascon <xref target="DEM
S21a" format="default"/><xref target="DEMS21b" format="default"/><xref target="Y
SS23" format="default"/>, generic constructions from <xref target="BH22" format=
"default"/> <xref target="CR22" format="default"/>.
</t>
<t>
Notes: Key commitment follows fro
m full commitment. Full commitment does not follow from key commitment <xref tar
get="BH22" format="default" />.
</t>
<t>
Applications: Password-Authentica
ted Key Exchange, password-based encryption <xref target="LGR21" format="default
" />, key rotation, envelope encryption <xref target="ADGKLS22" format="default"
/>.
</t>
<t>
Further reading:
<xref target="BH22" format="defau
lt" />,<xref target="CR22" format="default" />, <xref target="FOR17" format="def
ault" />, <xref target="LGR21" format="default" />, <xref target="GLR17" format=
"default" />.
</t>
</section>
<section anchor="Leakage" numbered="true" toc="de <section anchor="AE" numbered="true" toc="default">
fault"> <name>Authenticated Encryption Security</name>
<name>Leakage Resistance</name> <dl newline="true" spacing="normal">
<t> <dt>Definition:</dt><dd>An AEAD algorithm provides confidentiality
Definition: An AEAD algorithm pro and data integrity against active, nonce-respecting adversaries.</dd>
vides security even if some additional information about computations of an encr <dt>Security notion:</dt><dd>IND-CPA and IND-CTXT <xref
yption (and possibly decryption) operation is obtained via side-channel leakages target="BN2000" format="default"/> <xref target="R02"
. format="default"/> (or equivalently, IND-CCA3 <xref target="S04"
</t> format="default"/>)</dd>
<t> <dt>Notes:</dt><dd>Please refer to <xref
Security notion: CIL1 <xref targe target="I-D.irtf-cfrg-aead-limits" format="default"/> for usage
t="GPPS19" format="default" /> (CIML2 <xref target="BPPS17" format="default" /> limits on modern AEAD algorithms used in IETF protocols.</dd>
with leakages in decryption) for integrity, CCAL1 <xref target="GPPS19" format=" <dt>Further reading:</dt><dd><xref target="R02" format="default"/>,
default" /> (CCAmL2 <xref target="GPPS19" format="default" /> with leakages in d <xref target="BN2000" format="default"/>, <xref target="S04"
ecryption) for Authenticated Encryption security. format="default"/></dd>
</t> </dl>
<t> </section>
Examples: Ascon <xref target="DEM
S21a" format="default"/><xref target="DEMS21b" format="default"/> (security unde
r CIML2 and CCAL1 notions <xref target="B20" format="default" />), TEDT <xref ta
rget="GPPS19" format="default" />.
</t>
<t>
Notes: Leakages during AEAD opera
tion executions are implementation-dependent. It is possible to implement symmet
ric algorithms in a way that every possible physical leakage is entirely indepen
dent of the secret inputs of the algorithm (for example, with a masking techniqu
e <xref target="CJRR99" format="default" />), meaning the adversary doesn't gain
any additional information about the algorithm's computation via side-channel l
eakages. We say that an AEAD algorithm doesn't provide leakage resistance if it
can achieve leakage resistance only with such an implementation. Leakage-resista
nt AEAD algorithms aim to place as mild requirements on implementation as possib
le to achieve leakage resistance. These requirements SHOULD be listed.
</t>
<t>
Confidentiality of plaintext in t
he presence of leakages in the encryption operation is unachievable if an advers
ary can repeat the nonce used to encrypt the plaintext in other encryption queri
es. Confidentiality can be achieved only for plaintexts encrypted with fresh non
ces (analogously to nonce-misuse resilience, see <xref target="NM" format="defau
lt" />). For further discussions, see <xref target="GPPS19" format="default" />
and <xref target="B20" format="default" />.
</t>
<t>
For primitive-based AEAD algorith
ms, key evolution (internal re-keying <xref target="RFC8645" format="default" />
) can contribute to achieving leakage resistance with leakages in encryption. Co
nfidentiality in the presence of decryption leakages can be achieved by two-pass
AEAD algorithms with key evolution, which compute independent ephemeral key val
ues for encryption and tag generation, where the computation of these keys is im
plemented without any leakages. For more discussions on achieving leakage resist
ance see <xref target="B20" format="default" />.
</t>
<t>
A well-known weaker property, Lea
kage Resilience, introduced in <xref target="BMOS17" format="default" />, can al
so be considered. However, this document makes a conscious choice to focus on th
e stronger Leakage Resistance, following the framework established in <xref targ
et="GPPS19" format="default" />, <xref target="B20" format="default" />, for its
enhanced practicality and comprehensiveness.
</t>
<t>
Applications: Encryption on smart
cards, Internet-of-things devices, or other constrained devices.
</t>
<t>
Further reading: <xref target="GP
PS19" format="default" />, <xref target="B20" format="default" />, <xref target=
"BPPS17" format="default" />, <xref target="BMOS17" format="default" />.
</t>
</section>
<section anchor="Mu-sec" numbered="true" toc="def
ault">
<name>Multi-User Security</name>
<t>
Definition: An AEAD algorithm sec
urity degrades slower than linearly with an increase in the number of users.
</t>
<t>
Security notion: mu-ind <xref ta
rget="BT16" format="default" />.
</t>
<t>
Examples: AES-GCM <xref target="D
07" format="default"/>, ChaCha20-Poly1305 <xref target="RFC8439" format="default
"/>, AES-GCM-SIV <xref target="RFC8452" format="default"/>, AEGIS <xref target="
I-D.irtf-cfrg-aegis-aead" format="default"/>.
</t>
<t>
Notes: It holds that for any AEAD
algorithm security degrades no worse than linearly with an increase in the numb
er of users <xref target="BT16" format="default" />. However, for some applicati
ons with a significant number of users, better multi-user guarantees are require
d. For example, in the TLS 1.3 protocol, to address this issue, AEAD algorithms
are used with a randomized nonce (deterministically derived from a traffic secre
t and a sequence number). Using nonce randomization in block cipher counter-base
d AEAD modes can contribute to multi-user security <xref target="BT16" format="d
efault" />. Multi-user usage limits for AES-GCM and ChaCha20-Poly1305 are provid
ed in <xref target="I-D.irtf-cfrg-aead-limits" format="default"/>.
</t>
<t>
A weaker security notion, multi-u
ser key recovery, is also introduced and thoroughly studied in <xref target="BT1
6" format="default" />. While this document focuses on indistinguishability for
security notions, key recovery might be relevant and valuable to study alongside
indistinguishability.
</t>
<t>
Applications: Data transmission l
ayer of secure communication protocols (e.g., TLS, IPSec, SRTP, etc.)
</t>
<t>
Further reading: <xref target="BT
16" format="default" />, <xref target="HTT18" format="default" />, <xref target=
"LMP17" format="default" />, <xref target="DGGP21" format="default" />, <xref ta
rget="BHT18" format="default" />.
</t>
</section>
<section anchor="NonceHiding" numbered="true" toc
="default">
<name>Nonce-Hiding</name>
<t>
Definition: An AEAD algorithm pro
vides confidentiality for the nonce value used to encrypt plaintext. The algorit
hm includes information about the nonce in the ciphertext and doesn't require th
e nonce as input for the decryption operation.
</t>
<t>
Security notion: AE2 <xref target
="BNT19" format="default" />.
</t>
<t>
Examples: Hide-Nonce (HN) transfo
rms <xref target="BNT19" format="default" />.
</t>
<t>
Notes: As discussed in <xref targ
et="BNT19" format="default" />, adversary-visible nonces might compromise messag
e and user privacy, similar to the way any metadata might do. As pointed out in
<xref target="B13" format="default" />, even using a counter as a nonce value mi
ght compromise privacy. Designing a privacy-preserving way to manage nonces migh
t be a challenging problem for an application.
</t>
<t>
Applications: Any application tha
t can't rely on a secure 'out-of-band' nonce communication.
</t>
<t>
Further reading: <xref target="BN
T19" format="default" />.
</t>
</section>
<section anchor="NM" numbered="true" toc="default
">
<name>Nonce Misuse</name>
<t>
Definition: An AEAD algorithm pro
vides security (resilience or resistance) even if an adversary can repeat nonces
in its encryption queries. Nonce misuse resilience and resistance are defined a
s follows:
</t>
<ul>
<li>
<t>
Nonce misuse resi
lience: Security is provided for messages encrypted with non-repeated (fresh) no
nces (correctly encrypted messages).
</t>
<t>
Security notion:
CPA resilience (confidentiality), authenticity resilience (integrity), CCA resil
ience (authenticated encryption) <xref target="ADL17" format="default" />.
</t>
<t>
Examples: ChaCha2
0-Poly1305 <xref target="RFC8439" format="default"/>, AES-GCM <xref target="D07"
format="default"/> (only confidentiality).
</t>
</li>
<li>
<t>Nonce misuse resistanc
e: Security is provided for all messages that were not encrypted with the same n
once value more than once.</t>
<t>
Security notion:
MRAE <xref target="RS06" format="default" />.
</t>
<t>
Examples: AES-GCM
-SIV <xref target="RFC8452" format="default"/>, Deoxys-II <xref target="JNPS21"
format="default"/>.
</t>
<t>
Notes: SIV constr
uction <xref target="RS06" format="default" /> is a generic construction that pr
ovides nonce misuse resistance.
</t>
</li>
</ul>
<t>
Notes: Nonce misuse resilience fo
llows from nonce misuse resistance. Nonce misuse resistance does not follow from
nonce misuse resilience.
</t>
<t>
Applications: Any application whe
re nonce uniqueness can't be guaranteed, security against fault-injection attack
s and malfunctions, processes parallelization, full disk encryption.
</t>
<t>
Further reading:
<xref target="RS06" format="defau
lt" />, <xref target="ADL17" format="default" />.
</t>
</section>
<section anchor="Quantum" numbered="true" toc="de </section>
fault">
<name>Quantum Security</name>
<t>
Definition: An AEAD algorithm pro
vides security (in a Q1 or Q2 model) against a quantum adversary. Q1 and Q2 mode
ls are defined as follows:
</t>
<ul>
<li>
<t>Q1 model: An adversar
y has access to local quantum computational power. It has classical access to en
cryption and decryption oracles.</t>
<t>Synonyms: Post-quantum <section anchor="SecurityProp" numbered="true" toc="default">
security.</t> <name>Security Properties</name>
<section anchor="BWsec" numbered="true" toc="default">
<name>Blockwise Security</name>
<dl newline="true" spacing="normal">
<dt>Definition:</dt><dd>An AEAD algorithm provides security even if an
adversary can adaptively choose the next part of the plaintext
depending on already-computed ciphertext parts during an encryption
operation.</dd>
<dt>Security notion:</dt><dd>D-LORS-BCPA for confidentiality against
passive adversaries, B-INT-CTXT for integrity <xref target="EV17"
format="default"/>; OAE1 <xref target="HRRV15" format="default"/> (a
stronger notion; originally OAE (Online Authenticated Encryption) in
<xref target="FFL12" format="default"/>)</dd>
<dt>Examples:</dt><dd>Deoxys <xref target="JNPS21" format="default"/>,
SAEF <xref target="ABV21" format="default"/></dd>
<t>Examples: AES-GCM <xre <dt>Notes:</dt><dd>Blockwise security is highly relevant for streamable
f target="D07" format="default"/>, ChaCha20-Poly1305 <xref target="RFC8439" form AEAD algorithms (see <xref target="Online" format="default"/>). The
at="default"/>, OCB <xref target="RFC7253" format="default"/>, MGM <xref target= OAE1 security notion <xref target="HRRV15" format="default"/> and the
"RFC9058" format="default"/>, AES-GCM-SIV <xref target="RFC8452" format="default OAE2 notion <xref target="HRRV15" format="default"/> are tailored for
"/>, AEGIS <xref target="I-D.irtf-cfrg-aegis-aead" format="default"/>.</t> streamable AEAD algorithms. OAE1 was first defined in <xref
</li> target="FFL12" format="default"/> under the name OAE; however, it
<li> contained a glitch, and the reformulated definition was presented in
<t>Q2 model: An adversary <xref target="HRRV15" format="default"/>. Blockwise security follows
has access to local quantum computational power. It has quantum access to encry from security in the OAE notion <xref target="EV17"
ption and decryption oracles, i.e., it can query encryption and decryption oracl format="default"/>. For a discussion on security notions for streamable
es with quantum superpositions of inputs to receive quantum superpositions of th AEAD algorithms, see <xref target="HRRV15" format="default"/>.</dd>
e outputs.</t> <dt>Applications:</dt><dd>Real-time streaming protocols, encryption on
resource-constrained devices</dd>
<dt>Further reading:</dt><dd><xref target="EV17" format="default"/>,
<xref target="JMV2002" format="default"/>, <xref target="FJMV2004"
format="default"/>, <xref target="HRRV15" format="default"/></dd>
</dl>
</section>
<t>Synonyms: Superpositio <section anchor="FullComm" numbered="true" toc="default">
n-based quantum security.</t> <name>Full Commitment</name>
<dl spacing="normal" newline="true">
<dt>Definition:</dt><dd>An AEAD algorithm guarantees that it is hard to
find two or more different tuples of the key, nonce, associated data,
and plaintext such that they encrypt to the same ciphertext. In other
words, an AEAD scheme guarantees that a ciphertext is a commitment to
all inputs of an authenticated encryption operation.</dd>
<dt>Security notion:</dt><dd>CMT-4 <xref target="BH22"
format="default"/>, generalized CMT for a restricted setting (see the
notes below) <xref target="MLGR23" format="default"/></dd>
<dt>Examples:</dt><dd>Ascon <xref target="DEMS21a"
format="default"/> <xref target="DEMS21b" format="default"/> <xref
target="YSS23" format="default"/>, full committing versions of Galois/Cou
nter Mode (GCM) and
GCM-SIV <xref target="BH22" format="default"/>, generic constructions
<xref target="BH22" format="default"/> and <xref target="CR22"
format="default" /></dd>
<dt>Notes:</dt><dd>Full commitment can be considered in a weaker
setting, where certain restrictions on the tuples produced by an
adversary are imposed <xref target="MLGR23" format="default" />. For
instance, an adversary must find tuples that all share the same
associated data value. In such cases, an AEAD algorithm is said to
provide full commitment in a restricted setting. The imposed
restrictions <bcp14>MUST</bcp14> be listed.</dd>
<dt>Applications:</dt><dd>Message franking <xref target="GLR17"
format="default" /></dd>
<dt>Further reading:</dt><dd><xref target="BH22" format="default" />,
<xref target="CR22" format="default" />, <xref target="MLGR23"
format="default" /></dd>
</dl>
<t>Examples: QCB <xref ta </section>
rget="BBCLNSS21" format="default" />.</t> <section anchor="KeyComm" numbered="true" toc="default">
</li> <name>Key Commitment</name>
</ul> <dl spacing="normal" newline="true">
<t> <dt>Definition:</dt><dd>An AEAD algorithm guarantees that it is hard to
Notes: Most symmetric cryptograph find two or more different keys and the same number of potentially
ic algorithms that are secure in the classical model provide quantum security in equal triples of nonce, associated data, and plaintext such that they
the Q1 model, i.e., they are post-quantum secure. Security in the Q1 setting co encrypt to the same ciphertext under corresponding keys. In other
rresponds to security against "harvest now, decrypt later" attacks. Security in words, an AEAD scheme guarantees that a ciphertext is a commitment to
Q1 follows from security in Q2, the converse does not hold. For discussions on t the key used for an authenticated encryption operation.</dd>
he relevance of the Q2 model please see <xref target="G17" format = "default"/>. <dt>Security notion:</dt><dd>CMT-1 <xref target="BH22" format="default"/>
</t> </dd>
<t> <dt>Synonyms:</dt><dd>Key robustness, key collision resistance</dd>
Further reading: <xref target="KL <dt>Examples:</dt><dd>Ascon <xref target="DEMS21a"
LNP16" format="default" />, <xref target="BBCLNSS21" format="default" />, <xref format="default"/> <xref target="DEMS21b" format="default"/> <xref
target="G17" format = "default"/>. target="YSS23" format="default"/>, generic constructions from <xref
</t> target="BH22" format="default"/> and <xref target="CR22"
</section> format="default"/></dd>
<dt>Notes:</dt><dd>Key commitment follows from full commitment. Full
commitment does not follow from key commitment <xref target="BH22"
format="default" />.</dd>
<dt>Applications:</dt><dd>Password-Authenticated Key Exchange,
password-based encryption <xref target="LGR21" format="default" />, key
rotation, envelope encryption <xref target="ADGKLS22" format="default"
/></dd>
<dt>Further reading:</dt><dd><xref target="BH22" format="default"
/>, <xref target="CR22" format="default" />, <xref target="FOR17"
format="default" />, <xref target="LGR21" format="default" />, <xref
target="GLR17" format="default" /></dd>
</dl>
<section anchor="Reforg" numbered="true" toc="def </section>
ault">
<name>Reforgeability Resilience</name>
<t>
Definition: An AEAD algorithm gua
rantees that once a successful forgery for the algorithm has been found, it is s
till hard to find any subsequent forgery.
</t>
<t>
Security notion: j-Int-CTXT <xref
target="FLLW17" format="default" />.
</t>
<t>
Examples: Deoxys <xref target="JN
PS21" format="default"/>, AEGIS <xref target="I-D.irtf-cfrg-aegis-aead" format="
default"/>, Ascon <xref target="DEMS21a" format="default"/><xref target="DEMS21b
" format="default"/>.
</t>
<t>
Applications: VoIP, real-time str
eaming in a lightweight setting, applications that require small ciphertext expa
nsion (i.e., short tags).
</t>
<t>
Further reading: <xref target="BC
09" format="default" />, <xref target="FLLW17" format="default" />.
</t>
</section>
<section anchor="RUP" numbered="true" toc="defaul
t">
<name>Release of Unverified Plaintext (RU
P) Integrity</name>
<t>
Definition: An AEAD algorithm pro
vides data integrity even if plaintext is released for every ciphertext, includi
ng those with failed integrity verification.
</t>
<t>
Security notion: INT-RUP <xref ta
rget="A14" format="default" />.
</t>
<t>
Examples: GCM-RUP <xref target="A
DL17" format="default" />.
</t>
<t>
Applications: Decryption with lim
ited memory <xref target="FJMV2004" format="default" />, real-time streaming pro
tocols.
</t>
<t>
Notes: In <xref target="ADL17" fo
rmat="default"/> a generic approach to achieve INT-RUP security is introduced.
</t>
<t>
In the provided definition, we on
ly consider integrity in the RUP setting, since confidentiality, in the usual se
nse, is unachievable under RUP. In <xref target="A14" format="default" />, the n
otion of 'Plaintext Awareness' is introduced, capturing the best possible confid
entiality under RUP in the following sense: 'The adversary cannot gain any addit
ional knowledge about the plaintext from decryption queries beyond what it can d
erive from encryption queries'.
</t>
<t>
Further reading: <xref target="A1
4" format="default" />, <xref target="ADL17" format="default" />.
</t>
</section>
</section>
<section anchor="ImpProp" numbered="true" toc="default">
<name>Implementation Properties</name>
<section anchor="HardEff" numbered="true" toc="de <section anchor="Leakage" numbered="true" toc="default">
fault"> <name>Leakage Resistance</name>
<name>Hardware efficient</name> <dl spacing="normal" newline="true">
<t> <dt>Definition:</dt><dd>An AEAD algorithm provides security even if
Definition: An AEAD algorithm ens some additional information about computations of an encryption (and
ures optimal performance when operating on hardware that complies with the speci possibly decryption) operation is obtained via side-channel
fied requirements. leakages.</dd>
</t> <dt>Security notion:</dt><dd>CIL1 <xref target="GPPS19"
<t> format="default" /> (CIML2 <xref target="BPPS17" format="default" />
Notes: Various classes of hardwar with leakages in decryption) for integrity, CCAL1 <xref target="GPPS19"
e may be taken into consideration. Certain algorithms are tailored to minimize t format="default" /> (CCAmL2 <xref target="GPPS19" format="default" />
he area of dedicated hardware implementations, while others are intended to capi with leakages in decryption) for authenticated encryption
talize on general-purpose CPUs, with or without specific instruction sets. It is security</dd>
RECOMMENDED to specify the minimum platform requirements for the AEAD to fulfil <dt>Examples:</dt><dd>Ascon <xref target="DEMS21a"
l its intended purpose, as well as to match its performance and security claims. format="default"/> <xref target="DEMS21b" format="default"/> (security
</t> under CIML2 and CCAL1 notions <xref target="B20" format="default" />),
</section> TEDT <xref target="GPPS19" format="default" /></dd>
<section anchor="Inverse" numbered="true" toc="de <dt>Notes:</dt><dd><t>Leakages during AEAD operation executions are
fault"> implementation-dependent. It is possible to implement symmetric
<name>Inverse-Free</name> algorithms in a way that every possible physical leakage is entirely
<t> independent of the secret inputs of the algorithm (for example, with a
Definition: An AEAD algorithm bas masking technique <xref target="CJRR99" format="default" />), meaning
ed on a given primitive can be implemented without invoking the inverse of that the adversary doesn't gain any additional information about the
primitive. algorithm's computation via side-channel leakages. We say that an AEAD
</t> algorithm doesn't provide leakage resistance if it can only achieve leaka
<t> ge
Examples: AES-GCM <xref target="D resistance with such an implementation. Leakage-resistant AEAD
07" format="default"/>, ChaCha20-Poly1305 <xref target="RFC8439" format="default algorithms aim to place requirements on implementations that are as mild
"/>, OCB <xref target="RFC7253" format="default"/>, MGM <xref target="RFC9058" f as
ormat="default"/>, AEGIS <xref target="I-D.irtf-cfrg-aegis-aead" format="default possible to achieve leakage resistance. These requirements
"/>. <bcp14>SHOULD</bcp14> be listed.</t>
</t> <t>Confidentiality of plaintext in the presence of leakages in the
<t> encryption operation is unachievable if an adversary can repeat the
Notes: In a sponge-based AEAD alg nonce used to encrypt the plaintext in other encryption
orithm, an underlying permutation is viewed as a primitive. queries. Confidentiality can be achieved only for plaintexts encrypted
</t> with fresh nonces (analogously to nonce-misuse resilience; see <xref
</section> target="NM" format="default" />). For further discussions, see <xref
<section anchor="Lightweight" numbered="true" toc target="GPPS19" format="default" /> and <xref target="B20"
="default"> format="default" />.</t>
<name>Lightweight</name> <t>For primitive-based AEAD algorithms, key evolution (internal
<t> re-keying <xref target="RFC8645" format="default" />) can contribute to
Definition: An AEAD algorithm can achieving leakage resistance with leakages in
be efficiently and securely implemented on resource-constrained devices. In par encryption. Confidentiality in the presence of decryption leakages can
ticular, it meets the criteria required in the NIST Lightweight Cryptography com be achieved by two-pass AEAD algorithms with key evolution, which
petition <xref target="MBTM17" format="default" />. compute independent ephemeral key values for encryption and tag
</t> generation, where the computation of these keys is implemented without
<t> any leakages. For more discussion on achieving leakage resistance, see
Examples: OCB <xref target="RFC72 <xref target="B20" format="default" />.</t>
53" format="default"/>, Ascon <xref target="DEMS21a" format="default"/><xref tar <t>Leakage Resilience, a well-known weaker property introduced in
get="DEMS21b" format="default"/>. <xref target="BMOS17" format="default" />, can also be
</t> considered. However, following the framework established in
<t> <xref target="GPPS19" format="default" /> and <xref target="B20"
Further reading: <xref target="MB format="default" />, this document makes a conscious choice to focus on
TM17" format="default" />. the stronger Leakage Resistance for its enhanced practicality and
</t> comprehensiveness.</t></dd>
</section> <dt>Applications:</dt><dd>Encryption on smart cards, Internet-of-Things
<section anchor="Parallelizable" numbered="true" devices, or other constrained devices</dd>
toc="default"> <dt>Further reading:</dt><dd><xref target="GPPS19" format="default" />,
<name>Parallelizable</name> <xref target="B20" format="default" />, <xref target="BPPS17"
<t> format="default" />, <xref target="BMOS17" format="default" /></dd>
Definition: An AEAD algorithm can </dl>
fully exploit the parallel computation infrastructure. In other words, a parall </section>
elizable AEAD algorithm allows for the computation of ciphertext segments (plain <section anchor="Mu-sec" numbered="true" toc="default">
text segments for decryption) in parallel, meaning that ciphertext segments are <name>Multi-user Security</name>
computed independently. <dl newline="true" spacing="normal">
</t>
<t> <!-- [rfced] May we remove "It holds that"?
Synonyms: Pipelineable.
</t> Original:
<t> It holds that for any AEAD algorithm security degrades no worse
Examples: AES-GCM <xref target="D than linearly with an increase in the number of users [BT16].
07" format="default"/>, ChaCha20-Poly1305 <xref target="RFC8439" format="default
"/>, OCB <xref target="RFC7253" format="default"/>, MGM <xref target="RFC9058" f Perhaps:
ormat="default"/>, AEGIS <xref target="I-D.irtf-cfrg-aegis-aead" format="default For any AEAD algorithm, security degrades no worse
"/>. than linearly with an increase in the number of users [BT16].
</t> -->
<t>
Further reading: <xref target="C2 <dt>Definition:</dt><dd>The security of an AEAD algorithm degrades slower
0" format="default" />. than
</t> linearly with an increase in the number of users.</dd>
</section> <dt>Security notion:</dt><dd>mu-ind <xref target="BT16" format="default"
<section anchor="SetupFree" numbered="true" toc=" /></dd>
default"> <dt>Examples:</dt><dd>AES-GCM <xref target="D07" format="default"/>,
<name>Setup-Free</name> ChaCha20-Poly1305 <xref target="RFC8439" format="default"/>,
<t> AES-GCM-SIV <xref target="RFC8452" format="default"/>, AEGIS <xref
Definition: An AEAD algorithm's o target="I-D.irtf-cfrg-aegis-aead" format="default"/></dd>
perations can be implemented in a way that using a new key incurs either no over <dt>Notes:</dt><dd><t>It holds that for any AEAD algorithm, security
head or negligible overhead compared to the reuse of a previous key. Overhead ma degrades no worse than linearly with an increase in the number of users
y involve additional computations or increased storage space, such as precomputi <xref target="BT16" format="default" />. However, for some applications
ng a key schedule for a block cipher. with a significant number of users, better multi-user guarantees are
</t> required. For example, in the TLS 1.3 protocol,
<t> AEAD algorithms are used with a randomized nonce (deterministically
Examples: ChaCha20-Poly1305 <xref derived from a traffic secret and a sequence number) to address this issu
target="RFC8439" format="default"/>, AEGIS <xref target="I-D.irtf-cfrg-aegis-ae e. Using nonce
ad" format="default"/>, Ascon <xref target="DEMS21a" format="default"/><xref tar randomization in block cipher counter-based AEAD modes can contribute
get="DEMS21b" format="default"/>. to multi-user security <xref target="BT16" format="default"
</t> />. Multi-user usage limits for AES-GCM and ChaCha20-Poly1305 are
</section> provided in <xref target="I-D.irtf-cfrg-aead-limits"
<section anchor="SinglePass" numbered="true" toc= format="default"/>.</t>
"default"> <t>A weaker security notion, multi-user key recovery, is also
<name>Single Pass</name> introduced and thoroughly studied in <xref target="BT16"
<t> format="default" />. While this document focuses on
Definition: An AEAD algorithm enc indistinguishability for security notions, key recovery might be
ryption (decryption) operation can be implemented with a single pass over the pl relevant and valuable to study alongside indistinguishability.</t></dd>
aintext (ciphertext). <dt>Applications:</dt><dd>Data transmission layer of secure
</t> communication protocols (e.g., TLS, IPsec, the Secure Real-time Transport
<t> Protocol (SRTP), etc.)</dd>
Examples: AES-GCM <xref target="D <dt>Further reading:</dt><dd><xref target="BT16" format="default" />,
07" format="default"/>, ChaCha20-Poly1305 <xref target="RFC8439" format="default <xref target="HTT18" format="default" />, <xref target="LMP17"
"/>, OCB <xref target="RFC7253" format="default"/>, MGM <xref target="RFC9058" f format="default" />, <xref target="DGGP21" format="default" />, <xref
ormat="default"/>, AEGIS <xref target="I-D.irtf-cfrg-aegis-aead" format="default target="BHT18" format="default" /></dd>
"/>. </dl>
</t> </section>
</section> <section anchor="NonceHiding" numbered="true" toc="default">
<section anchor="StaticAD" numbered="true" toc="d <name>Nonce Hiding</name>
efault"> <dl spacing="normal" newline="true">
<name>Static Associated Data Efficient</n <dt>Definition:</dt><dd>An AEAD algorithm provides confidentiality for
ame> the nonce value used to encrypt plaintext. The algorithm includes
<t> information about the nonce in the ciphertext and doesn't require the
Definition: An AEAD algorithm all nonce as input for the decryption operation.</dd>
ows pre-computation for static (or repeating) associated data so that static ass <dt>Security notion:</dt><dd>AE2 <xref target="BNT19" format="default" />
ociated data doesn't significantly contribute to the computational cost of encry </dd>
ption.
</t> <!-- [rfced] Should "Hide-Nonce (HN)" be updated to "Nonce-Hiding" per the
<t> title of Section 4.3.6? We are unable to access [BNT19] to check for
Examples: AES-GCM <xref target="D guidance there.
07" format="default"/>, ChaCha20-Poly1305 <xref target="RFC8439" format="default
"/>, OCB <xref target="RFC7253" format="default"/>. Original:
</t> 4.3.6. Nonce-Hiding
</section> ...
<section anchor="Online" numbered="true" toc="def Examples: Hide-Nonce (HN) transforms [BNT19].
ault">
<name>Streamable</name> Perhaps:
<t> 4.3.6. Nonce Hiding
Definition: An AEAD algorithm enc ...
ryption (decryption) operation can be implemented with constant memory usage and Examples: Nonce-hiding transforms [BNT19].
a single one-direction pass over the plaintext (ciphertext), writing out the re -->
sult during that pass.
</t> <dt>Examples:</dt><dd>Hide-Nonce (HN) transforms <xref target="BNT19" for
<t> mat="default" /></dd>
Synonyms: Online. <dt>Notes:</dt><dd>As discussed in <xref target="BNT19"
</t> format="default" />, adversary-visible nonces might compromise message
<t> and user privacy, similar to the way any metadata might. As pointed
Examples: AES-GCM <xref target="D out in <xref target="B13" format="default" />, even using a counter as
07" format="default"/>, ChaCha20-Poly1305 <xref target="RFC8439" format="default a nonce value might compromise privacy. Designing a privacy-preserving
"/>, OCB <xref target="RFC7253" format="default"/>, MGM <xref target="RFC9058" f way to manage nonces might be a challenging problem for an application.</
ormat="default"/>, AEGIS <xref target="I-D.irtf-cfrg-aegis-aead" format="default dd>
"/>, Ascon <xref target="DEMS21a" format="default"/><xref target="DEMS21b" forma <dt>Applications:</dt><dd>Any application that can't rely on a secure
t="default"/>. "out-of-band" nonce communication</dd>
</t> <dt>Further reading:</dt><dd><xref target="BNT19" format="default" /></dd
<t> >
Applications: Real-time streaming </dl>
protocols, resource-constrained devices. </section>
</t> <section anchor="NM" numbered="true" toc="default">
<t> <name>Nonce Misuse</name>
Notes: Blockwise security (see <x <dl spacing="normal" newline="true">
ref target="BWsec" format="default" />) and RUP integrity (see <xref target="RUP <dt>Definition:</dt><dd><t>An AEAD algorithm provides security
" format="default" />) might be relevant security properties for streamable AEAD (resilience or resistance) even if an adversary can repeat nonces in
algorithms in certain applications. its encryption queries. Nonce misuse resilience and resistance are
</t> defined as follows:</t>
<t> <dl newline="false" spacing="normal">
Further reading: <xref target="HR <dt>Nonce misuse resilience:</dt><dd><t>Security is provided for message
RV15" format="default" />, <xref target="FJMV2004" format="default" />. s
</t> encrypted with non-repeated (fresh) nonces (correctly encrypted
</section> messages).</t>
</section> <dl newline="true" spacing="normal">
</section> <dt>Security notion:</dt><dd>CPA resilience (confidentiality),
<section anchor="Security" numbered="true" toc="default"> authenticity resilience (integrity), CCA resilience (authenticated
<name>Security Considerations</name> encryption) <xref target="ADL17" format="default" /></dd>
<dt>Examples:</dt><dd>ChaCha20-Poly1305 <xref target="RFC8439"
format="default"/>, AES-GCM <xref target="D07" format="default"/>
(only confidentiality)</dd></dl></dd>
<dt>Nonce misuse resistance:</dt><dd><t>Security is provided for
all
messages that were not encrypted with the same nonce value more
than
once.</t>
<dl newline="true" spacing="normal">
<dt>Security notion:</dt><dd>MRAE <xref target="RS06" format="default" /
></dd>
<dt>Examples:</dt><dd>AES-GCM-SIV <xref target="RFC8452"
format="default"/>, Deoxys-II <xref target="JNPS21"
format="default"/></dd>
<dt>Notes:</dt><dd>Synthetic Initialization Vector (SIV) construction <x
ref target="RS06"
format="default" /> is a generic construction that provides nonce
misuse resistance.</dd></dl></dd>
</dl>
</dd>
<dt>Notes:</dt><dd>Nonce misuse resilience follows from nonce misuse
resistance. Nonce misuse resistance does not follow from nonce misuse
resilience.</dd>
<dt>Applications:</dt><dd>Any application where nonce uniqueness can't be
guaranteed, security against fault-injection attacks and malfunctions,
processes parallelization, full disk encryption</dd>
<dt>Further reading:</dt><dd><xref target="RS06" format="default" />,
<xref target="ADL17" format="default" /></dd>
</dl>
</section>
<section anchor="Quantum" numbered="true" toc="default">
<name>Quantum Security</name>
<dl spacing="normal" newline="true">
<dt>Definition:</dt><dd><t>An AEAD algorithm provides security (in a Q1
or Q2 model) against a quantum adversary. Q1 and Q2 models are defined
as follows:</t>
<dl spacing="normal" newline="false">
<dt>Q1 model:</dt><dd><t>An adversary has access to local quantum
computational power. It has classical access to encryption and
decryption oracles.</t>
<dl spacing="normal" newline="true">
<dt>Synonyms:</dt><dd>Post-quantum security</dd>
<dt>Examples:</dt><dd> AES-GCM <xref target="D07" format="default"/>,
ChaCha20-Poly1305 <xref target="RFC8439" format="default"/>, OCB
<xref target="RFC7253" format="default"/>, Multilinear Galois Mode (MGM)
<xref target="RFC9058"
format="default"/>, AES-GCM-SIV <xref target="RFC8452"
format="default"/>, AEGIS <xref target="I-D.irtf-cfrg-aegis-aead"
format="default"/></dd>
</dl></dd>
<dt>Q2 model:</dt><dd><t>An adversary has access to local quantu
m
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">
<dt>Synonyms:</dt><dd> Superposition-based quantum security</dd>
<dt>Examples:</dt><dd> QCB <xref target="BBCLNSS21" format="default" /><
/dd>
</dl></dd>
</dl>
</dd>
<dt>Notes:</dt><dd>Most symmetric cryptographic algorithms that are secure
in
the classical model provide quantum security in the Q1 model, i.e., they
are post-quantum secure. Security in the Q1 setting corresponds to
security against "harvest now, decrypt later" attacks. Security in Q1
follows from security in Q2; the converse does not hold. For discussions
on the relevance of the Q2 model, please see <xref target="G17" format =
"default"/>.</dd>
<dt>Further reading:</dt><dd> <xref target="KLLNP16" format="default" />,
<xref target="BBCLNSS21" format="default" />, <xref target="G17" format =
"default"/></dd>
</dl>
</section>
<section anchor="Reforg" numbered="true" toc="default">
<name>Reforgeability Resilience</name>
<dl newline="true" spacing="normal">
<dt>Definition:</dt><dd>An AEAD algorithm guarantees that once a
successful forgery for the algorithm has been found, it is still hard
to find any subsequent forgery.</dd>
<dt>Security notion:</dt><dd>j-Int-CTXT <xref target="FLLW17" format="def
ault" /></dd>
<dt>Examples:</dt><dd>Deoxys <xref target="JNPS21" format="default"/>,
AEGIS <xref target="I-D.irtf-cfrg-aegis-aead" format="default"/>, Ascon
<xref target="DEMS21a" format="default"/> <xref target="DEMS21b"
format="default"/></dd>
<dt>Applications:</dt><dd>Voice over IP (VoIP), real-time streaming in a
lightweight
setting, applications that require small ciphertext expansion (i.e.,
short tags)</dd>
<dt>Further reading:</dt><dd><xref target="BC09" format="default" />, <xr
ef target="FLLW17" format="default" /></dd>
</dl>
</section>
<section anchor="RUP" numbered="true" toc="default">
<name>Release of Unverified Plaintext (RUP) Integrity</name>
<dl spacing="normal" newline="true">
<!-- [rfced] FYI - We made minor changes to the quoted text (lowercased "the"
and changed "beyond" to "besides") to exactly match the text at [A14].
Original:
In [A14], the notion of 'Plaintext
Awareness' is introduced, capturing the best possible
confidentiality under RUP in the following sense: 'The adversary
cannot gain any additional knowledge about the plaintext from
decryption queries beyond what it can derive from encryption
queries'.
-->
<dt>Definition:</dt><dd>An AEAD algorithm provides data integrity even
if plaintext is released for every ciphertext, including those with
failed integrity verification.</dd>
<dt>Security notion:</dt><dd>INT-RUP <xref target="A14" format="default"
/></dd>
<dt>Examples:</dt><dd>GCM-RUP <xref target="ADL17" format="default" /></d
d>
<dt>Applications:</dt><dd>Decryption with limited memory <xref
target="FJMV2004" format="default" />, real-time streaming protocols</dd>
<dt>Notes:</dt><dd><t>In <xref target="ADL17" format="default"/>, a gener
ic
approach to achieve INT-RUP security is introduced.</t>
<t>In the provided definition, we only consider integrity in the RUP
setting, since confidentiality, in the usual sense, is unachievable
under RUP. In <xref target="A14" format="default" />, the notion of
"Plaintext Awareness" 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>Further reading:</dt><dd><xref target="A14" format="default" />,
<xref target="ADL17" format="default" /></dd>
</dl>
</section>
</section>
<section anchor="ImpProp" numbered="true" toc="default">
<name>Implementation Properties</name>
<section anchor="HardEff" numbered="true" toc="default">
<name>Hardware Efficient</name>
<dl newline="true" spacing="normal">
<dt>Definition:</dt><dd>An AEAD algorithm ensures optimal performance
when operating on hardware that complies with the specified
requirements.</dd>
<dt>Notes:</dt><dd>Various classes of hardware may be taken into
consideration. Certain algorithms are tailored to minimize the area of
dedicated hardware implementations, while others are intended to
capitalize on general-purpose CPUs, with or without specific
instruction sets. It is <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="default">
<name>Inverse-Free</name>
<dl newline="true" spacing="normal">
<dt>Definition:</dt><dd>An AEAD algorithm based on a given primitive
can be implemented without invoking the inverse of that primitive.</dd>
<dt>Examples:</dt><dd>AES-GCM <xref target="D07" format="default"/>,
ChaCha20-Poly1305 <xref target="RFC8439" format="default"/>, OCB <xref
target="RFC7253" format="default"/>, MGM <xref target="RFC9058"
format="default"/>, AEGIS <xref target="I-D.irtf-cfrg-aegis-aead"
format="default"/></dd>
<dt>Notes:</dt><dd>In a sponge-based AEAD algorithm, an underlying
permutation is viewed as a primitive.</dd>
</dl>
</section>
<section anchor="Lightweight" numbered="true" toc="default">
<name>Lightweight</name>
<dl newline="true" spacing="normal">
<dt>Definition:</dt><dd>An AEAD algorithm can be efficiently and
securely implemented on resource-constrained devices. In particular, it
meets the criteria required in the NIST Lightweight Cryptography
competition <xref target="MBTM17" format="default" />.</dd>
<dt>Examples:</dt><dd>OCB <xref target="RFC7253" format="default"/>,
Ascon <xref target="DEMS21a" format="default"/> <xref target="DEMS21b"
format="default"/></dd>
<dt>Further reading:</dt><dd><xref target="MBTM17" format="default" /></d
d>
</dl>
</section>
<section anchor="Parallelizable" numbered="true" toc="default">
<name>Parallelizable</name>
<dl newline="true" spacing="normal">
<dt>Definition:</dt><dd>An AEAD algorithm can fully exploit the parallel
computation infrastructure. In other words, a parallelizable AEAD
algorithm allows for the computation of ciphertext segments (plaintext
segments for decryption) in parallel, meaning that ciphertext segments
are computed independently.</dd>
<dt>Synonyms:</dt><dd>Pipelineable</dd>
<dt>Examples:</dt><dd>AES-GCM <xref target="D07" format="default"/>,
ChaCha20-Poly1305 <xref target="RFC8439" format="default"/>, OCB <xref
target="RFC7253" format="default"/>, MGM <xref target="RFC9058"
format="default"/>, AEGIS <xref target="I-D.irtf-cfrg-aegis-aead"
format="default"/></dd>
<dt>Further reading:</dt><dd><xref target="C20" format="default" /></dd>
</dl>
</section>
<section anchor="SetupFree" numbered="true" toc="default">
<name>Setup-Free</name>
<dl newline="true" spacing="normal">
<dt>Definition:</dt><dd>An AEAD algorithm's operations can be
implemented in a way that using a new key incurs either no overhead or
negligible overhead compared to the reuse of a previous key. Overhead
may involve additional computations or increased storage space, such as
precomputing a key schedule for a block cipher.</dd>
<dt>Examples:</dt><dd>ChaCha20-Poly1305 <xref target="RFC8439"
format="default"/>, AEGIS <xref target="I-D.irtf-cfrg-aegis-aead"
format="default"/>, Ascon <xref target="DEMS21a"
format="default"/> <xref target="DEMS21b" format="default"/></dd>
</dl>
</section>
<section anchor="SinglePass" numbered="true" toc="default">
<name>Single Pass</name>
<dl newline="true" spacing="normal">
<dt>Definition:</dt><dd>An AEAD algorithm encryption (decryption)
operation can be implemented with a single pass over the plaintext
(ciphertext).</dd>
<dt>Examples:</dt><dd>AES-GCM <xref target="D07" format="default"/>,
ChaCha20-Poly1305 <xref target="RFC8439" format="default"/>, OCB <xref
target="RFC7253" format="default"/>, MGM <xref target="RFC9058"
format="default"/>, AEGIS <xref target="I-D.irtf-cfrg-aegis-aead"
format="default"/></dd>
</dl>
</section>
<section anchor="StaticAD" numbered="true" toc="default">
<name>Static Associated Data Efficient</name>
<dl newline="true" spacing="normal">
<dt>Definition:</dt><dd>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>Examples:</dt><dd>AES-GCM <xref target="D07" format="default"/>,
ChaCha20-Poly1305 <xref target="RFC8439" format="default"/>, OCB <xref
target="RFC7253" format="default"/></dd>
</dl>
</section>
<section anchor="Online" numbered="true" toc="default">
<name>Streamable</name>
<dl newline="true" spacing="normal">
<dt>Definition:</dt><dd>An AEAD algorithm encryption (decryption)
operation can be implemented with constant memory usage and a single
one-direction pass over the plaintext (ciphertext), writing out the
result during that pass.</dd>
<dt>Synonyms:</dt><dd>Online</dd>
<dt>Examples:</dt><dd>AES-GCM <xref target="D07" format="default"/>,
ChaCha20-Poly1305 <xref target="RFC8439" format="default"/>, OCB <xref
target="RFC7253" format="default"/>, MGM <xref target="RFC9058"
format="default"/>, AEGIS <xref target="I-D.irtf-cfrg-aegis-aead"
format="default"/>, Ascon <xref target="DEMS21a"
format="default"/> <xref target="DEMS21b" format="default"/></dd>
<dt>Applications:</dt><dd>Real-time streaming protocols, resource-constra
ined devices</dd>
<dt>Notes:</dt><dd>Blockwise security (see <xref target="BWsec"
format="default" />) and RUP integrity (see <xref target="RUP"
format="default" />) might be relevant security properties for
streamable AEAD algorithms in certain applications.</dd>
<dt>Further reading:</dt><dd><xref target="HRRV15" format="default" />,
<xref target="FJMV2004" format="default" /></dd>
</dl>
</section>
</section>
</section>
<section anchor="Security" numbered="true" toc="default">
<name>Security Considerations</name>
<t> <t>
This document gives high-level definitions of AEA D properties. For each security property, we provide an informational reference to a game-based security notion (or security notions if there are separate notio ns for integrity and confidentiality) that formalizes the property. We only cons ider game-based notions and security properties that can be formalized using thi s approach. However, there are different approaches to formalizing AEAD security , like the indifferentiability framework <xref target="BM18" format="default" /> ; security in such notions should be studied separately. This document gives high-level definitions of AEA D properties. For each security property, we provide an informational reference to a game-based security notion (or security notions if there are separate notio ns for integrity and confidentiality) that formalizes the property. We only cons ider game-based notions and security properties that can be formalized using thi s approach. However, there are different approaches to formalizing AEAD security , like the indifferentiability framework <xref target="BM18" format="default" /> ; security in such notions should be studied separately.
</t> </t>
<t> <t>
For some properties, examples of AEAD algorithms that provide them are given, with standardized AEAD algorithms preferred for com monly encountered properties. However, for certain properties, only non-standard ized algorithms exist. Implementing such algorithms requires careful considerati on, and it is advised to contact the algorithm designers for reference implement ations and implementation guidelines. For some properties, examples of AEAD algorithms that provide them are given, with standardized AEAD algorithms preferred for com monly encountered properties. However, for certain properties, only non-standard ized algorithms exist. Implementing such algorithms requires careful considerati on, and it is advised to contact the algorithm designers for reference implement ations and implementation guidelines.
</t> </t>
<t> <t>
Every claimed security property of an AEAD algori Every claimed security property of an AEAD algorithm
thm MUST undergo security analysis within a relevant notion. It's RECOMMENDED to <bcp14>MUST</bcp14> undergo security analysis within
use the security notions referenced in the document. If an alternative notion i a relevant notion. It's <bcp14>RECOMMENDED</bcp14>
s used, there MUST exist proof of equivalence or it SHOULD be indicated that a n to use the security notions referenced in the
on-equivalent notion is used. For security properties that extend adversarial ca document. If an alternative notion is used, proof of
pabilities, consideration of integrity and confidentiality separately may be rel equivalence <bcp14>MUST</bcp14> exist, or use of a
evant. If the algorithm provides only one of these, that SHOULD be indicated. 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>
<!-- [rfced] How may we clarify "as should all trade-offs be"?
Original:
In an
application, the requirements for additional AEAD properties SHOULD
be highly motivated and justified, as should all trade-offs be
carefully considered.
Perhaps:
In an
application, the requirements for additional AEAD properties SHOULD
be highly motivated and justified, and all trade-offs should be
carefully considered.
Or:
In an
application, the requirements for additional AEAD properties SHOULD
be highly motivated and justified, as all trade-offs should be
carefully considered.
-->
<t> <t>
When specifying security requirements for an AEAD algorithm in an application, it SHOULD be indicated, for every required securit y property, whether only integrity or confidentiality is necessary. Additionally , for each security property, it SHOULD be specified whether an analysis in an a lternative security notion is required. We also note that some additional proper ties come with trade-offs in terms of classical security and efficiency, and may only be supported in non-standardized or modified AEAD algorithms. This immedia tely implies challenges in deployment and interoperability. In an application, t he requirements for additional AEAD properties SHOULD be highly motivated and ju stified, as should all trade-offs be carefully considered. When specifying security requirements for an AEAD algorithm in an application, it <bcp14>SHOULD</bcp14> be indicated, for every r equired security property, whether only integrity or confidentiality is necessar y. Additionally, for each security property, it <bcp14>SHOULD</bcp14> be specifi ed whether an analysis in an alternative security notion is required. We also no te that some additional properties come with trade-offs in terms of classical se curity and efficiency, and they may only be supported in non-standardized or mod ified AEAD algorithms. This immediately implies challenges in deployment and int eroperability. In an application, the requirements for additional AEAD propertie s <bcp14>SHOULD</bcp14> be highly motivated and justified, as should all trade-o ffs be carefully considered.
</t> </t>
</section> </section>
<section anchor="IANACON" numbered="true" toc="default"> <section anchor="IANACON" numbered="true" toc="default">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>This document has no IANA actions.</t> <t>This document has no IANA actions.</t>
</section> </section>
</middle> </middle>
<back> <back>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public
/rfc/bibxml/reference.RFC.2119.xml" />
<xi:include href="https://xml2rfc.ietf.org/public
/rfc/bibxml/reference.RFC.8174.xml" />
<xi:include href="https://xml2rfc.ietf.org/public
/rfc/bibxml/reference.RFC.5116.xml" />
<reference anchor="D07" target="https://csrc.nist
.gov/pubs/sp/800/38/d/final">
<front>
<title>Recommendation for Block C
ipher Modes of Operation: Galois/Counter
Mode (GCM) and GMAC</titl
e>
<author initials="M." surname="Dw
orkin" fullname="Morris Dworkin" />
<date year="2007" />
</front>
<seriesInfo name="DOI" value="10.6028/NIS
T.SP.800-38D" />
<refcontent>NIST Special Publication 800-
38D</refcontent>
</reference>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc <displayreference target="I-D.irtf-cfrg-aead-limits" to="AEAD-LIMITS"/>
/bibxml/reference.RFC.8446.xml" /> <displayreference target="I-D.irtf-cfrg-aegis-aead" to="AEGIS-AEAD"/>
<xi:include href="https://bib.ietf.org/public/rfc <references>
/bibxml/reference.RFC.4303.xml" /> <name>References</name>
<xi:include href="https://bib.ietf.org/public/rfc <references>
/bibxml/reference.RFC.8221.xml" /> <name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.
/bibxml/reference.RFC.9000.xml" /> RFC.2119.xml" />
<!-- <xi:include href="https://bib.ietf.org/public/rfc <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.
/bibxml/reference.RFC.5652.xml" />--> RFC.8174.xml" />
<xi:include href="https://bib.ietf.org/public/rfc <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.
/bibxml/reference.RFC.8439.xml" /> RFC.5116.xml" />
<xi:include href="https://bib.ietf.org/public/rfc <reference anchor="D07" target="https://csrc.nist.gov/pubs/sp/800/3
/bibxml/reference.RFC.8645.xml" /> 8/d/final">
<xi:include href="https://bib.ietf.org/public/rfc <front>
/bibxml/reference.RFC.8452.xml" /> <title>Recommendation for Block Cipher Modes of Operation: Galo
<xi:include href="https://bib.ietf.org/public/rfc is/Counter
/bibxml/reference.RFC.7253.xml" /> Mode (GCM) and GMAC</title>
<xi:include href="https://bib.ietf.org/public/rfc <author initials="M." surname="Dworkin" fullname="Morris Dworki
/bibxml/reference.RFC.9058.xml" /> n" />
<date year="2007" />
</front>
<seriesInfo name="NIST SP" value="800-38D"/>
<seriesInfo name="DOI" value="10.6028/NIST.SP.800-38D" />
</reference>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://datatracker.ietf.org/do <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.
c/bibxml3/draft-irtf-cfrg-aead-limits.xml" /> RFC.8446.xml" />
<xi:include href="https://datatracker.ietf.org/do <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.
c/bibxml3/draft-irtf-cfrg-aegis-aead.xml" /> RFC.4303.xml" />
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.
RFC.8221.xml" />
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.
RFC.9000.xml" />
<reference anchor="R02"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.
<front> RFC.8439.xml" />
<title>Authenticated-encryption w <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.
ith associated-data</title> RFC.8645.xml" />
<author initials="P." surname="Ro <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.
gaway" fullname="Phillip Rogaway" /> RFC.8452.xml" />
<date year="2002" /> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.
</front> RFC.7253.xml" />
<seriesInfo name="DOI" value="10.1145/586 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.
110.586125" /> RFC.9058.xml" />
<refcontent>Proceedings of the 9th ACM co
nference on Computer and communications security (CCS '02)</refcontent> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference
<refcontent>Association for Computing Mac .I-D.irtf-cfrg-aead-limits.xml" />
hinery, New York, NY, USA, 98–107</refcontent>
</reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference
<reference anchor="BN2000"> .I-D.irtf-cfrg-aegis-aead.xml" />
<front>
<title>Authenticated Encryption: <reference anchor="R02">
Relations among Notions and Analysis of the Generic Composition Paradigm</title> <front>
<author initials="M." surname="Be <title>Authenticated-encryption with associated-data</title>
llare" fullname="Mihir Bellare" /> <author initials="P." surname="Rogaway" fullname="Phillip Rogaw
<author initials="C." surname="Na ay" />
mprempre" fullname="Chanathip Namprempre" /> <date year="2002" />
<date year="2000" /> </front>
</front> <seriesInfo name="DOI" value="10.1145/586110.586125" />
<seriesInfo name="DOI" value="10.1007/s00 <refcontent>Proceedings of the 9th ACM Conference on Computer and
145-008-9026-x" /> Communications Security (CCS '02), pp. 98-107</refcontent>
<refcontent>Proceedings of ASIACRYPT 2000 </reference>
, Springer-Verlag, LNCS 1976, pp. 531-545</refcontent> <!-- [rfced] The URL in this reference entry points to a 2008 publication of
</reference> the paper, but the information in the reference entry is for a 2000
<reference anchor="JMV2002"> publication. Which would you like to cite?
<front>
<title>Blockwise-Adaptive Attacke 2008 - https://doi.org/10.1007/s00145-008-9026-x
rs Revisiting the (In)Security of Some Provably Secure Encryption Modes: CBC, GE 2000 - https://doi.org/10.1007/3-540-44448-3_41
M, IACBC</title>
<author initials="A." surname="Jo Original:
ux" fullname="Antoine Joux" /> [BN2000] Bellare, M. and C. Namprempre, "Authenticated Encryption:
<author initials="G." surname="Ma Relations among Notions and Analysis of the Generic
rtinet" fullname="Gwenaelle Martinet" /> Composition Paradigm", Proceedings of ASIACRYPT 2000,
<author initials="F." surname="Va Springer-Verlag, LNCS 1976, pp. 531-545,
lette" fullname="Frederic Valette" /> DOI 10.1007/s00145-008-9026-x, 2000,
<date year="2002" /> <https://doi.org/10.1007/s00145-008-9026-x>.
</front>
<seriesInfo name="DOI" value="10.1007/3-5 Perhaps (1) - 2000 paper:
40-45708-9_2" /> [BN2000] Bellare, M. and C. Namprempre, "Authenticated Encryption:
<refcontent>Advances in Cryptology — CRYP Relations among Notions and Analysis of the Generic
TO 2002. CRYPTO 2002. Lecture Notes in Computer Science, vol 2442. Springer, Ber Composition Paradigm", Advances in Cryptology - ASIACRYPT
lin, Heidelberg</refcontent> 2000, Lecture Notes in Computer Science, vol. 1976, pp.
</reference> 531-545, DOI 10.1007/3-540-44448-3_41, 2000,
<reference anchor="FJMV2004"> <https://doi.org/10.1007/3-540-44448-3_41>.
<front>
<title>Authenticated On-Line Encr Perhaps (2) - 2008 paper:
yption</title> [BN2000] Bellare, M. and C. Namprempre, "Authenticated Encryption:
<author initials="PA." surname="F Relations among Notions and Analysis of the Generic
ouque" fullname="Pierre-Alain Fouque" /> Composition Paradigm", Journal of Cryptology, vol. 21,
<author initials="A." surname="Jo pp. 469–491,
ux" fullname="Antoine Joux" /> DOI 10.1007/s00145-008-9026-x, July 2008,
<author initials="G." surname="Ma <https://doi.org/10.1007/s00145-008-9026-x>.
rtinet" fullname="Gwenaelle Martinet" />
<author initials="F." surname="Va
lette" fullname="Frederic Valette" />
<date year="2004" />
</front>
<seriesInfo name="DOI" value="10.1007/978
-3-540-24654-1_11" />
<refcontent>Selected Areas in Cryptograph
y. SAC 2003. Lecture Notes in Computer Science, vol 3006. Springer, Berlin, Heid
elberg.</refcontent>
</reference>
<!-- <reference anchor="BK2011">
<front>
<title>Authenticated and Misuse-R
esistant Encryption of Key-Dependent Data</title>
<author initials="M." surname="Be
llare" fullname="Mihir Bellare" />
<author initials="S." surname="Ke
elveedhi" fullname="Sriram Keelveedhi" />
<date year="2011" />
</front>
<seriesInfo name="DOI" value="10.1007/978
-3-642-22792-9_35" />
<refcontent>Advances in Cryptology - CRYP
TO 2011. CRYPTO 2011. Lecture Notes in Computer Science, vol 6841. Springer, Ber
lin, Heidelberg.</refcontent>
</reference>
<reference anchor="FOR17">
<front>
<title>Security of Symmetric Prim
itives under Incorrect Usage of Keys</title>
<author initials="P." surname="Fa
rshim" fullname="Pooya Farshim" />
<author initials="C." surname="Or
landi" fullname="Claudio Orlandi" />
<author initials="R." surname="Ro
sie" fullname="Razvan Rosie" />
<date year="2017" />
</front>
<seriesInfo name="DOI" value="10.13154/to
sc.v2017.i1.449-473" />
<refcontent>IACR Transactions on Symmetri
c Cryptology, 2017(1), 449–473.</refcontent>
</reference>
<reference anchor="LGR21">
<front>
<title>Partitioning Oracle Attack
s</title>
<author initials="J." surname="Le
n" fullname="Julia Len" />
<author initials="P." surname="Gr
ubbs" fullname="Paul Grubbs" />
<author initials="T." surname="Ri
stenpart" fullname="Thomas Ristenpart" />
<date year="2021" />
</front>
<refcontent>30th USENIX Security Symposiu
m (USENIX Security 21), 195--212</refcontent>
</reference>
<reference anchor="GLR17">
<front>
<title>Message Franking via Commi
tting Authenticated Encryption</title>
<author initials="P." surname="Gr
ubbs" fullname="Paul Grubbs" />
<author initials="J." surname="Lu
" fullname="Jiahui Lu" />
<author initials="T." surname="Ri
stenpart" fullname="Thomas Ristenpart" />
<date year="2017" />
</front>
<seriesInfo name="DOI" value="10.1007/978
-3-319-63697-9_3" />
<refcontent>Advances in Cryptology – CRYP
TO 2017. CRYPTO 2017. Lecture Notes in Computer Science, vol 10403. Springer, Ch
am</refcontent>
</reference>
<reference anchor="B20">
<front>
<title>Mode-Level vs. Implementat
ion-Level Physical Security in Symmetric Cryptography: A Practical Guide Through
the Leakage-Resistance Jungle</title>
<author initials="D." surname="Be
llizia" fullname="Davide Bellizia" />
<author initials="O." surname="Br
onchain" fullname="Olivier Bronchain" />
<author initials="G." surname="Ca
ssiers" fullname="Gaëtan Cassiers" />
<author initials="V." surname="Gr
osso" fullname="Vincent Grosso" />
<author initials="C." surname="Gu
o" fullname="Chun Guo" />
<author initials="C." surname="Mo
min" fullname="Charles Momin" />
<author initials="O." surname="Pe
reira" fullname="Olivier Pereira" />
<author initials="T." surname="Pe
ters" fullname="Thomas Peters" />
<author initials="FX." surname="S
tandaert" 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 – CRYP
TO 2020. CRYPTO 2020. Lecture Notes in Computer Science, vol 12170. Springer, Ch
am</refcontent>
</reference>
<reference anchor="GPPS19">
<front>
<title>Authenticated Encryption w
ith Nonce Misuse and Physical Leakages: Definitions, Separation Results and Leve
led Constructions</title>
<author initials="C." surname="Gu
o" fullname="Chun Guo" />
<author initials="O." surname="Pe
reira" fullname="Olivier Pereira" />
<author initials="T." surname="Pe
ters" fullname="Thomas Peters" />
<author initials="FX." surname="S
tandaert" 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 - LATI
NCRYPT 2019. LATINCRYPT 2019. Lecture Notes in Computer Science, vol 11774. Spri
nger, Cham</refcontent>
</reference>
<reference anchor="BT16">
<front>
<title>The Multi-User Security of
Authenticated Encryption: AES-GCM in TLS 1.3</title>
<author initials="M." surname="Be
llare" fullname="Mihir Bellare" />
<author initials="B." surname="Ta
ckmann" fullname="Björn Tackmann" />
<date year="2016" />
</front>
<seriesInfo name="DOI" value="10.1007/978
-3-662-53018-4_10" />
<refcontent>Advances in Cryptology – CRYP
TO 2016. CRYPTO 2016. Lecture Notes in Computer Science, vol 9814. Springer, Ber
lin, Heidelberg</refcontent>
</reference>
<reference anchor="RS06">
<front>
<title>A Provable-Security Treatm
ent of the Key-Wrap Problem</title>
<author initials="R." surname="Ro
gaway" fullname="Phillip Rogaway" />
<author initials="T." surname="Sh
rimpton" fullname="Thomas Shrimpton" />
<date year="2016" />
</front>
<seriesInfo name="DOI" value="10.1007/117
61679_23" />
<refcontent>Advances in Cryptology - EURO
CRYPT 2006. EUROCRYPT 2006. Lecture Notes in Computer Science, vol 4004. Springe
r, Berlin, Heidelberg</refcontent>
</reference>
<reference anchor="ADL17">
<front>
<title>Boosting Authenticated Enc
ryption Robustness with Minimal Modifications</title>
<author initials="T." surname="As
hur" fullname="Tomer Ashur" />
<author initials="O." surname="Du
nkelman" fullname="Orr Dunkelman" />
<author initials="A." surname="Lu
ykx" fullname="Atul Luykx" />
<date year="2017" />
</front>
<seriesInfo name="DOI" value="10.1007/978
-3-319-63697-9_1" />
<refcontent>Advances in Cryptology – CRYP
TO 2017. CRYPTO 2017. Lecture Notes in Computer Science, vol 10403. Springer, Ch
am</refcontent>
</reference>
<reference anchor="FLLW17">
<front>
<title>Reforgeability of Authenti
cated Encryption Schemes</title>
<author initials="C." surname="Fo
rler" fullname="Christian Forler" />
<author initials="E." surname="Li
st" fullname="Eik List" />
<author initials="S." surname="Lu
cks" fullname="Stefan Lucks" />
<author initials="J." surname="We
nzel" fullname="Jakob Wenzel" />
<date year="2017" />
</front>
<seriesInfo name="DOI" value="10.1007/978
-3-319-59870-3_2" />
<refcontent>Information Security and Priv
acy. ACISP 2017. Lecture Notes in Computer Science, vol 10343. Springer, Cham</r
efcontent>
</reference>
<reference anchor="BC09">
<front>
<title>MAC Reforgeability</title>
<author initials="J." surname="Bl
ack" fullname="John Black" />
<author initials="M." surname="Co
chran" 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. Springer, Berlin, Heidelberg
</refcontent>
</reference>
<reference anchor="A14">
<front>
<title>How to Securely Release Un
verified Plaintext in Authenticated Encryption</title>
<author initials="E." surname="An
dreeva" fullname="Elena Andreeva" />
<author initials="A." surname="Bo
gdanov" fullname="Andrey Bogdanov" />
<author initials="A." surname="Lu
ykx" fullname="Atul Luykx" />
<author initials="B." surname="Me
nnink" fullname="Bart Mennink" />
<author initials="N." surname="Mo
uha" fullname="Nicky Mouha" />
<author initials="K." surname="Ya
suda" fullname="Kan Yasuda " />
<date year="2014" />
</front>
<seriesInfo name="DOI" value="10.1007/978
-3-662-45611-8_6" />
<refcontent>Advances in Cryptology – ASIA
CRYPT 2014. ASIACRYPT 2014. Lecture Notes in Computer Science, vol 8873. Springe
r, Berlin, Heidelberg</refcontent>
</reference>
<reference anchor="MBTM17">
<front>
<title>Report on Lightweight Cryp
tography</title>
<author initials="K." surname="Mc
Kay" fullname="Kerry A. McKay" />
<author initials="L." surname="Ba
ssham" fullname="Larry Bassham" />
<author initials="MS." surname="T
uran" fullname="Meltem Sönmez Turan" />
<author initials="N." surname="Mo
uha" fullname="Nicky Mouha" />
<date year="2017" />
</front>
<seriesInfo name="DOI" value="10.6028/NIS
T.IR.8114" />
</reference>
<reference anchor="HRRV15">
<front>
<title>Online Authenticated-Encry
ption and its Nonce-Reuse Misuse-Resistance</title>
<author initials="VT." surname="H
oang" fullname="Viet Tung Hoang" />
<author initials="R." surname="Re
yhanitabar" fullname="Reza Reyhanitabar" />
<author initials="P." surname="Ro
gaway" fullname="Phillip Rogaway" />
<author initials="D." surname="Vi
zá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 -- CRY
PTO 2015. CRYPTO 2015. Lecture Notes in Computer Science, vol 9215. Springer, Be
rlin, Heidelberg</refcontent>
</reference>
<reference anchor="C20">
<front>
<title>INT-RUP Secure Lightweight
Parallel AE Modes</title>
<author initials="A." surname="Ch
akraborti" fullname="Avik Chakraborti" />
<author initials="N." surname="Da
tta" fullname="Nilanjan Datta" />
<author initials="A." surname="Jh
a" fullname="Ashwin Jha" />
<author initials="C." surname="Ma
ncillas-López" fullname="Cuauhtemoc Mancillas-López" />
<author initials="M." surname="Na
ndi" fullname="Mridul Nandi" />
<author initials="Y." surname="Sa
saki" fullname="Yu Sasaki" />
<date year="2020" />
</front>
<seriesInfo name="DOI" value="10.13154/to
sc.v2019.i4.81-118" />
<refcontent>IACR Transactions on Symmetri
c Cryptology, 2019(4), 81–118</refcontent>
</reference>
<!--
<reference anchor="DGGK21">
<front>
<title>CIMINION: Symmetric Encryp
tion Based on Toffoli-Gates over Large Finite Fields</title>
<author initials="C." surname="Do
braunig" fullname="Christoph Dobraunig" />
<author initials="L." surname="Gr
assi" fullname="Lorenzo Grassi" />
<author initials="G." surname="Gu
inet" fullname="Anna Guinet" />
<author initials="D." surname="Ku
ijsters" fullname="Daniël Kuijsters" />
<date year="2021" />
</front>
<seriesInfo name="DOI" value="10.1007/978
-3-030-77886-6_1" />
<refcontent>Advances in Cryptology - EURO
CRYPT 2021. EUROCRYPT 2021. Lecture Notes in Computer Science(), vol 12697. Spri
nger, Cham</refcontent>
</reference>
<reference anchor="BKY02">
<front>
<title>Incremental Unforgeable En
cryption</title>
<author initials="E." surname="Bu
onanno" fullname="Enrico Buonanno" />
<author initials="J." surname="Ka
tz" fullname="Jonathan Katz" />
<author initials="M." surname="Yu
ng" fullname="Moti Yung" />
<date year="2002" />
</front>
<seriesInfo name="DOI" value="10.1007/3-5
40-45473-X_9" />
<refcontent>Fast Software Encryption. FSE
2001. Lecture Notes in Computer Science, vol 2355. Springer, Berlin, Heidelberg
</refcontent>
</reference>
<reference anchor="SY16">
<front>
<title>A New Mode of Operation fo
r Incremental Authenticated Encryption with Associated Data</title>
<author initials="Y." surname="Sa
saki" fullname="Yu Sasaki" />
<author initials="K." surname="Ya
suda" fullname="Kan Yasuda" />
<date year="2016" />
</front>
<seriesInfo name="DOI" value="10.1007/978
-3-319-31301-6_23" />
<refcontent>Selected Areas in Cryptograph
y – SAC 2015. SAC 2015. Lecture Notes in Computer Science, vol 9566. Springer, C
ham</refcontent>
</reference>
<reference anchor="BNT19">
<front>
<title>Nonces Are Noticed: AEAD R
evisited</title>
<author initials="M." surname="Be
llare" fullname="Mihir Bellare" />
<author initials="R." surname="Ng
" fullname="Ruth Ng" />
<author initials="B." surname="Ta
ckmann" fullname="Björn Tackmann" />
<date year="2019" />
</front>
<seriesInfo name="DOI" value="10.1007/978
-3-030-26948-7_9" />
<refcontent>Advances in Cryptology – CRYP
TO 2019. CRYPTO 2019. Lecture Notes in Computer Science, vol 11692. Springer, Ch
am</refcontent>
</reference>
<reference anchor="BH22">
<front>
<title>Efficient schemes for comm
itting authenticated encryption</title>
<author initials="M." surname="Be
llare" 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 – EURO
CRYPT 2022. EUROCRYPT 2022. Lecture Notes in Computer Science, vol 13276. Spring
er, Cham.</refcontent>
</reference>
<reference anchor="CR22">
<front>
<title>On Committing Authenticate
d-Encryption</title>
<author initials="J." surname="Ch
an" fullname="John Chan" />
<author initials="P." surname="Ro
gaway" fullname="Phillip Rogaway" />
<date year="2022" />
</front>
<seriesInfo name="DOI" value="10.1007/978
-3-031-17146-8_14" />
<refcontent>Computer Security – ESORICS 2
022. ESORICS 2022. Lecture Notes in Computer Science, vol 13555. Springer, Cham.
</refcontent>
</reference>
<!-- <reference anchor="BFN98">
<front>
<title>A formal treatment of remo
tely keyed encryption</title>
<author initials="M." surname="Bl
aze" fullname="Matt Blaze" />
<author initials="J." surname="Fe
igenbaum" fullname="Joan Feigenbaum" />
<author initials="M." surname="Na
or" fullname="Moni Naor" />
<date year="1998" />
</front>
<seriesInfo name="DOI" value="10.1007/BFb
0054131" />
<refcontent>Advances in Cryptology - EURO
CRYPT'98. EUROCRYPT 1998. Lecture Notes in Computer Science, vol 1403. Springer,
Berlin, Heidelberg</refcontent>
</reference>
--> -->
<!-- <reference anchor="DA03"> <reference anchor="BN2000">
<front> <front>
<title>Concealment and Its Applic <title>Authenticated Encryption: Relations among Notions and An
ations to Authenticated Encryption</title> alysis of the Generic Composition Paradigm</title>
<author initials="Y." surname="Do <author initials="M." surname="Bellare" fullname="Mihir Bellare
dis" fullname="Yevgeniy Dodis" /> " />
<author initials="JH." surname="A <author initials="C." surname="Namprempre" fullname="Chanathip
n" fullname="Jee Hea An" /> Namprempre" />
<date year="2003" /> <date year="2000" />
</front> </front>
<seriesInfo name="DOI" value="10.1007/3-5 <seriesInfo name="DOI" value="10.1007/3-540-44448-3_41"/>
40-39200-9_19" /> <refcontent>Advances in Cryptology - ASIACRYPT 2000, Lecture Note
<refcontent>Advances in Cryptology - EURO s in Computer Science, vol. 1976, pp. 531-545</refcontent>
CRYPT 2003. EUROCRYPT 2003. Lecture Notes in Computer Science, vol 2656. Springe </reference>
r, Berlin, Heidelberg</refcontent>
</reference> <reference anchor="JMV2002">
<front>
<title>Blockwise-Adaptive Attackers Revisiting the (In)Security
of Some Provably Secure Encryption Modes: CBC, GEM, IACBC</title>
<author initials="A." surname="Joux" fullname="Antoine Joux" />
<author initials="G." surname="Martinet" fullname="Gwenaelle Ma
rtinet" />
<author initials="F." surname="Valette" fullname="Frederic Vale
tte" />
<date year="2002" />
</front>
<seriesInfo name="DOI" value="10.1007/3-540-45708-9_2" />
<refcontent>Advances in Cryptology - CRYPTO 2002, Lecture Notes i
n Computer Science, vol. 2442</refcontent>
</reference>
<reference anchor="FJMV2004">
<front>
<title>Authenticated On-Line Encryption</title>
<author initials="P.-A." surname="Fouque" fullname="Pierre-Alai
n Fouque" />
<author initials="A." surname="Joux" fullname="Antoine Joux" />
<author initials="G." surname="Martinet" fullname="Gwenaelle Ma
rtinet" />
<author initials="F." surname="Valette" fullname="Frederic Vale
tte" />
<date year="2004" />
</front>
<seriesInfo name="DOI" value="10.1007/978-3-540-24654-1_11" />
<refcontent>Selected Areas in Cryptography (SAC 2003), Lecture No
tes in Computer Science, vol. 3006</refcontent>
</reference>
<reference anchor="FOR17">
<front>
<title>Security of Symmetric Primitives under Incorrect Usage o
f Keys</title>
<author initials="P." surname="Farshim" fullname="Pooya Farshim
" />
<author initials="C." surname="Orlandi" fullname="Claudio Orlan
di" />
<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="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 Ris
tenpart" />
<date year="2021" />
</front>
<refcontent>30th USENIX Security Symposium (USENIX Security 21),
pp. 195-212</refcontent>
</reference>
<reference anchor="GLR17">
<front>
<title>Message Franking via Committing Authenticated Encryption
</title>
<author initials="P." surname="Grubbs" fullname="Paul Grubbs" /
>
<author initials="J." surname="Lu" fullname="Jiahui Lu" />
<author initials="T." surname="Ristenpart" fullname="Thomas Ris
tenpart" />
<date year="2017" />
</front>
<seriesInfo name="DOI" value="10.1007/978-3-319-63697-9_3" />
<refcontent>Advances in Cryptology - CRYPTO 2017, Lecture Notes i
n Computer Science, vol. 10403, pp. 66-97</refcontent>
</reference>
<reference anchor="B20">
<front>
<title>Mode-Level vs. Implementation-Level Physical Security in
Symmetric Cryptography: A Practical Guide Through the Leakage-Resistance Jungle
</title>
<author initials="D." surname="Bellizia" fullname="Davide Belli
zia" />
<author initials="O." surname="Bronchain" fullname="Olivier Bro
nchain" />
<author initials="G." surname="Cassiers" fullname="Gaëtan Cassi
ers" />
<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 Perei
ra" />
<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 i
n Computer Science, vol. 12170, pp. 369-400</refcontent>
</reference>
<!-- [rfced] FYI - We updated the title in the reference entry to match the
title in the provided URL.
Original;
[GPPS19] Guo, C., Pereira, O., Peters, T., and FX. Standaert,
"Authenticated Encryption with Nonce Misuse and Physical
Leakages: Definitions, Separation Results and Leveled
Constructions", Progress in Cryptology - LATINCRYPT 2019.
LATINCRYPT 2019. Lecture Notes in Computer Science, vol
11774. Springer, Cham, DOI 10.1007/978-3-030-30530-7_8,
2019, <https://doi.org/10.1007/978-3-030-30530-7_8>.
Updated:
[GPPS19] Guo, C., Pereira, O., Peters, T., and F.-X. Standaert,
"Authenticated Encryption with Nonce Misuse and Physical
Leakages: Definitions, Separation Results and First
Construction", Progress in Cryptology - LATINCRYPT 2019,
Lecture Notes in Computer Science, vol. 11774, pp.
150-172, DOI 10.1007/978-3-030-30530-7_8, 2019,
<https://doi.org/10.1007/978-3-030-30530-7_8>.
--> -->
<reference anchor="HKR2015"> <reference anchor="GPPS19">
<front> <front>
<title>Robust Authenticated-Encry <title>Authenticated Encryption with Nonce Misuse and Physical
ption AEZ and the Problem That It Solves</title> Leakages: Definitions, Separation Results and First Construction</title>
<author initials="VT." surname="H <author initials="C." surname="Guo" fullname="Chun Guo" />
oang" fullname="Viet Tung Hoang" /> <author initials="O." surname="Pereira" fullname="Olivier Perei
<author initials="T." surname="Kr ra" />
ovetz" fullname="Ted Krovetz" /> <author initials="T." surname="Peters" fullname="Thomas Peters"
<author initials="P." surname="Ro />
gaway" fullname="Phillip Rogaway" /> <author initials="F.-X." surname="Standaert" fullname="François
<date year="2015" /> -Xavier Standaert" />
</front> <date year="2019" />
<seriesInfo name="DOI" value="10.1007/978 </front>
-3-662-46800-5_2" /> <seriesInfo name="DOI" value="10.1007/978-3-030-30530-7_8" />
<refcontent>Advances in Cryptology -- EUR <refcontent>Progress in Cryptology - LATINCRYPT 2019, Lecture Not
OCRYPT 2015. EUROCRYPT 2015. Lecture Notes in Computer Science, vol 9056. Spring es in Computer Science, vol. 11774, pp. 150-172</refcontent>
er, Berlin, Heidelberg.</refcontent> </reference>
</reference>
<reference anchor="MLGR23"> <reference anchor="BT16">
<front> <front>
<title>Context Discovery and Comm <title>The Multi-user Security of Authenticated Encryption: AES
itment Attacks: How to Break CCM, EAX, SIV, and More</title> -GCM in TLS 1.3</title>
<author initials="S." surname="Me <author initials="M." surname="Bellare" fullname="Mihir Bellare
nda" fullname="Sanketh Menda" /> " />
<author initials="J." surname="Ju <author initials="B." surname="Tackmann" fullname="Björn Tackma
lia" fullname="Julia Len" /> nn" />
<author initials="P." surname="Gr <date year="2016" />
ubbs" fullname="Paul Grubbs" /> </front>
<author initials="T." surname="Ri <seriesInfo name="DOI" value="10.1007/978-3-662-53018-4_10" />
stenpart" fullname="Thomas Ristenpart" /> <refcontent>Advances in Cryptology - CRYPTO 2016, Lecture Notes i
<date year="2023" /> n Computer Science, vol. 9814, pp. 247-276</refcontent>
</front> </reference>
<seriesInfo name="DOI" value="10.1007/978
-3-031-30634-1_13" />
<refcontent>Advances in Cryptology – EURO
CRYPT 2023. EUROCRYPT 2023. Lecture Notes in Computer Science, vol 14007. Spring
er, Cham.</refcontent>
</reference>
<reference anchor="BBCLNSS21"> <reference anchor="RS06">
<front> <front>
<title>QCB: Efficient Quantum-Sec <title>A Provable-Security Treatment of the Key-Wrap Problem</t
ure Authenticated Encryption</title> itle>
<author initials="R." surname="Bh <author initials="R." surname="Rogaway" fullname="Phillip Rogaw
aumik" fullname="Ritam Bhaumik" /> ay" />
<author initials="X." surname="Bo <author initials="T." surname="Shrimpton" fullname="Thomas Shri
nnetain" fullname="Xavier Bonnetain" /> mpton" />
<author initials="A." surname="Ch <date year="2016" />
ailloux" fullname="André Chailloux" /> </front>
<author initials="G." surname="Le <seriesInfo name="DOI" value="10.1007/11761679_23" />
urent" fullname="Gaëtan Leurent" /> <refcontent>Advances in Cryptology - EUROCRYPT 2006, Lecture Note
<author initials="M." surname="Na s in Computer Science, vol. 4004, pp. 373-390</refcontent>
ya-Plasencia" fullname="María Naya-Plasencia" /> </reference>
<author initials="A." surname="Sc
hrottenlohe" fullname="André Schrottenlohe" />
<author initials="Y." surname="Se
urin" fullname="Yannick Seurin" />
<date year="2021" />
</front>
<seriesInfo name="DOI" value="10.1007/978
-3-030-92062-3_23" />
<refcontent>Advances in Cryptology – ASIA
CRYPT 2021. ASIACRYPT 2021. Lecture Notes in Computer Science(), vol 13090. Spri
nger, Cham.</refcontent>
</reference>
<reference anchor="KLLNP16"> <reference anchor="ADL17">
<front> <front>
<title>Quantum Differential and L <title>Boosting Authenticated Encryption Robustness with Minima
inear Cryptanalysis</title> l Modifications</title>
<author initials="M." surname="Me <author initials="T." surname="Ashur" fullname="Tomer Ashur" />
nda" fullname="Marc Kaplan" /> <author initials="O." surname="Dunkelman" fullname="Orr Dunkelm
<author initials="G." surname="Le an" />
urent" fullname="Gaëtan Leurent" /> <author initials="A." surname="Luykx" fullname="Atul Luykx" />
<author initials="A." surname="Le <date year="2017" />
verrier" fullname="Anthony Leverrier" /> </front>
<author initials="M." surname="Na <seriesInfo name="DOI" value="10.1007/978-3-319-63697-9_1" />
ya-Plasencia" fullname="María Naya-Plasencia" /> <refcontent>Advances in Cryptology - CRYPTO 2017, Lecture Notes i
<date year="2021" /> n Computer Science, vol. 10403, pp. 3-33</refcontent>
</front> </reference>
<seriesInfo name="DOI" value="10.13154/to
sc.v2016.i1.71-94" />
<refcontent> IACR Transactions on Symmetr
ic Cryptology, 2016(1), 71–94.</refcontent>
</reference>
<reference anchor="G17" target="https://tuprints. <reference anchor="FLLW17">
ulb.tu-darmstadt.de/6019/"> <front>
<front> <title>Reforgeability of Authenticated Encryption Schemes</titl
<title>Quantum Security of Crypto e>
graphic Primitives</title> <author initials="C." surname="Forler" fullname="Christian Forl
<author initials="T." surname="Ga er" />
gliardoni" fullname="Tommaso Gagliardoni"/> <author initials="E." surname="List" fullname="Eik List" />
<date year="2017"/> <author initials="S." surname="Lucks" fullname="Stefan Lucks" /
</front> >
<refcontent>Ph.D. Thesis, Technische Univ <author initials="J." surname="Wenzel" fullname="Jakob Wenzel"
ersität Darmstadt</refcontent> />
</reference> <date year="2017" />
</front>
<seriesInfo name="DOI" value="10.1007/978-3-319-59870-3_2" />
<refcontent>Information Security and Privacy (ACISP 2017), Lectur
e Notes in Computer Science, vol. 10343, pp. 19-37</refcontent>
</reference>
<reference anchor="EV16"> <reference anchor="BC09">
<front> <front>
<title>Linking Online Misuse-Resi <title>MAC Reforgeability</title>
stant Authenticated Encryption and Blockwise Attack Models</title> <author initials="J." surname="Black" fullname="John Black" />
<author initials="G." surname="En <author initials="M." surname="Cochran" fullname="Martin Cochra
dignoux" fullname="Guillaume Endignoux"/> n" />
<author initials="D." surname="Vi <date year="2009" />
zár" fullname="Damian Vizár"/> </front>
<date year="2016"/> <seriesInfo name="DOI" value="10.1007/978-3-642-03317-9_21" />
</front> <refcontent>Fast Software Encryption (FSE 2009), Lecture Notes in
<seriesInfo name="DOI" value="10.13154/TO Computer Science, vol. 5665, pp. 345-362</refcontent>
SC.V2016.I2.125-144" /> </reference>
<refcontent>IACR Transactions on Symmetri
c Cryptology</refcontent>
</reference>
<reference anchor="FFL12"> <reference anchor="A14">
<front> <front>
<title>McOE: A family of almost f <title>How to Securely Release Unverified Plaintext in Authenti
oolproof on-line authenticated encryption schemes</title> cated Encryption</title>
<author initials="E." surname="Fl <author initials="E." surname="Andreeva" fullname="Elena Andree
eischmann" fullname="Ewan Fleischmann"/> va" />
<author initials="C." surname="Fo <author initials="A." surname="Bogdanov" fullname="Andrey Bogda
rler" fullname="Christian Forler"/> nov" />
<author initials="S." surname="Lu <author initials="A." surname="Luykx" fullname="Atul Luykx" />
cks" fullname="Stefan Lucks"/> <author initials="B." surname="Mennink" fullname="Bart Mennink"
<date year="2012"/> />
</front> <author initials="N." surname="Mouha" fullname="Nicky Mouha" />
<seriesInfo name="DOI" value="10.1007/978 <author initials="K." surname="Yasuda" fullname="Kan Yasuda " /
-3-642-34047-5_12" /> >
<refcontent>Fast Software Encryption: 19t <date year="2014" />
h International Workshop, FSE 2012, Washington, DC, USA, March 19-21, 2012. Revi </front>
sed Selected Papers. Springer Berlin Heidelberg, 2012</refcontent> <seriesInfo name="DOI" value="10.1007/978-3-662-45611-8_6" />
</reference> <refcontent>Advances in Cryptology - ASIACRYPT 2014, Lecture Note
s in Computer Science, vol. 8873, pp. 105-125</refcontent>
</reference>
<reference anchor="ABV21"> <reference anchor="MBTM17">
<front> <front>
<title>Nonce-misuse security of t <title>Report on Lightweight Cryptography</title>
he SAEF authenticated encryption mode</title> <author initials="K." surname="McKay" fullname="Kerry A. McKay"
<author initials="E." surname="An />
dreeva" fullname="Elena Andreeva"/> <author initials="L." surname="Bassham" fullname="Larry Bassham
<author initials="A.S." surname=" " />
Bhati" fullname="Amit Singh Bhati"/> <author initials="MS." surname="Turan" fullname="Meltem Sönmez
<author initials="D." surname="Vi Turan" />
zár" fullname="Damian Vizár"/> <author initials="N." surname="Mouha" fullname="Nicky Mouha" />
<date year="2021"/> <date year="2017" />
</front> </front>
<seriesInfo name="DOI" value="10.1007/978 <seriesInfo name="NISTIR" value="8114"/>
-3-030-81652-0_20" /> <seriesInfo name="DOI" value="10.6028/NIST.IR.8114" />
<refcontent>Selected Areas in Cryptograph </reference>
y: 27th International Conference, Halifax, NS, Canada (Virtual Event), October 2
1-23, 2020, Revised Selected Papers 27. Springer International Publishing, 2021<
/refcontent>
</reference>
<reference anchor="YSS23"> <reference anchor="HRRV15">
<front> <front>
<title>Committing Security of Asc <title>Online Authenticated-Encryption and its Nonce-Reuse Misu
on: Cryptanalysis on Primitive and Proof on Mode</title> se-Resistance</title>
<author initials="Y." surname="Na <author initials="VT." surname="Hoang" fullname="Viet Tung Hoan
ito" fullname="Yusuke Naito"/> g" />
<author initials="Y." surname="Sa <author initials="R." surname="Reyhanitabar" fullname="Reza Rey
saki" fullname="Yu Sasaki"/> hanitabar" />
<author initials="T." surname="Su <author initials="P." surname="Rogaway" fullname="Phillip Rogaw
gawara" fullname="Takeshi Sugawara"/> ay" />
<date year="2023"/> <author initials="D." surname="Vizár" fullname="Damian Vizár" /
</front> >
<seriesInfo name="DOI" value="10.46586/to <date year="2015" />
sc.v2023.i4.420-451" /> </front>
<refcontent>IACR Transactions on Symmetri <seriesInfo name="DOI" value="10.1007/978-3-662-47989-6_24" />
c Cryptology 2023, no. 4 (2023): 420-451</refcontent> <refcontent>Advances in Cryptology -- CRYPTO 2015, Lecture Notes
</reference> in Computer Science, vol. 9215, pp. 493-517</refcontent>
</reference>
<reference anchor="ADGKLS22"> <reference anchor="C20">
<front> <front>
<title>How to abuse and fix authe <title>INT-RUP Secure Lightweight Parallel AE Modes</title>
nticated encryption without key commitment</title> <author initials="A." surname="Chakraborti" fullname="Avik Chak
<author initials="A." surname="Al raborti" />
bertini" fullname="Ange Albertini"/> <author initials="N." surname="Datta" fullname="Nilanjan Datta"
<author initials="T." surname="Du />
ong" fullname="Thai Duong"/> <author initials="A." surname="Jha" fullname="Ashwin Jha" />
<author initials="S." surname="Gu <author initials="C." surname="Mancillas-López" fullname="Cuauh
eron" fullname="Shay Gueron"/> temoc Mancillas-López" />
<author initials="S." surname="Kö <author initials="M." surname="Nandi" fullname="Mridul Nandi" /
lbl" fullname="Stefan Kölbl"/> >
<author initials="A." surname="Lu <author initials="Y." surname="Sasaki" fullname="Yu Sasaki" />
ykx" fullname="Atul Luykx"/> <date year="2020" />
<author initials="S." surname="Sc </front>
hmieg" fullname="Sophie Schmieg"/> <seriesInfo name="DOI" value="10.13154/tosc.v2019.i4.81-118" />
<date year="2022"/> <refcontent>IACR Transactions on Symmetric Cryptology, vol. 2019,
</front> no.4, pp. 81-118</refcontent>
<refcontent>1st USENIX Security Symposium </reference>
(USENIX Security 22), pp. 3291-3308. 2022</refcontent>
</reference>
<reference anchor="BPPS17"> <reference anchor="BKY02">
<front> <front>
<title>On leakage-resilient authe <title>Incremental Unforgeable Encryption</title>
nticated encryption with decryption leakages</title> <author initials="E." surname="Buonanno" fullname="Enrico Buona
<author initials="F." surname="Be nno" />
rti" fullname="Francesco Berti" /> <author initials="J." surname="Katz" fullname="Jonathan Katz" /
<author initials="O." surname="Pe >
reira" fullname="Olivier Pereira" /> <author initials="M." surname="Yung" fullname="Moti Yung" />
<author initials="T." surname="Pe <date year="2002" />
ters" fullname="Thomas Peters" /> </front>
<author initials="F.X." surname=" <seriesInfo name="DOI" value="10.1007/3-540-45473-X_9" />
Standaert" fullname="François-Xavier Standaert" /> <refcontent>Fast Software Encryption (FSE 2001), Lecture Notes in
<date year="2017" /> Computer Science, vol. 2355, pp. 109-124</refcontent>
</front> </reference>
<seriesInfo name="DOI" value="10.13154/to
sc.v2017.i3.271-293" />
<refcontent>IACR Transactions on Symmetri
c Cryptology (2017): 271-293</refcontent>
</reference>
<reference anchor="HTT18"> <reference anchor="SY16">
<front> <front>
<title>The multi-user security of <title>A New Mode of Operation for Incremental Authenticated En
GCM, revisited: Tight bounds for nonce randomization</title> cryption with Associated Data</title>
<author initials="V.T." surname=" <author initials="Y." surname="Sasaki" fullname="Yu Sasaki" />
Hoang" fullname="Viet Tung Hoang" /> <author initials="K." surname="Yasuda" fullname="Kan Yasuda" />
<author initials="S." surname="Te <date year="2016" />
ssaro" fullname="Stefano Tessaro" /> </front>
<author initials="A." surname="Th <seriesInfo name="DOI" value="10.1007/978-3-319-31301-6_23" />
iruvengadam" fullname="Aishwarya Thiruvengadam" /> <refcontent>Selected Areas in Cryptography - SAC 2015, Lecture No
<date year="2018" /> tes in Computer Science, vol. 9566, pp. 397-416</refcontent>
</front> </reference>
<seriesInfo name="DOI" value="10.1145/324
3734.3243816" />
<refcontent>Proceedings of the 2018 ACM S
IGSAC Conference on Computer and Communications Security, pp. 1429-1440. 2018</r
efcontent>
</reference>
<reference anchor="BHT18"> <reference anchor="BNT19">
<front> <front>
<title>Revisiting AES-GCM-SIV: mu <title>Nonces Are Noticed: AEAD Revisited</title>
lti-user security, faster key derivation, and better bounds</title> <author initials="M." surname="Bellare" fullname="Mihir Bellare
<author initials="P." surname="Bo " />
se" fullname="Priyanka Bose" /> <author initials="R." surname="Ng" fullname="Ruth Ng" />
<author initials="V.T." surname=" <author initials="B." surname="Tackmann" fullname="Björn Tackma
Hoang" fullname="Viet Tung Hoang" /> nn" />
<author initials="S." surname="Te <date year="2019" />
ssaro" fullname="Stefano Tessaro" /> </front>
<date year="2018" /> <seriesInfo name="DOI" value="10.1007/978-3-030-26948-7_9" />
</front> <refcontent>Advances in Cryptology - CRYPTO 2019, Lecture Notes i
<seriesInfo name="DOI" value="10.1007/978 n Computer Science, vol. 11692, pp. 235-265</refcontent>
-3-319-78381-9_18" /> </reference>
<refcontent>Annual International Conferen
ce on the Theory and Applications of Cryptographic Techniques, pp. 468-499. Cham
: Springer International Publishing, 2018</refcontent>
</reference>
<reference anchor="LMP17"> <reference anchor="BH22">
<front> <front>
<title>Analyzing multi-key securi <title>Efficient Schemes for Committing Authenticated Encryptio
ty degradation</title> n</title>
<author initials="A." surname="Lu <author initials="M." surname="Bellare" fullname="Mihir Bellare
ykx" fullname="Atul Luykx" /> " />
<author initials="B." surname="Me <author initials="V.T." surname="Hoang" fullname="Viet Tung Hoa
nnink" fullname="Bart Mennink" /> ng" />
<author initials="K." surname="Pa <date year="2022" />
terson" fullname="Kenneth G. Paterson" /> </front>
<date year="2017" /> <seriesInfo name="DOI" value="10.1007/978-3-031-07085-3_29" />
</front> <refcontent>Advances in Cryptology - EUROCRYPT 2022, Lecture Note
<seriesInfo name="DOI" value="10.1007/978 s in Computer Science, vol. 13276, pp. 845-875</refcontent>
-3-319-70697-9_20" /> </reference>
<refcontent>Conference on the Theory and
Applications of Cryptology and Information Security, Hong Kong, China, December
3-7, 2017, Proceedings, Part II 23, pp. 575-605. Springer International Publishi
ng, 2017.</refcontent>
</reference>
<reference anchor="DGGP21"> <reference anchor="CR22">
<front> <front>
<title>The security of ChaCha20-P <title>On Committing Authenticated-Encryption</title>
oly1305 in the multi-user setting</title> <author initials="J." surname="Chan" fullname="John Chan" />
<author initials="J.P." surname=" <author initials="P." surname="Rogaway" fullname="Phillip Rogaw
Degabriele" fullname="Jean Paul Degabriele" /> ay" />
<author initials="J." surname="Go <date year="2022" />
vinden" fullname="Jérôme Govinden" /> </front>
<author initials="F." surname="Gü <seriesInfo name="DOI" value="10.1007/978-3-031-17146-8_14" />
nther" fullname="Felix Günther" /> <refcontent>Computer Security - ESORICS 2022, Lecture Notes in Co
<author initials="K." surname="Pa mputer Science, vol. 13555, pp. 275-294</refcontent>
terson" fullname="Kenneth G. Paterson" /> </reference>
<date year="2021" />
</front>
<seriesInfo name="DOI" value="10.1145/346
0120.3484814" />
<refcontent>In Proceedings of the 2021 AC
M SIGSAC Conference on Computer and Communications Security, pp. 1981-2003. 2021
.</refcontent>
</reference>
<reference anchor="B13" target="https://groups.go <reference anchor="HKR2015">
ogle.com/d/msg/crypto-competitions/n5ECGwYr6Vk/bsEfPWqSAU4J"> <front>
<front> <title>Robust Authenticated-Encryption AEZ and the Problem That It Solves</t
<title>Re: secret message numbers itle>
</title> <author initials="V.T." surname="Hoang" fullname="Viet Tung Hoang" />
<author initials="D. J. " surname <author initials="T." surname="Krovetz" fullname="Ted Krovetz" />
="Bernstein" fullname="Daniel J. Bernstein" /> <author initials="P." surname="Rogaway" fullname="Phillip Rogaway" />
<date year="2013" /> <date year="2015" />
</front> </front>
<refcontent>Message in Google group on cr <seriesInfo name="DOI" value="10.1007/978-3-662-46800-5_2" />
yptographic competitions, October 2013.</refcontent> <refcontent>Advances in Cryptology -- EUROCRYPT 2015, Lecture Notes in Compute
</reference> r Science, vol. 9056, pp. 15-44</refcontent>
</reference>
<reference anchor="BM18"> <reference anchor="MLGR23">
<front> <front>
<title>Indifferentiable authentic <title>Context Discovery and Commitment Attacks: How to Break CCM, EAX, SIV,
ated encryption</title> and More</title>
<author initials="M." surname="Ba <author initials="S." surname="Menda" fullname="Sanketh Menda" />
rbosa" fullname="Manuel Barbosa" /> <author initials="J." surname="Julia" fullname="Julia Len" />
<author initials="P." surname="Fa <author initials="P." surname="Grubbs" fullname="Paul Grubbs" />
rshim" fullname="Pooya Farshim" /> <author initials="T." surname="Ristenpart" fullname="Thomas Ristenpart" />
<date year="2018" /> <date year="2023" />
</front> </front>
<seriesInfo name="DOI" value="10.1007/978 <seriesInfo name="DOI" value="10.1007/978-3-031-30634-1_13" />
-3-319-96884-1_7" /> <refcontent>Advances in Cryptology - EUROCRYPT 2023, Lecture Notes in Computer
<refcontent>Advances in Cryptology–CRYPTO Science, vol. 14007, pp. 379-407</refcontent>
2018: 38th Annual International Cryptology Conference, Santa Barbara, CA, USA, </reference>
August 19–23, 2018, Proceedings, Part I 38, pp. 187-220. Springer International
Publishing, 2018. </refcontent>
</reference>
<reference anchor="JNPS21"> <reference anchor="BBCLNSS21">
<front> <front>
<title>The Deoxys AEAD family</ti <title>QCB: Efficient Quantum-Secure Authenticated Encryption</title>
tle> <author initials="R." surname="Bhaumik" fullname="Ritam Bhaumik" />
<author initials="M." surname="Je <author initials="X." surname="Bonnetain" fullname="Xavier Bonnetain" />
an" fullname="Jérémy Jean" /> <author initials="A." surname="Chailloux" fullname="André Chailloux" />
<author initials="I." surname="Ni <author initials="G." surname="Leurent" fullname="Gaëtan Leurent" />
kolić" fullname="Ivica Nikolić" /> <author initials="M." surname="Naya-Plasencia" fullname="María Naya-Plasenci
<author initials="T." surname="Pe a" />
yrin" fullname="Thomas Peyrin" /> <author initials="A." surname="Schrottenloher" fullname="André Schrottenlohe
<author initials="Y." surname="Se r" />
urin" fullname="Yannick Seurin" /> <author initials="Y." surname="Seurin" fullname="Yannick Seurin" />
<date year="2021" /> <date year="2021" />
</front> </front>
<seriesInfo name="DOI" value="10.1007/s00 <seriesInfo name="DOI" value="10.1007/978-3-030-92062-3_23" />
145-021-09397-w" /> <refcontent>Advances in Cryptology - ASIACRYPT 2021, Lecture Notes in Computer
<refcontent>Journal of Cryptology 34, no. Science, vol. 13090, pp. 668-698</refcontent>
3 (2021): 31.</refcontent> </reference>
</reference>
<reference anchor="DEMS21a"> <reference anchor="KLLNP16">
<front> <front>
<title>Ascon v1.2: Lightweight Au <title>Quantum Differential and Linear Cryptanalysis</title>
thenticated Encryption and Hashing</title> <author initials="M." surname="Menda" fullname="Marc Kaplan" />
<author initials="C." surname="Do <author initials="G." surname="Leurent" fullname="Gaëtan Leurent" />
braunig" fullname="Christoph Dobraunig" /> <author initials="A." surname="Leverrier" fullname="Anthony Leverrier" />
<author initials="M." surname="Ei <author initials="M." surname="Naya-Plasencia" fullname="María Naya-Plasenci
chlseder" fullname="Maria Eichlseder" /> a" />
<author initials="F." surname="Me <date year="2016" />
ndel" fullname="Florian Mendel" /> </front>
<author initials="M." surname="Sc <seriesInfo name="DOI" value="10.13154/tosc.v2016.i1.71-94" />
hläffer" fullname="Martin Schläffer" /> <refcontent> IACR Transactions on Symmetric Cryptology, vol. 2016, no.1, pp. 7
<date year="2021" /> 1-94</refcontent>
</front> </reference>
<seriesInfo name="DOI" value="10.1007/s00
145-021-09398-9" />
<refcontent>Journal of Cryptology 34 (202
1): 1-42.</refcontent>
</reference>
<reference anchor="DEMS21b"> <reference anchor="G17" target="https://tuprints.ulb.tu-darmstadt.de/6019/">
<front> <front>
<title>Ascon v1.2</title> <title>Quantum Security of Cryptographic Primitives</title>
<author initials="C." surname="Do <author initials="T." surname="Gagliardoni" fullname="Tommaso Gagliardoni"/>
braunig" fullname="Christoph Dobraunig" /> <date year="2017"/>
<author initials="M." surname="Ei </front>
chlseder" fullname="Maria Eichlseder" /> <refcontent>Ph.D. Thesis, Technische Universität Darmstadt</refcontent>
<author initials="F." surname="Me </reference>
ndel" fullname="Florian Mendel" />
<author initials="M." surname="Sc
hläffer" fullname="Martin Schläffer" />
<date year="2021" />
</front>
<refcontent>Submission to the NIST LWC Co
mpetition</refcontent>
</reference>
<reference anchor="CJRR99"> <!-- [rfced] FYI - Per the provided URL, the date for this reference is "2017"
<front> rather than "2016". We updated the reference entry accordingly and also
<title>Towards sound approaches t updated the citation tag from from "[EV16]" to "[EV17]".
o counteract power-analysis attacks.</title>
<author initials="S." surname="Ch
ari" 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="Ro
hatgi" fullname="Pankaj Rohatgi" />
<date year="1999" />
</front>
<seriesInfo name="DOI" value="10.1007/3-5
40-48405-1_26" />
<refcontent>Advances in Cryptology—CRYPTO
'99: 19th Annual International Cryptology Conference Santa Barbara, California,
USA, August 15–19, 1999 Proceedings 19, pp. 398-412. Springer Berlin Heidelberg,
1999.</refcontent>
</reference>
<reference anchor="M05"> Original:
<front> [EV16] Endignoux, G. and D. Vizár, "Linking Online Misuse-
<title>Efficient authentication o Resistant Authenticated Encryption and Blockwise Attack
f large, dynamic data sets using Galois/Counter Mode (GCM).</title> Models", IACR Transactions on Symmetric Cryptology,
<author initials="D." surname="Mc DOI 10.13154/TOSC.V2016.I2.125-144, 2016,
Grew" fullname="David McGrew" /> <https://doi.org/10.13154/TOSC.V2016.I2.125-144>.
<date year="2005" />
</front>
<seriesInfo name="DOI" value="10.1109/SIS
W.2005.3" />
<refcontent>Third IEEE International Secu
rity in Storage Workshop (SISW'05), pp. 6-pp. IEEE, 2005.</refcontent>
</reference>
<reference anchor="S04" target="https://eprint.ia Perhaps:
cr.org/2004/272"> [EV17] Endignoux, G. and D. Vizár, "Linking Online Misuse-
<front> Resistant Authenticated Encryption and Blockwise Attack
<title>A Characterization of Auth Models", IACR Transactions on Symmetric Cryptology, vol.
enticated-Encryption as a Form of Chosen-Ciphertext Security</title> 2016, no. 2, pp. 125-144,
<author initials="T." surname="Sh DOI 10.13154/TOSC.V2016.I2.125-144, 2017,
rimpton" fullname="Tom Shrimpton" /> <https://doi.org/10.13154/TOSC.V2016.I2.125-144>.
<date year="2004" /> -->
</front> <reference anchor="EV17">
<refcontent>Cryptology ePrint Archive, Pa <front>
per 2004/272</refcontent> <title>Linking Online Misuse-Resistant Authenticated Encryption and Blockwis
</reference> e 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. 1
25-144</refcontent>
</reference>
<reference anchor="BMOS17"> <reference anchor="FFL12">
<front> <front>
<title>Authenticated encryption i <title>McOE: A Family of Almost Foolproof On-Line Authenticated Encryption S
n the face of protocol and side channel leakage.</title> chemes</title>
<author initials="G." surname="Ba <author initials="E." surname="Fleischmann" fullname="Ewan Fleischmann"/>
rwell" fullname="Guy Barwell" /> <author initials="C." surname="Forler" fullname="Christian Forler"/>
<author initials="D.P." surname=" <author initials="S." surname="Lucks" fullname="Stefan Lucks"/>
Martin" fullname="Daniel P. Martin" /> <date year="2012"/>
<author initials="E." surname="Os </front>
wald" fullname="Elisabeth Oswald" /> <seriesInfo name="DOI" value="10.1007/978-3-642-34047-5_12" />
<author initials="M." surname="St <refcontent>Fast Software Encryption (FSE 2012), Lecture Notes in Computer Sci
am" fullname="Martijn Stam" /> ence, vol. 7549, pp. 196-215</refcontent>
<date year="2017" /> </reference>
</front>
<seriesInfo name="DOI" value="10.1007/978
-3-319-70694-8_24" />
<refcontent>Advances in Cryptology – ASIA
CRYPT 2017. ASIACRYPT 2017. Lecture Notes in Computer Science, vol 10624. Spring
er, Cham</refcontent>
</reference>
</references>
</references>
<section anchor="AddProp" numbered="true" toc="default"> <reference anchor="ABV21">
<front>
<title>Nonce-Misuse Security of the SAEF Authenticated Encryption Mode</titl
e>
<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 Comput
er Science, vol. 12804, pp. 512-534</refcontent>
</reference>
<reference anchor="YSS23">
<front>
<title>Committing Security of Ascon: Cryptanalysis on Primitive and Proof on
Mode</title>
<author initials="Y." surname="Naito" fullname="Yusuke Naito"/>
<author initials="Y." surname="Sasaki" fullname="Yu Sasaki"/>
<author initials="T." surname="Sugawara" fullname="Takeshi Sugawara"/>
<date year="2023"/>
</front>
<seriesInfo name="DOI" value="10.46586/tosc.v2023.i4.420-451" />
<refcontent>IACR Transactions on Symmetric Cryptology, vol. 2023, no. 4, pp. 4
20-451</refcontent>
</reference>
<reference anchor="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="BPPS17">
<front>
<title>On Leakage-Resilient Authenticated Encryption with Decryption Leakage
s</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 Stand
aert" />
<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. 2
71-293</refcontent>
</reference>
<reference anchor="HTT18">
<front>
<title>The Multi-user Security of GCM, Revisited: Tight Bounds for Nonce Ran
domization</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 Thiruvenga
dam" />
<date year="2018" />
</front>
<seriesInfo name="DOI" value="10.1145/3243734.3243816" />
<refcontent>Proceedings of the 2018 ACM SIGSAC Conference on Computer and Comm
unications Security (CCS '18), pp. 1429-1440</refcontent>
</reference>
<reference anchor="BHT18">
<front>
<title>Revisiting AES-GCM-SIV: Multi-user Security, Faster Key Derivation, a
nd 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="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="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 Comm
unications Security (CCS '21), pp. 1981-2003</refcontent>
</reference>
<reference anchor="B13" target="https://groups.google.com/d/msg/crypto-competiti
ons/n5ECGwYr6Vk/bsEfPWqSAU4J">
<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="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 Sc
ience, vol. 10991, pp. 187-220</refcontent>
</reference>
<reference anchor="JNPS21">
<front>
<title>The Deoxys AEAD family</title>
<author initials="M." surname="Jean" fullname="Jérémy Jean" />
<author initials="I." surname="Nikolić" fullname="Ivica Nikolić" />
<author initials="T." surname="Peyrin" fullname="Thomas Peyrin" />
<author initials="Y." surname="Seurin" fullname="Yannick Seurin" />
<date year="2021" />
</front>
<seriesInfo name="DOI" value="10.1007/s00145-021-09397-w" />
<refcontent>Journal of Cryptology, vol. 34, no. 31</refcontent>
</reference>
<reference anchor="DEMS21a">
<front>
<title>Ascon v1.2: Lightweight Authenticated Encryption and Hashing</title>
<author initials="C." surname="Dobraunig" fullname="Christoph Dobraunig" />
<author initials="M." surname="Eichlseder" fullname="Maria Eichlseder" />
<author initials="F." surname="Mendel" fullname="Florian Mendel" />
<author initials="M." surname="Schläffer" fullname="Martin Schläffer" />
<date year="2021" />
</front>
<seriesInfo name="DOI" value="10.1007/s00145-021-09398-9" />
<refcontent>Journal of Cryptology, vol. 34, no. 33</refcontent>
</reference>
<reference anchor="DEMS21b">
<front>
<title>Ascon v1.2</title>
<author initials="C." surname="Dobraunig" fullname="Christoph Dobraunig" />
<author initials="M." surname="Eichlseder" fullname="Maria Eichlseder" />
<author initials="F." surname="Mendel" fullname="Florian Mendel" />
<author initials="M." surname="Schläffer" fullname="Martin Schläffer" />
<date year="2021" />
</front>
<refcontent>Submission to the NIST LWC Competition</refcontent>
</reference>
<reference anchor="CJRR99">
<front>
<title>Towards Sound Approaches 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 Scie
nce, vol. 1666, pp. 398-412</refcontent>
</reference>
<reference anchor="M05">
<front>
<title>Efficient authentication of large, dynamic data sets using Galois/Cou
nter 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), p
p. 6-94</refcontent>
</reference>
<reference anchor="S04" target="https://eprint.iacr.org/2004/272">
<front>
<title>A Characterization of Authenticated-Encryption as a Form of Chosen-Ci
phertext Security</title>
<author initials="T." surname="Shrimpton" fullname="Tom Shrimpton" />
<date year="2004" />
</front>
<refcontent>Cryptology ePrint Archive, Paper 2004/272</refcontent>
</reference>
<reference anchor="BMOS17">
<front>
<title>Authenticated Encryption in the Face of Protocol and Side Channel Lea
kage</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>
</references>
</references>
<section anchor="AddProp" numbered="true" toc="default">
<name>AEAD Algorithms with Additional Functionality</name > <name>AEAD Algorithms with Additional Functionality</name >
<t> <t>
In this section, we briefly discuss AEAD algorith ms that provide additional functionality. As noted in <xref target="Classificati on" format="default" />, each additional functionality requires a redefinition o f the conventional AEAD interface; thus, each additional functionality property defines a new class of cryptographic algorithms. In this section, we briefly discuss AEAD algorith ms that provide additional functionality. As noted in <xref target="Classificati on" format="default" />, each additional functionality requires a redefinition o f the conventional AEAD interface; thus, each additional functionality property defines a new class of cryptographic algorithms.
</t> </t>
<t> <t>
Most importantly, for every Additional Functional ity AEAD class, conventional security properties must be redefined concerning th e targeted additional functionality and the new interface. Although it might be possible to consider a particular Additional Functionality AEAD algorithm as a c onventional 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 sec urity in the sense of the redefined conventional properties would suffice. Most importantly, for every AEAD class with addit ional functionality, conventional security properties must be redefined concerni ng the targeted additional functionality and the new interface. Although it migh t be possible to consider a particular AEAD algorithm with additional functional ity as a conventional AEAD algorithm and study it for the conventional confident iality 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 suff ice.
</t> </t>
<t> <t>
For the examples given in this section, we leave it out of scope how to concretely redefine conventional security for these class es; we only briefly describe the additional functionality they offer and provide further references. For the examples given in this section, we leave it out of scope how to concretely redefine conventional security for these class es; we only briefly describe the additional functionality they offer and provide further references.
</t> </t>
<section anchor="Incremental" numbered="true" toc="defaul <section anchor="Incremental" numbered="true" toc="default">
t"> <name>Incremental Authenticated Encryption</name>
<name>Incremental Authenticated Encryption</name> <dl spacing="normal" newline="true">
<t>
Definition: An AEAD algorithm allows re-e
ncrypting and authenticating a message (associated data and a plaintext pair), w
hich only partly differs from some previous message, faster than processing it f
rom scratch.
</t>
<t>
Examples: Incremental AEAD algorithm of <
xref target="SY16" format="default" />.
</t>
<t>
Security notion: Privacy, Authenticity <x
ref target="SY16" format="default" />.
</t>
<t>
Notes: The interface of an incremental AE
AD algorithm is usually expanded, when compared with conventional AEAD, with sev
eral operations, which perform different types of updates. For example, one can
consider such operations as "Append" or "Chop", which provide a straightforward
additional functionality. A comprehensive definition of an incremental AEAD inte
rface is provided in <xref target="SY16" format="default" />.
</t>
<t>
Further reading:
<xref target="SY16" format="default" />,
<xref target="M05" format="default" />, <xref target="BKY02" format="default" />
.
</t>
</section>
<section anchor="Robust" numbered="true" toc="default">
<name>Robust Authenticated Encryption</name>
<t>
Definition: An AEAD algorithm allows user
s to choose a desired ciphertext expansion (the difference between the length of
plaintext and corresponding ciphertext) along with an input to the encryption o
peration. This feature enables the regulation of desired data integrity guarante
es, which depend on ciphertext expansion, for each particular application while
using the same algorithm implementation.
</t>
<t>
Examples: AEZ <xref target="HKR2015" form
at="default" />.
</t>
<t>
Security notion: RAE <xref target="HKR201
5" format="default" />.
</t>
<t>
Notes: The security goal of robust AEAD a
lgorithms is to ensure the best possible security, even with small ciphertext ex
pansion (referred to as stretch). For instance, analyzing any AEAD algorithm wit
h a one-byte stretch for conventional integrity reveals insecurity, as the proba
bility of forging a ciphertext is no less than 1/256. Nonetheless, from the robu
st AEAD perspective, an algorithm with such forgery probability for a one-byte c
iphertext expansion is secure, representing the best achievable security in that
scenario.
</t>
<t>
Further reading:
<xref target="HKR2015" format="default" /
>.
</t>
</section>
</section>
<section anchor="Acknowledgments" numbered="false" toc="default"> <!-- [rfced] May we update this sentence for clarity?
<name>Acknowledgments</name>
<t> Original:
This document benefited greatly from the comments An AEAD algorithm allows re-encrypting and authenticating a
received from the CFRG community, for which we are very grateful. We would also message (associated data and a plaintext pair), which only partly
like to extend special appreciation to Liliya Akhmetzyanova, Evgeny Alekseev, A differs from some previous message, faster than processing it from
lexandra Babueva, Frank Denis, Kirill Kutsenok, Sergey Kyazhin, Samuel Lucas, Gr scratch.
igory Marshalko, Christopher Patton, and Christopher Wood for their thoughtful c
omments, proposals, and discussions. Perhaps:
</t> For a message that only partly differs from some previous message, an
</section> AEAD algorithm allows re-encrypting and authenticating that
message (associated data and a plaintext pair) faster than processing it
from scratch.
-->
<dt>Definition:</dt><dd>An AEAD algorithm allows re-encrypting and
authenticating a message (associated data and a plaintext pair), which
only partly differs from some previous message, faster than processing it
from scratch.</dd>
<dt>Examples:</dt><dd>Incremental AEAD algorithm of <xref target="SY16" for
mat="default" /></dd>
<dt>Security notion:</dt><dd>Privacy, authenticity <xref target="SY16" form
at="default" /></dd>
<dt>Notes:</dt><dd>When compared with conventional AEAD, the interface of a
n 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" />.</dd>
<dt>Further reading:</dt><dd><xref target="SY16" format="default" />,
<xref target="M05" format="default" />, <xref target="BKY02"
format="default" /></dd>
</dl>
</section>
<section anchor="Robust" numbered="true" toc="default">
<name>Robust Authenticated Encryption</name>
<dl spacing="normal" newline="true">
<dt>Definition:</dt><dd>An AEAD algorithm allows users to choose a
desired ciphertext expansion (the difference between the length of
plaintext and corresponding ciphertext) along with an input to the
encryption operation. This feature enables the regulation of desired data
integrity guarantees, which depend on ciphertext expansion, for each
particular application while using the same algorithm
implementation.</dd>
<dt>Examples:</dt><dd>AEZ <xref target="HKR2015" format="default" /></dd>
<dt>Security notion:</dt><dd>RAE <xref target="HKR2015" format="default" />
</dd>
<dt>Notes:</dt><dd>The security goal of robust AEAD algorithms is to
ensure the best possible security, even with small ciphertext expansion
(referred to as stretch). For instance, analyzing any AEAD algorithm with
a one-byte stretch for conventional integrity reveals insecurity, as the
probability of forging a ciphertext is no less than 1/256. Nonetheless,
from the robust AEAD perspective, an algorithm with such forgery
probability for a one-byte ciphertext expansion is secure, representing
the best achievable security in that scenario.</dd>
<dt>Further reading:</dt><dd><xref target="HKR2015" format="default" /></dd
>
</dl>
</section>
</section>
<section anchor="Acknowledgments" numbered="false" toc="default">
<name>Acknowledgments</name>
<t>This document benefited greatly from the comments received from the CFRG
community, for which we are very grateful. We would also like to extend
special appreciation to <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>
<!-- [rfced] We updated "Additional Functionality AEAD class" and "Additional
Functionality AEAD algorithm" as follows. Please review.
Original:
Most importantly, for every Additional Functionality AEAD class,
conventional security properties must be redefined concerning the
targeted additional functionality and the new interface.
...
Although it
might be possible to consider a particular Additional Functionality
AEAD algorithm as a conventional AEAD algorithm ...
Updated:
Most importantly, for every AEAD class with additional functionality,
conventional security properties must be redefined concerning the
targeted additional functionality and the new interface.
...
Although it
might be possible to consider a particular
AEAD algorithm with additional functionality as a conventional AEAD algorithm
...
-->
<!-- [rfced] Abbreviations
a) FYI - We have added expansions for the following abbreviations
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correctness.
Encapsulating Security Payload (ESP)
Secure Real-time Transport Protocol (SRTP)
Voice over IP (VoIP)
Multilinear Galois Mode (MGM)
Synthetic Initialization Vector (SIV)
Galois/Counter Mode (GCM)
b) How should "CCA" be expanded here? As "Congestion Control Algorithm (CCA)"
or something else? Also, how should "CPA" be expanded here? As "Certification
Path Advertisement (CPA)"?
Original:
Security notion: CPA resilience (confidentiality), authenticity
resilience (integrity), CCA resilience (authenticated encryption)
[ADL17].
c) How should "RAE" be expanded? As "Robust Authenticated Encryption" or
something else?
Original:
Security notion: RAE [HKR2015].
c) Should any of the following be expanded or defined? Are these names of
things rather than abbreviations that should be expanded?
Note that these do not appear on our Abbreviations List at
https://www.rfc-editor.org/rpc/wiki/doku.php?id=abbrev_list. Also note that we
do not expand fixed names for things (e.g., algorithms like AES-GCM).
IND-CPA
IND-CTXT
D-LORS-BCPA
B-INT-CTXT
INT-RUP
GCM-RUP
SAEF
CMT
CMT-4
CMT-1
CIL1
CCAL1
CCAmL2
TEDT
MRAE
QCB
AEZ
mu-ind
-->
<!-- [rfced] Lists in Sections 4.4 and Appendix A
a) May we update "Security notion:" to "Security notions:" (plural)
throughout? We see that "Examples:" and "Applications:" are plural.
b) We used newline="true" for these lists; let us know if you would like to
use newline="false" instead.
Example of newline="true":
Definition:
An AEAD algorithm guarantees that the plaintext is not available
to an active, nonce-respecting adversary.
Security notion:
IND-CCA [BN2000] (or IND-CCA2 [S04])
Synonyms:
Message privacy
Example of newline="false":
Definition: An AEAD algorithm allows one to ensure that the
ciphertext and the associated data have not been changed or forged
by an active, nonce-respecting adversary.
Security notion: IND-CTXT [BN2000] (or AUTH [R02])
Synonyms: Message authentication, authenticity
-->
<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers.
Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
-->
</back>
</back>
</rfc> </rfc>
 End of changes. 70 change blocks. 
1927 lines changed or deleted 1811 lines changed or added

This html diff was produced by rfcdiff 1.48.