draft-irtf-cfrg-aead-properties-04.txt | draft-irtf-cfrg-aead-properties-05.txt | |||
---|---|---|---|---|
Crypto Forum A.A. Bozhko, Ed. | Crypto Forum A.A. Bozhko, Ed. | |||
Internet-Draft CryptoPro | Internet-Draft CryptoPro | |||
Intended status: Informational 29 February 2024 | Intended status: Informational 25 March 2024 | |||
Expires: 1 September 2024 | Expires: 26 September 2024 | |||
Properties of AEAD Algorithms | Properties of AEAD Algorithms | |||
draft-irtf-cfrg-aead-properties-04 | draft-irtf-cfrg-aead-properties-05 | |||
Abstract | Abstract | |||
Authenticated Encryption with Associated Data (AEAD) algorithms | Authenticated Encryption with Associated Data (AEAD) algorithms | |||
provide both confidentiality and integrity of data. The widespread | provide both confidentiality and integrity of data. The widespread | |||
use of AEAD algorithms in various applications has led to an | use of AEAD algorithms in various applications has led to an | |||
increased demand for AEAD algorithms with additional properties, | increased demand for AEAD algorithms with additional properties, | |||
driving research in the field. This document provides definitions | driving research in the field. This document provides definitions | |||
for the most common of those properties, aiming to improve | for the most common of those properties, aiming to improve | |||
consistency in the terminology used in documentation. | consistency in the terminology used in documentation. | |||
skipping to change at page 1, line 36 ¶ | skipping to change at page 1, line 36 ¶ | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on 1 September 2024. | This Internet-Draft will expire on 26 September 2024. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2024 IETF Trust and the persons identified as the | Copyright (c) 2024 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents (https://trustee.ietf.org/ | Provisions Relating to IETF Documents (https://trustee.ietf.org/ | |||
license-info) in effect on the date of publication of this document. | license-info) in effect on the date of publication of this document. | |||
Please review these documents carefully, as they describe your rights | Please review these documents carefully, as they describe your rights | |||
skipping to change at page 4, line 35 ¶ | skipping to change at page 4, line 35 ¶ | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
"OPTIONAL" in this document are to be interpreted as described in BCP | "OPTIONAL" in this document are to be interpreted as described in BCP | |||
14 [RFC2119][RFC8174] when, and only when, they appear in all | 14 [RFC2119][RFC8174] when, and only when, they appear in all | |||
capitals, as shown here. | capitals, as shown here. | |||
3. AEAD Algorithms | 3. AEAD Algorithms | |||
This section gives a conventional definition of an AEAD algorithm | This section gives a conventional definition of an AEAD algorithm | |||
following [RFC5116]. | following [RFC5116]. | |||
Definition. An AEAD algorithm is defined by two operations, which | Definition: An AEAD algorithm is defined by two operations, which are | |||
are authenticated encryption and authenticated decryption: | authenticated encryption and authenticated decryption: | |||
* A deterministic operation of authenticated encryption has four | * A deterministic operation of authenticated encryption has four | |||
inputs, each a binary string: a secret key K of a fixed bit | inputs, each a binary string: a secret key K of a fixed bit | |||
length, a nonce N, associated data A, and a plaintext P. The | length, a nonce N, associated data A, and a plaintext P. The | |||
plaintext contains the data to be encrypted and authenticated, and | plaintext contains the data to be encrypted and authenticated, and | |||
the associated data contains the data to be authenticated only. | the associated data contains the data to be authenticated only. | |||
Each nonce value MUST be unique in every distinct invocation of | Each nonce value MUST be unique in every distinct invocation of | |||
the operation for any particular value of the key. The | the operation for any particular value of the key. The | |||
authenticated encryption operation outputs a ciphertext C. | authenticated encryption operation outputs a ciphertext C. | |||
skipping to change at page 5, line 39 ¶ | skipping to change at page 5, line 39 ¶ | |||
4. AEAD Properties | 4. AEAD Properties | |||
4.1. Classification of additional AEAD Properties | 4.1. Classification of additional AEAD Properties | |||
In this document, we employ a high-level classification of additional | In this document, we employ a high-level classification of additional | |||
properties. This classification aims to provide insight into how one | properties. This classification aims to provide insight into how one | |||
can benefit from each property. The additional properties in this | can benefit from each property. The additional properties in this | |||
section are categorized into one of these two groups: | section are categorized into one of these two groups: | |||
* Security properties. We classify a property as a security | * Security properties: We classify a property as a security property | |||
property if it either takes into account new threats or extends | if it either takes into account new threats or extends adversarial | |||
adversarial capabilities, in addition to those posed by the | capabilities, in addition to those posed by the typical nonce- | |||
typical nonce-respecting adversary whose goal is to compromise | respecting adversary whose goal is to compromise confidentiality | |||
confidentiality or data integrity. | or data integrity. | |||
* Implementation properties. We classify a property as an | * Implementation properties: We classify a property as an | |||
implementation property if it enables more efficient | implementation property if it enables more efficient | |||
implementations of the AEAD algorithm in specific cases or | implementations of the AEAD algorithm in specific cases or | |||
environments. | environments. | |||
We note that some additional properties of AEAD algorithms found in | We note that some additional properties of AEAD algorithms found in | |||
the literature could not be allocated to either of these two groups. | the literature could not be allocated to either of these two groups. | |||
The observation is that such properties require an extension of the | The observation is that such properties require an extension of the | |||
conventional AEAD interface. We refer to these properties as | conventional AEAD interface. We refer to these properties as | |||
'additional functionality properties' and define the corresponding | 'additional functionality properties' and define the corresponding | |||
group as follows: | group as follows: | |||
* Additional functionality properties. We classify a property as an | * Additional functionality properties: We classify a property as an | |||
additional functionality property if it introduces new features in | additional functionality property if it introduces new features in | |||
addition to the standard authenticated encryption with associated | addition to the standard authenticated encryption with associated | |||
data. | data. | |||
With the extension of the conventional AEAD interface, each | With the extension of the conventional AEAD interface, each | |||
additional functionality property defines a new class of | additional functionality property defines a new class of | |||
cryptographic algorithms. Consequently, the basic threats and | cryptographic algorithms. Consequently, the basic threats and | |||
adversarial capabilities must be redefined for each class. As a | adversarial capabilities must be redefined for each class. As a | |||
result, additional functionality properties consider the basic | result, additional functionality properties consider the basic | |||
threats and adversarial capabilities for their class of algorithms, | threats and adversarial capabilities for their class of algorithms, | |||
skipping to change at page 6, line 36 ¶ | skipping to change at page 6, line 36 ¶ | |||
In this section, we recall the conventional properties of an AEAD | In this section, we recall the conventional properties of an AEAD | |||
algorithm. Active nonce-respecting adversaries in a single-key | algorithm. Active nonce-respecting adversaries in a single-key | |||
setting are considered. | setting are considered. | |||
We say that an AEAD algorithm provides security if it provides | We say that an AEAD algorithm provides security if it provides | |||
conventional properties listed in this section. | conventional properties listed in this section. | |||
4.2.1. Confidentiality | 4.2.1. Confidentiality | |||
Definition. An AEAD algorithm guarantees that the plaintext is not | Definition: An AEAD algorithm guarantees that the plaintext is not | |||
available to an active, nonce-respecting adversary. | available to an active, nonce-respecting adversary. | |||
Security notion. IND-CCA [BN2000] (or IND-CCA2 [S04]). | Security notion: IND-CCA [BN2000] (or IND-CCA2 [S04]). | |||
Synonyms. Message privacy. | Synonyms: Message privacy. | |||
Note. Confidentiality against passive adversaries can also be | Notes: Confidentiality against passive adversaries can also be | |||
considered. The corresponding security notion is IND-CPA | considered. The corresponding security notion is IND-CPA | |||
[BN2000][R02]. | [BN2000][R02]. | |||
Further reading. [R02], [BN2000], [S04]. | Further reading: [R02], [BN2000], [S04]. | |||
4.2.2. Data Integrity | 4.2.2. Data Integrity | |||
Definition. An AEAD algorithm guarantees that the ciphertext and the | Definition: An AEAD algorithm guarantees that the ciphertext and the | |||
associated data have not been changed or forged by an active, nonce- | associated data have not been changed or forged by an active, nonce- | |||
respecting adversary. | respecting adversary. | |||
Security notion. IND-CTXT [BN2000] (or AUTH [R02]). | Security notion: IND-CTXT [BN2000] (or AUTH [R02]). | |||
Synonyms. Message authentication, authenticity. | Synonyms: Message authentication, authenticity. | |||
Further reading. [R02], [BN2000], [S04]. | Further reading: [R02], [BN2000], [S04]. | |||
4.2.3. Authenticated Encryption Security | 4.2.3. Authenticated Encryption Security | |||
Definition. An AEAD algorithm provides confidentiality and data | Definition: An AEAD algorithm provides confidentiality and data | |||
integrity against active, nonce-respecting adversaries. | integrity against active, nonce-respecting adversaries. | |||
Security notion. IND-CPA and IND-CTXT [BN2000][R02] (or equivalently | Security notion: IND-CPA and IND-CTXT [BN2000][R02] (or equivalently | |||
IND-CCA3 [S04]). | IND-CCA3 [S04]). | |||
Note. Please refer to [I-D.irtf-cfrg-aead-limits] for usage limits | Notes: Please refer to [I-D.irtf-cfrg-aead-limits] for usage limits | |||
on modern AEAD algorithms used in IETF protocols. | on modern AEAD algorithms used in IETF protocols. | |||
Further reading. [R02], [BN2000], [S04]. | Further reading: [R02], [BN2000], [S04]. | |||
4.3. Security Properties | 4.3. Security Properties | |||
4.3.1. Blockwise Security | 4.3.1. Blockwise Security | |||
Definition. An AEAD algorithm provides security even if an adversary | Definition: An AEAD algorithm provides security even if an adversary | |||
can adaptively choose the next part of the plaintext depending on | can adaptively choose the next part of the plaintext depending on | |||
already computed ciphertext parts during an encryption operation. | already computed ciphertext parts during an encryption operation. | |||
Security notion. D-LORS-BCPA for confidentiality against passive | Security notion: D-LORS-BCPA for confidentiality against passive | |||
adversaries, B-INT-CTXT for integrity [EV16]; OAE1 [HRRV15] (stronger | adversaries, B-INT-CTXT for integrity [EV16]; OAE1 [HRRV15] (stronger | |||
notion; originally, OAE in [FFL12]). | notion; originally, OAE in [FFL12]). | |||
Examples. Deoxys [JNPS21], SAEF [ABV21]. | Examples: Deoxys [JNPS21], SAEF [ABV21]. | |||
Notes. Blockwise security is highly relevant for streamable AEAD | Notes: Blockwise security is highly relevant for streamable AEAD | |||
algorithms (see Section 4.4.8). OAE1 (OAE) security notion [HRRV15], | algorithms (see Section 4.4.8). OAE1 (OAE) security notion [HRRV15], | |||
and OAE2 notion [HRRV15] are tailored for streamable AEAD algorithms. | and OAE2 notion [HRRV15] are tailored for streamable AEAD algorithms. | |||
Blockwise security follows from security in the OAE notion [EV16]. | Blockwise security follows from security in the OAE notion [EV16]. | |||
For a discussion on security notions for streamable AEAD algorithms | For a discussion on security notions for streamable AEAD algorithms | |||
see [HRRV15]. | see [HRRV15]. | |||
Applications. Real-time streaming protocols, encryption on resource- | Applications: Real-time streaming protocols, encryption on resource- | |||
constrained devices. | constrained devices. | |||
Further reading. [EV16], [JMV2002], [FJMV2004], [HRRV15] | Further reading: [EV16], [JMV2002], [FJMV2004], [HRRV15]. | |||
4.3.2. Full Commitment | 4.3.2. Full Commitment | |||
Definition. An AEAD algorithm guarantees that it is hard to find two | Definition: An AEAD algorithm guarantees that it is hard to find two | |||
or more different tuples of the key, nonce, associated data, and | or more different tuples of the key, nonce, associated data, and | |||
plaintext such that they encrypt to the same ciphertext. In other | plaintext such that they encrypt to the same ciphertext. In other | |||
words, an AEAD scheme guarantees that a ciphertext is a commitment to | words, an AEAD scheme guarantees that a ciphertext is a commitment to | |||
all inputs of an authenticated encryption operation. | all inputs of an authenticated encryption operation. | |||
Security notion. CMT-4 [BH22], generalized CMT for a restricted | Security notion: CMT-4 [BH22], generalized CMT for a restricted | |||
setting (see the notes below) [MLGR23]. | setting (see the notes below) [MLGR23]. | |||
Examples. Ascon [DEMS21a][DEMS21b][YSS23], full commiting versions | Examples: Ascon [DEMS21a][DEMS21b][YSS23], full commiting versions of | |||
of GCM and GCM-SIV [BH22], generic constructions [BH22][CR22]. | GCM and GCM-SIV [BH22], generic constructions [BH22][CR22]. | |||
Notes. Full commitment can be considered in a weaker setting, where | Notes: Full commitment can be considered in a weaker setting, where | |||
certain restrictions on the tuples produced by an adversary are | certain restrictions on the tuples produced by an adversary are | |||
imposed [MLGR23]. For instance, an adversary must find tuples that | imposed [MLGR23]. For instance, an adversary must find tuples that | |||
all share the same associated data value. In such cases, an AEAD | all share the same associated data value. In such cases, an AEAD | |||
algorithm is said to provide full commitment in a restricted setting. | algorithm is said to provide full commitment in a restricted setting. | |||
The imposed restrictions MUST be listed. | The imposed restrictions MUST be listed. | |||
Applications. Message franking [GLR17]. | Applications: Message franking [GLR17]. | |||
Further reading. [BH22], [CR22], [MLGR23]. | Further reading: [BH22], [CR22], [MLGR23]. | |||
4.3.3. Key Commitment | 4.3.3. Key Commitment | |||
Definition. An AEAD algorithm guarantees that it is hard to find two | Definition: An AEAD algorithm guarantees that it is hard to find two | |||
or more different keys and the same number of potentially equal | or more different keys and the same number of potentially equal | |||
triples of nonce, associated data, and plaintext such that they | triples of nonce, associated data, and plaintext such that they | |||
encrypt to the same ciphertext under corresponding keys. In other | encrypt to the same ciphertext under corresponding keys. In other | |||
words, an AEAD scheme guarantees that a ciphertext is a commitment to | words, an AEAD scheme guarantees that a ciphertext is a commitment to | |||
the key used for an authenticated encryption operation. | the key used for an authenticated encryption operation. | |||
Security notion. CMT-1 [BH22]. | Security notion: CMT-1 [BH22]. | |||
Synonyms. Key-robustness, key collision resistance. | Synonyms: Key-robustness, key collision resistance. | |||
Examples. Ascon [DEMS21a][DEMS21b][YSS23], generic constructions | Examples: Ascon [DEMS21a][DEMS21b][YSS23], generic constructions from | |||
from [BH22],[CR22]. | [BH22] [CR22]. | |||
Notes. Key commitment follows from full commitment. Full commitment | Notes: Key commitment follows from full commitment. Full commitment | |||
does not follow from key commitment [BH22]. | does not follow from key commitment [BH22]. | |||
Applications. Password-Authenticated Key Exchange, password-based | Applications: Password-Authenticated Key Exchange, password-based | |||
encryption [LGR21], key rotation, envelope encryption [ADGKLS22]. | encryption [LGR21], key rotation, envelope encryption [ADGKLS22]. | |||
Further reading. [BH22],[CR22], [FOR17], [LGR21], [GLR17]. | Further reading: [BH22],[CR22], [FOR17], [LGR21], [GLR17]. | |||
4.3.4. Leakage Resistance | 4.3.4. Leakage Resistance | |||
Definition. An AEAD algorithm provides security even if some | Definition: An AEAD algorithm provides security even if some | |||
additional information about computations of an encryption (and | additional information about computations of an encryption (and | |||
possibly decryption) operation is obtained via side-channel leakages. | possibly decryption) operation is obtained via side-channel leakages. | |||
Security notion. CIL1 [GPPS19] (CIML2 [BPPS17] with leakages in | Security notion: CIL1 [GPPS19] (CIML2 [BPPS17] with leakages in | |||
decryption) for integrity, CCAL1 [GPPS19] (CCAmL2 [GPPS19] with | decryption) for integrity, CCAL1 [GPPS19] (CCAmL2 [GPPS19] with | |||
leakages in decryption) for Authenticated Encryption security. | leakages in decryption) for Authenticated Encryption security. | |||
Examples. Ascon [DEMS21a][DEMS21b] (integrity with leakages in both | Examples: Ascon [DEMS21a][DEMS21b] (security under CIML2 and CCAL1 | |||
encryption and decryption operations, confidentiality with leakages | notions [B20]), TEDT [GPPS19]. | |||
in encryption), TEDT [GPPS19]. | ||||
Leakages during AEAD operation executions are implementation- | Notes: Leakages during AEAD operation executions are implementation- | |||
dependent. It is possible to implement symmetric algorithms in a way | dependent. It is possible to implement symmetric algorithms in a way | |||
that every possible physical leakage is entirely independent of the | that every possible physical leakage is entirely independent of the | |||
secret inputs of the algorithm (for example, with a masking technique | secret inputs of the algorithm (for example, with a masking technique | |||
[CJRR99]), meaning the adversary doesn't gain any additional | [CJRR99]), meaning the adversary doesn't gain any additional | |||
information about the algorithm's computation via side-channel | information about the algorithm's computation via side-channel | |||
leakages. We say that an AEAD algorithm doesn't provide leakage | leakages. We say that an AEAD algorithm doesn't provide leakage | |||
resistance if it can achieve leakage resistance only with such an | resistance if it can achieve leakage resistance only with such an | |||
implementation. Leakage-resistant AEAD algorithms aim to place as | implementation. Leakage-resistant AEAD algorithms aim to place as | |||
mild requirements on implementation as possible to achieve leakage | mild requirements on implementation as possible to achieve leakage | |||
resistance. These requirements SHOULD be listed. | resistance. These requirements SHOULD be listed. | |||
skipping to change at page 9, line 49 ¶ | skipping to change at page 9, line 48 ¶ | |||
For primitive-based AEAD algorithms, key evolution (internal re- | For primitive-based AEAD algorithms, key evolution (internal re- | |||
keying [RFC8645]) can contribute to achieving leakage resistance with | keying [RFC8645]) can contribute to achieving leakage resistance with | |||
leakages in encryption. Confidentiality in the presence of | leakages in encryption. Confidentiality in the presence of | |||
decryption leakages can be achieved by two-pass AEAD algorithms with | decryption leakages can be achieved by two-pass AEAD algorithms with | |||
key evolution, which compute independent ephemeral key values for | key evolution, which compute independent ephemeral key values for | |||
encryption and tag generation, where the computation of these keys is | encryption and tag generation, where the computation of these keys is | |||
implemented without any leakages. For more discussions on achieving | implemented without any leakages. For more discussions on achieving | |||
leakage resistance see [B20]. | leakage resistance see [B20]. | |||
Applications. Encryption on smart cards, Internet-of-things devices, | Applications: Encryption on smart cards, Internet-of-things devices, | |||
or other constrained devices. | or other constrained devices. | |||
Further reading. [GPPS19], [B20], [BPPS17]. | Further reading: [GPPS19], [B20], [BPPS17]. | |||
4.3.5. Multi-User Security | 4.3.5. Multi-User Security | |||
Definition. An AEAD algorithm security degrades slower than linearly | Definition: An AEAD algorithm security degrades slower than linearly | |||
with an increase in the number of users. | with an increase in the number of users. | |||
Security notion. mu-ind [BT16]. | Security notion: mu-ind [BT16]. | |||
Examples. AES-GCM [D07], ChaCha20-Poly1305 [RFC8439], AES-GCM-SIV | Examples: AES-GCM [D07], ChaCha20-Poly1305 [RFC8439], AES-GCM-SIV | |||
[RFC8452], AEGIS [I-D.irtf-cfrg-aegis-aead]. | [RFC8452], AEGIS [I-D.irtf-cfrg-aegis-aead]. | |||
Notes. It holds that for any AEAD algorithm security degrades no | Notes: It holds that for any AEAD algorithm security degrades no | |||
worse than linearly with an increase in the number of users. | worse than linearly with an increase in the number of users [BT16]. | |||
However, for some applications with a significant number of users, | However, for some applications with a significant number of users, | |||
better multi-user guarantees are required. For example, in the TLS | better multi-user guarantees are required. For example, in the TLS | |||
1.3 protocol, to address this issue, AEAD algorithms are used with a | 1.3 protocol, to address this issue, AEAD algorithms are used with a | |||
randomized nonce (deterministically derived from a traffic secret and | randomized nonce (deterministically derived from a traffic secret and | |||
a sequence number). Using nonce randomization in block cipher | a sequence number). Using nonce randomization in block cipher | |||
counter-based AEAD modes can contribute to multi-user security | counter-based AEAD modes can contribute to multi-user security | |||
[BT16]. Multi-user usage limits for AES-GCM and ChaCha20-Poly1305 | [BT16]. Multi-user usage limits for AES-GCM and ChaCha20-Poly1305 | |||
are provided in [I-D.irtf-cfrg-aead-limits]. | are provided in [I-D.irtf-cfrg-aead-limits]. | |||
Applications. Data transmission layer of secure communication | Applications: Data transmission layer of secure communication | |||
protocols (e.g., TLS, IPSec, SRTP, etc.) | protocols (e.g., TLS, IPSec, SRTP, etc.) | |||
Further reading. [BT16], [HTT18], [LMP17],[DGGP21], [BHT18]. | Further reading: [BT16], [HTT18], [LMP17], [DGGP21], [BHT18]. | |||
4.3.6. Nonce-Hiding | 4.3.6. Nonce-Hiding | |||
Definition. An AEAD algorithm provides confidentiality for the nonce | Definition: An AEAD algorithm provides confidentiality for the nonce | |||
value used to encrypt plaintext. The algorithm includes information | value used to encrypt plaintext. The algorithm includes information | |||
about the nonce in the ciphertext and doesn't require the nonce as | about the nonce in the ciphertext and doesn't require the nonce as | |||
input for the decryption operation. | input for the decryption operation. | |||
Security notion. AE2 [BNT19]. | Security notion: AE2 [BNT19]. | |||
Example. Hide-Nonce (HN) transforms [BNT19]. | Examples: Hide-Nonce (HN) transforms [BNT19]. | |||
Notes. As discussed in [BNT19], adversary-visible nonces might | Notes: As discussed in [BNT19], adversary-visible nonces might | |||
compromise message and user privacy, similar to the way any metadata | compromise message and user privacy, similar to the way any metadata | |||
might do. As pointed out in [B13], even using a counter as a nonce | might do. As pointed out in [B13], even using a counter as a nonce | |||
value might compromise privacy. Designing a privacy-preserving way | value might compromise privacy. Designing a privacy-preserving way | |||
to manage nonces might be a challenging problem for an application. | to manage nonces might be a challenging problem for an application. | |||
Applications. Any application that can't rely on a secure 'out-of- | Applications: Any application that can't rely on a secure 'out-of- | |||
band' nonce communication. | band' nonce communication. | |||
Further reading. [BNT19]. | Further reading: [BNT19]. | |||
4.3.7. Nonce Misuse | 4.3.7. Nonce Misuse | |||
Definition. An AEAD algorithm provides security (resilience or | Definition: An AEAD algorithm provides security (resilience or | |||
resistance) even if an adversary can repeat nonces in its encryption | resistance) even if an adversary can repeat nonces in its encryption | |||
queries. Nonce misuse resilience and resistance are defined as | queries. Nonce misuse resilience and resistance are defined as | |||
follows: | follows: | |||
* Nonce misuse resilience. Security is provided only for messages | * Nonce misuse resilience: Security is provided only for messages | |||
encrypted with fresh nonces (correctly encrypted messages). | encrypted with fresh nonces (correctly encrypted messages). | |||
Security notion. CPA resilience (confidentiality), authenticity | Security notion: CPA resilience (confidentiality), authenticity | |||
resilience (integrity), CCA resilience (authenticated encryption) | resilience (integrity), CCA resilience (authenticated encryption) | |||
[ADL17]. | [ADL17]. | |||
Examples. ChaCha20-Poly1305 [RFC8439], AES-GCM [D07] (only | Examples: ChaCha20-Poly1305 [RFC8439], AES-GCM [D07] (only | |||
confidentiality). | confidentiality). | |||
* Nonce misuse resistance. Security is provided for all messages | * Nonce misuse resistance: Security is provided for all messages | |||
that were not encrypted with the same nonce value more than once. | that were not encrypted with the same nonce value more than once. | |||
Security notion. MRAE [RS06]. | Security notion: MRAE [RS06]. | |||
Examples. AES-GCM-SIV [RFC8452], Deoxys-II [JNPS21]. | Examples: AES-GCM-SIV [RFC8452], Deoxys-II [JNPS21]. | |||
Notes. SIV construction [RS06] is a generic construction that | Notes: SIV construction [RS06] is a generic construction that | |||
provides nonce misuse resistance. | provides nonce misuse resistance. | |||
Notes. Nonce misuse resilience follows from nonce misuse resistance. | Notes: Nonce misuse resilience follows from nonce misuse resistance. | |||
Nonce misuse resistance does not follow from nonce misuse resilience. | Nonce misuse resistance does not follow from nonce misuse resilience. | |||
Applications. Any application where nonce uniqueness can't be | Applications: Any application where nonce uniqueness can't be | |||
guaranteed, security against fault-injection attacks and | guaranteed, security against fault-injection attacks and | |||
malfunctions, processes parallelization, full disk encryption. | malfunctions, processes parallelization, full disk encryption. | |||
Further reading. [RS06], [ADL17] | Further reading: [RS06], [ADL17]. | |||
4.3.8. Quantum Security | 4.3.8. Quantum Security | |||
Definition. An AEAD algorithm provides security (in a Q1 or Q2 | Definition: An AEAD algorithm provides security (in a Q1 or Q2 model) | |||
model) against a quantum adversary. Q1 and Q2 models are defined as | against a quantum adversary. Q1 and Q2 models are defined as | |||
follows: | follows: | |||
* Q1 model. An adversary has access to local quantum computational | * Q1 model: An adversary has access to local quantum computational | |||
power. It has classical access to encryption and decryption | power. It has classical access to encryption and decryption | |||
oracles. | oracles. | |||
Synonyms. Post-quantum security. | Synonyms: Post-quantum security. | |||
Examples. AES-GCM [D07], ChaCha20-Poly1305 [RFC8439], OCB | Examples: AES-GCM [D07], ChaCha20-Poly1305 [RFC8439], OCB | |||
[RFC7253], MGM [RFC9058], AES-GCM-SIV [RFC8452], AEGIS | [RFC7253], MGM [RFC9058], AES-GCM-SIV [RFC8452], AEGIS | |||
[I-D.irtf-cfrg-aegis-aead]. | [I-D.irtf-cfrg-aegis-aead]. | |||
* Q2 model. An adversary has access to local quantum computational | * Q2 model: An adversary has access to local quantum computational | |||
power. It has quantum access to encryption and decryption | power. It has quantum access to encryption and decryption | |||
oracles; it can query encryption and decryption oracles with | oracles, i.e, it can query encryption and decryption oracles with | |||
quantum superpositions of inputs to receive quantum superpositions | quantum superpositions of inputs to receive quantum superpositions | |||
of the outputs. | of the outputs. | |||
Synonyms. Superposition-based quantum security. | Synonyms: Superposition-based quantum security. | |||
Examples. QCB [BBCLNSS21]. | Examples: QCB [BBCLNSS21]. | |||
Notes. Most symmetric cryptographic algorithms that are secure in | Notes: Most symmetric cryptographic algorithms that are secure in the | |||
the classical model provide quantum security in the Q1 model, i.e., | classical model provide quantum security in the Q1 model, i.e., they | |||
they are post-quantum secure. Security in the Q1 setting corresponds | are post-quantum secure. Security in the Q1 setting corresponds to | |||
to security against "harvest now, decrypt later" attacks. Security | security against "harvest now, decrypt later" attacks. Security in | |||
in the Q2 model is considered stronger, security in Q1 follows from | Q1 follows from security in Q2, the converse does not hold. For | |||
security in Q2. For discussions on the relevance of the Q2 model | discussions on the relevance of the Q2 model please see [G17]. | |||
please see [G17]. | ||||
Further reading. [KLLNP16], [BBCLNSS21], [G17]. | Further reading: [KLLNP16], [BBCLNSS21], [G17]. | |||
4.3.9. Reforgeability Resilience | 4.3.9. Reforgeability Resilience | |||
Definition. An AEAD algorithm guarantees that once a successful | Definition: An AEAD algorithm guarantees that once a successful | |||
forgery for the algorithm has been found, it is still hard to find | forgery for the algorithm has been found, it is still hard to find | |||
any subsequent forgery. | any subsequent forgery. | |||
Security notion. j-Int-CTXT [FLLW17]. | Security notion: j-Int-CTXT [FLLW17]. | |||
Examples. Deoxys [JNPS21], AEGIS [I-D.irtf-cfrg-aegis-aead], Ascon | Examples: Deoxys [JNPS21], AEGIS [I-D.irtf-cfrg-aegis-aead], Ascon | |||
[DEMS21a][DEMS21b]. | [DEMS21a][DEMS21b]. | |||
Applications. VoIP, real-time streaming in a lightweight setting, | Applications: VoIP, real-time streaming in a lightweight setting, | |||
applications that require small ciphertext expansion (i.e., short | applications that require small ciphertext expansion (i.e., short | |||
tags). | tags). | |||
Further reading. [BC09], [FLLW17]. | Further reading: [BC09], [FLLW17]. | |||
4.3.10. Release of Unverified Plaintext (RUP) Integrity | 4.3.10. Release of Unverified Plaintext (RUP) Integrity | |||
Definition. An AEAD algorithm provides data integrity even if | Definition: An AEAD algorithm provides data integrity even if | |||
plaintext is released for every ciphertext, including those with | plaintext is released for every ciphertext, including those with | |||
failed integrity verification. | failed integrity verification. | |||
Security notion. INT-RUP [A14]. | Security notion: INT-RUP [A14]. | |||
Example. GCM-RUP [ADL17]. | Examples: GCM-RUP [ADL17]. | |||
Applications. Decryption with limited memory [FJMV2004], real-time | Applications: Decryption with limited memory [FJMV2004], real-time | |||
streaming protocols. | streaming protocols. | |||
Notes. In [ADL17] a generic approach to achieve INT-RUP security is | Notes: In [ADL17] a generic approach to achieve INT-RUP security is | |||
introduced. | introduced. | |||
In the provided definition, we only consider integrity in the RUP | In the provided definition, we only consider integrity in the RUP | |||
setting, since confidentiality, in the usual sense, is unachievable | setting, since confidentiality, in the usual sense, is unachievable | |||
under RUP. In [A14], the notion of 'Plaintext Awareness' is | under RUP. In [A14], the notion of 'Plaintext Awareness' is | |||
introduced, capturing the best possible confidentiality under RUP in | introduced, capturing the best possible confidentiality under RUP in | |||
the following sense: 'The adversary cannot gain any additional | the following sense: 'The adversary cannot gain any additional | |||
knowledge about the plaintext from decryption queries beyond what it | knowledge about the plaintext from decryption queries beyond what it | |||
can derive from encryption queries'. | can derive from encryption queries'. | |||
Further reading. [A14], [ADL17]. | Further reading: [A14], [ADL17]. | |||
4.4. Implementation Properties | 4.4. Implementation Properties | |||
4.4.1. Hardware efficient | 4.4.1. Hardware efficient | |||
Definition. An AEAD algorithm ensures optimal performance when | Definition: An AEAD algorithm ensures optimal performance when | |||
operating on hardware that complies with the specified requirements. | operating on hardware that complies with the specified requirements. | |||
Notes. Various classes of hardware may be taken into consideration. | Notes: Various classes of hardware may be taken into consideration. | |||
Certain algorithms are tailored to minimize the area of dedicated | Certain algorithms are tailored to minimize the area of dedicated | |||
hardware implementations, while others are intended to capitalize on | hardware implementations, while others are intended to capitalize on | |||
general-purpose CPUs, with or without specific instruction sets. It | general-purpose CPUs, with or without specific instruction sets. It | |||
is RECOMMENDED to specify the minimum platform requirements for the | is RECOMMENDED to specify the minimum platform requirements for the | |||
AEAD to fulfill its intended purpose, as well as to match its | AEAD to fulfill its intended purpose, as well as to match its | |||
performance and security claims. | performance and security claims. | |||
4.4.2. Inverse-Free | 4.4.2. Inverse-Free | |||
Definition. An AEAD algorithm that is based on some primitive can be | Definition: An AEAD algorithm that is based on some primitive can be | |||
implemented without evaluating the inverse of that primitive. | implemented without evaluating the inverse of that primitive. | |||
Examples. AES-GCM [D07], ChaCha20-Poly1305 [RFC8439], OCB [RFC7253], | Examples: AES-GCM [D07], ChaCha20-Poly1305 [RFC8439], OCB [RFC7253], | |||
MGM [RFC9058], AEGIS [I-D.irtf-cfrg-aegis-aead]. | MGM [RFC9058], AEGIS [I-D.irtf-cfrg-aegis-aead]. | |||
Notes. In a sponge-based AEAD algorithm, an underlying permutation | Notes: In a sponge-based AEAD algorithm, an underlying permutation is | |||
is viewed as a primitive. | viewed as a primitive. | |||
4.4.3. Lightweight | 4.4.3. Lightweight | |||
Definition. An AEAD algorithm can be efficiently and securely | Definition: An AEAD algorithm can be efficiently and securely | |||
implemented on resource-constrained devices. In particular, it meets | implemented on resource-constrained devices. In particular, it meets | |||
the criteria required in the NIST Lightweight Cryptography | the criteria required in the NIST Lightweight Cryptography | |||
competition [MBTM17]. | competition [MBTM17]. | |||
Examples. OCB [RFC7253], Ascon [DEMS21a][DEMS21b]. | Examples: OCB [RFC7253], Ascon [DEMS21a][DEMS21b]. | |||
Further reading. [MBTM17]. | Further reading: [MBTM17]. | |||
4.4.4. Parallelizable | 4.4.4. Parallelizable | |||
Definition. An AEAD algorithm can fully exploit the parallel | Definition: An AEAD algorithm can fully exploit the parallel | |||
computation infrastructure. In other words, a parallelizable AEAD | computation infrastructure. In other words, a parallelizable AEAD | |||
algorithm allows for the computation of ciphertext segments | algorithm allows for the computation of ciphertext segments | |||
(plaintext segments for decryption) in parallel, meaning that | (plaintext segments for decryption) in parallel, meaning that | |||
ciphertext segments are computed independently. | ciphertext segments are computed independently. | |||
Synonyms. Pipelineable. | Synonyms: Pipelineable. | |||
Examples. AES-GCM [D07], ChaCha20-Poly1305 [RFC8439], OCB [RFC7253], | Examples: AES-GCM [D07], ChaCha20-Poly1305 [RFC8439], OCB [RFC7253], | |||
MGM [RFC9058], AEGIS [I-D.irtf-cfrg-aegis-aead]. | MGM [RFC9058], AEGIS [I-D.irtf-cfrg-aegis-aead]. | |||
Further reading. [C20]. | Further reading: [C20]. | |||
4.4.5. Setup-Free | 4.4.5. Setup-Free | |||
Definition. An AEAD algorithm's operations can be implemented in a | Definition: An AEAD algorithm's operations can be implemented in a | |||
way that using a new key incurs either no overhead or negligible | way that using a new key incurs either no overhead or negligible | |||
overhead compared to the reuse of a previous key. Overhead may | overhead compared to the reuse of a previous key. Overhead may | |||
involve additional computations or increased storage space, such as | involve additional computations or increased storage space, such as | |||
precomputing a key schedule for a block cipher. | precomputing a key schedule for a block cipher. | |||
Examples. ChaCha20-Poly1305 [RFC8439], AEGIS | Examples: ChaCha20-Poly1305 [RFC8439], AEGIS | |||
[I-D.irtf-cfrg-aegis-aead], Ascon [DEMS21a][DEMS21b]. | [I-D.irtf-cfrg-aegis-aead], Ascon [DEMS21a][DEMS21b]. | |||
4.4.6. Single Pass | 4.4.6. Single Pass | |||
Definition. An AEAD algorithm encryption (decryption) operation can | Definition: An AEAD algorithm encryption (decryption) operation can | |||
be implemented with a single pass over the plaintext (ciphertext). | be implemented with a single pass over the plaintext (ciphertext). | |||
Examples. AES-GCM [D07], ChaCha20-Poly1305 [RFC8439], OCB [RFC7253], | Examples: AES-GCM [D07], ChaCha20-Poly1305 [RFC8439], OCB [RFC7253], | |||
MGM [RFC9058], AEGIS [I-D.irtf-cfrg-aegis-aead]. | MGM [RFC9058], AEGIS [I-D.irtf-cfrg-aegis-aead]. | |||
4.4.7. Static Associated Data Efficient | 4.4.7. Static Associated Data Efficient | |||
Definition. An AEAD algorithm allows pre-computation for static (or | Definition: An AEAD algorithm allows pre-computation for static (or | |||
repeating) associated data so that static associated data doesn't | repeating) associated data so that static associated data doesn't | |||
significantly contribute to the computational cost of encryption. | significantly contribute to the computational cost of encryption. | |||
Examples. AES-GCM [D07], ChaCha20-Poly1305 [RFC8439], OCB [RFC7253]. | Examples: AES-GCM [D07], ChaCha20-Poly1305 [RFC8439], OCB [RFC7253]. | |||
4.4.8. Streamable | 4.4.8. Streamable | |||
Definition. An AEAD algorithm encryption (decryption) operation can | Definition: An AEAD algorithm encryption (decryption) operation can | |||
be implemented with constant memory usage and a single one-direction | be implemented with constant memory usage and a single one-direction | |||
pass over the plaintext (ciphertext), writing out the result during | pass over the plaintext (ciphertext), writing out the result during | |||
that pass. | that pass. | |||
Synonyms. Online. | Synonyms: Online. | |||
Examples. AES-GCM [D07], ChaCha20-Poly1305 [RFC8439], OCB [RFC7253], | Examples: AES-GCM [D07], ChaCha20-Poly1305 [RFC8439], OCB [RFC7253], | |||
MGM [RFC9058], AEGIS [I-D.irtf-cfrg-aegis-aead], Ascon | MGM [RFC9058], AEGIS [I-D.irtf-cfrg-aegis-aead], Ascon | |||
[DEMS21a][DEMS21b]. | [DEMS21a][DEMS21b]. | |||
Applications. Real-time streaming protocols, resource-constrained | Applications: Real-time streaming protocols, resource-constrained | |||
devices. | devices. | |||
Notes. Blockwise security (see Section 4.3.1) might be a relevant | Notes: Blockwise security (see Section 4.3.1) and RUP integrity (see | |||
security property for streamable AEAD algorithms in certain | Section 4.3.10) might be relevant security properties for streamable | |||
applications. | AEAD algorithms in certain applications. | |||
Further reading. [HRRV15], [FJMV2004]. | Further reading: [HRRV15], [FJMV2004]. | |||
5. Security Considerations | 5. Security Considerations | |||
This document gives high-level definitions of AEAD properties. For | This document gives high-level definitions of AEAD properties. For | |||
each security property, we provide an informational reference to a | each security property, we provide an informational reference to a | |||
game-based security notion (or security notions if there are separate | game-based security notion (or security notions if there are separate | |||
notions for integrity and confidentiality) that formalizes the | notions for integrity and confidentiality) that formalizes the | |||
property. We only consider game-based notions and security | property. We only consider game-based notions and security | |||
properties that can be formalized using this approach. However, | properties that can be formalized using this approach. However, | |||
there are different approaches to formalizing AEAD security, like the | there are different approaches to formalizing AEAD security, like the | |||
indifferentiability framework [BM18]; security in such notions should | indifferentiability framework [BM18]; security in such notions should | |||
be studied separately. | be studied separately. | |||
For some properties, examples of AEAD algorithms that provide them | ||||
are given, with standardized AEAD algorithms preferred for commonly | ||||
encountered properties. However, for certain properties, only non- | ||||
standardized algorithms exist. Implementing such algorithms requires | ||||
careful consideration, and it is advised to contact the algorithm | ||||
designers for reference implementations and implementation | ||||
guidelines. | ||||
Every claimed security property of an AEAD algorithm MUST undergo | Every claimed security property of an AEAD algorithm MUST undergo | |||
security analysis within a relevant notion. It’s RECOMMENDED to use | security analysis within a relevant notion. It’s RECOMMENDED to use | |||
the security notions referenced in the document. If an alternative | the security notions referenced in the document. If an alternative | |||
notion is used, there MUST exist proof of equivalence or it SHOULD be | notion is used, there MUST exist proof of equivalence or it SHOULD be | |||
indicated that a non-equivalent notion is used. For security | indicated that a non-equivalent notion is used. For security | |||
properties that extend adversarial capabilities, consideration of | properties that extend adversarial capabilities, consideration of | |||
integrity and confidentiality separately may be relevant. If the | integrity and confidentiality separately may be relevant. If the | |||
algorithm provides only one of these, that SHOULD be indicated. | algorithm provides only one of these, that SHOULD be indicated. | |||
When specifying security requirements for an AEAD algorithm in an | When specifying security requirements for an AEAD algorithm in an | |||
application, it SHOULD be indicated, for every required security | application, it SHOULD be indicated, for every required security | |||
property, whether only integrity or confidentiality is necessary. | property, whether only integrity or confidentiality is necessary. | |||
Additionally, for each security property, it SHOULD be specified | Additionally, for each security property, it SHOULD be specified | |||
whether an analysis in an alternative security notion is required. | whether an analysis in an alternative security notion is required. | |||
We also note that some additional properties come with trade-offs in | ||||
For some properties, examples of AEAD algorithms that provide them | terms of classical security and efficiency, and may only be supported | |||
are given, with standardized AEAD algorithms preferred for commonly | in non-standardized or modified AEAD algorithms. This immediately | |||
encountered properties. However, for certain properties, only non- | implies challenges in deployment and interoperability. In an | |||
standardized algorithms exist. Implementing such algorithms requires | application, the requirements for additional AEAD properties SHOULD | |||
careful consideration, and it is advised to contact the algorithm | be highly motivated and justified, as SHOULD all trade-offs be | |||
designers for reference implementations and implementation | carefully considered. | |||
guidelines. | ||||
6. IANA Considerations | 6. IANA Considerations | |||
This document has no IANA actions. | This document has no IANA actions. | |||
7. References | 7. References | |||
7.1. Normative References | 7.1. Normative References | |||
[D07] Dworkin, M., "Recommendation for Block Cipher Modes of | [D07] Dworkin, M., "Recommendation for Block Cipher Modes of | |||
skipping to change at page 25, line 30 ¶ | skipping to change at page 25, line 43 ¶ | |||
(or insecure) Additional Functionality AEAD. Only security in the | (or insecure) Additional Functionality AEAD. Only security in the | |||
sense of the redefined conventional properties would suffice. | sense of the redefined conventional properties would suffice. | |||
For the examples given in this section, we leave it out of scope how | For the examples given in this section, we leave it out of scope how | |||
to concretely redefine conventional security for these classes; we | to concretely redefine conventional security for these classes; we | |||
only briefly describe the additional functionality they offer and | only briefly describe the additional functionality they offer and | |||
provide further references. | provide further references. | |||
A.1. Incremental Authenticated Encryption | A.1. Incremental Authenticated Encryption | |||
Definition. An AEAD algorithm allows re-encrypting and | Definition: An AEAD algorithm allows re-encrypting and authenticating | |||
authenticating a message (associated data and a plaintext pair), | a message (associated data and a plaintext pair), which only partly | |||
which only partly differs from some previous message, faster than | differs from some previous message, faster than processing it from | |||
processing it from scratch. | scratch. | |||
Example. Incremental AEAD algorithm of [SY16]. | Examples: Incremental AEAD algorithm of [SY16]. | |||
Security notion. Privacy, Authenticity [SY16]. | Security notion: Privacy, Authenticity [SY16]. | |||
Note. The interface of an incremental AEAD algorithm is usually | Notes: The interface of an incremental AEAD algorithm is usually | |||
expanded, when compared with conventional AEAD, with several | expanded, when compared with conventional AEAD, with several | |||
operations, which perform different types of updates. For example, | operations, which perform different types of updates. For example, | |||
one can consider such operations as "Append" or "Chop", which provide | one can consider such operations as "Append" or "Chop", which provide | |||
a straightforward additional functionality. A comprehensive | a straightforward additional functionality. A comprehensive | |||
definition of an incremental AEAD interface is provided in [SY16]. | definition of an incremental AEAD interface is provided in [SY16]. | |||
Further reading. [SY16], [M05], [BKY02]. | Further reading: [SY16], [M05], [BKY02]. | |||
A.2. Robust Authenticated Encryption | A.2. Robust Authenticated Encryption | |||
Definition. An AEAD algorithm allows users to choose a desired | Definition: An AEAD algorithm allows users to choose a desired | |||
ciphertext expansion (the difference between the length of plaintext | ciphertext expansion (the difference between the length of plaintext | |||
and corresponding ciphertext) along with an input to the encryption | and corresponding ciphertext) along with an input to the encryption | |||
operation. This feature enables the regulation of desired data | operation. This feature enables the regulation of desired data | |||
integrity guarantees, which depend on ciphertext expansion, for each | integrity guarantees, which depend on ciphertext expansion, for each | |||
particular application while using the same algorithm implementation. | particular application while using the same algorithm implementation. | |||
Examples. AEZ [HKR2015]. | Examples: AEZ [HKR2015]. | |||
Security notion. RAE [HKR2015]. | Security notion: RAE [HKR2015]. | |||
Note. The security goal of robust AEAD algorithms is to ensure the | Notes: The security goal of robust AEAD algorithms is to ensure the | |||
best possible security, even with small ciphertext expansion | best possible security, even with small ciphertext expansion | |||
(referred to as stretch). For instance, analyzing any AEAD algorithm | (referred to as stretch). For instance, analyzing any AEAD algorithm | |||
with a one-byte stretch for conventional integrity reveals | with a one-byte stretch for conventional integrity reveals | |||
insecurity, as the probability of forging a ciphertext is no less | insecurity, as the probability of forging a ciphertext is no less | |||
than 1/256. Nonetheless, from the robust AEAD perspective, an | than 1/256. Nonetheless, from the robust AEAD perspective, an | |||
algorithm with such forgery probability for a one-byte ciphertext | algorithm with such forgery probability for a one-byte ciphertext | |||
expansion is secure, representing the best achievable security in | expansion is secure, representing the best achievable security in | |||
that scenario. | that scenario. | |||
Further reading. [HKR2015] | Further reading: [HKR2015]. | |||
Acknowledgments | Acknowledgments | |||
This document benefited greatly from the comments received from the | This document benefited greatly from the comments received from the | |||
CFRG community, for which we are very grateful. We would also like | CFRG community, for which we are very grateful. We would also like | |||
to extend special appreciation to Liliya Akhmetzyanova, Evgeny | to extend special appreciation to Liliya Akhmetzyanova, Evgeny | |||
Alekseev, Alexandra Babueva, Frank Denis, Kirill Kutsenok, Sergey | Alekseev, Alexandra Babueva, Frank Denis, Kirill Kutsenok, Sergey | |||
Kyazhin, Samuel Lucas, Grigory Marshalko, Christopher Patton, and | Kyazhin, Samuel Lucas, Grigory Marshalko, Christopher Patton, and | |||
Christopher Wood for their thoughtful comments, proposals, and | Christopher Wood for their thoughtful comments, proposals, and | |||
discussions. | discussions. | |||
End of changes. 125 change blocks. | ||||
155 lines changed or deleted | 160 lines changed or added | |||
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |