Internet Research Task Force (IRTF) A. Bozhko, Ed.
Request for Comments: 9771 CryptoPro
Category: Informational May 2025
ISSN: 2070-1721
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.
関連するデータ（AEAD）アルゴリズムを使用した認証された暗号化は、データの機密性と整合性の両方を提供します。さまざまなアプリケーションでのAEADアルゴリズムの広範な使用により、追加のプロパティを備えたAEADアルゴリズムの需要が増加し、フィールドでの研究が促進されました。このドキュメントは、これらのプロパティの中で最も一般的なものの定義を提供し、ドキュメントで使用される用語の一貫性を改善することを目的としています。このドキュメントは、Crypto Forum Research Groupの製品です。
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the consensus of the Crypto Forum Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、インターネット研究タスクフォース（IRTF）の製品です。IRTFは、インターネット関連の研究開発活動の結果を公開しています。これらの結果は、展開に適していない場合があります。このRFCは、インターネット研究タスクフォース（IRTF）の暗号フォーラム研究グループのコンセンサスを表しています。IRSGによって公開されたことが承認された文書は、インターネット標準のレベルの候補者ではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9771.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9771で取得できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2025 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
1. Introduction
1.1. Background
1.2. Scope
2. Conventions Used in This Document
3. AEAD Algorithms
4. AEAD Properties
4.1. Classification of Additional AEAD Properties
4.2. Conventional Properties
4.2.1. Confidentiality
4.2.2. Data Integrity
4.2.3. Authenticated Encryption Security
4.3. Security Properties
4.3.1. Blockwise Security
4.3.2. Full Commitment
4.3.3. Key Commitment
4.3.4. Leakage Resistance
4.3.5. Multi-user Security
4.3.6. Nonce Hiding
4.3.7. Nonce Misuse
4.3.8. Quantum Security
4.3.9. Reforgeability Resilience
4.3.10. Release of Unverified Plaintext (RUP) Integrity
4.4. Implementation Properties
4.4.1. Hardware Efficient
4.4.2. Inverse-Free
4.4.3. Lightweight
4.4.4. Parallelizable
4.4.5. Setup-Free
4.4.6. Single Pass
4.4.7. Static Associated Data Efficient
4.4.8. Streamable
5. Security Considerations
6. IANA Considerations
7. References
7.1. Normative References
7.2. Informative References
Appendix A. AEAD Algorithms with Additional Functionality
A.1. Incremental Authenticated Encryption
A.2. Robust Authenticated Encryption
Acknowledgments
Author's Address
An Authenticated Encryption with Associated Data (AEAD) algorithm provides confidentiality for the plaintext to be encrypted and integrity for the plaintext and some associated data (sometimes called "Header"). AEAD algorithms play a crucial role in various applications and have emerged as a significant focus in cryptographic research.
関連データ（AEAD）アルゴリズムを備えた認証された暗号化は、プレーンテキストの機密性を提供し、プレーンテキストといくつかの関連データの整合性（「ヘッダー」と呼ばれることもあります）を提供します。AEADアルゴリズムは、さまざまなアプリケーションで重要な役割を果たしており、暗号化研究の重要な焦点として浮上しています。
AEAD algorithms are formally defined in [RFC5116]. The main benefit of AEAD algorithms is that they simultaneously provide data confidentiality and integrity and have a simple unified interface. In contrast to generic compositions of Message Authentication Code (MAC) and encryption algorithms, an AEAD algorithm allows for a reduction in key and state sizes, improving the data processing speed. Most AEAD algorithms come with security analysis, usage guidelines, and reference implementations. Consequently, their integration into high-level schemes and protocols is highly transparent. For instance, AEAD algorithms are mandatory in TLS 1.3 [RFC8446], IPsec Encapsulating Security Payload (ESP) [RFC4303] [RFC8221], and QUIC [RFC9000].
AEADアルゴリズムは[RFC5116]で正式に定義されています。AEADアルゴリズムの主な利点は、データの機密性と整合性を同時に提供し、単純な統一インターフェイスを持っていることです。メッセージ認証コード（MAC）および暗号化アルゴリズムの一般的な構成とは対照的に、AEADアルゴリズムにより、キーサイズと状態サイズを縮小し、データ処理速度が向上します。ほとんどのAEADアルゴリズムには、セキュリティ分析、使用ガイドライン、および参照実装が伴います。その結果、高レベルのスキームとプロトコルへの統合は非常に透明です。たとえば、AEADアルゴリズムは、TLS 1.3 [RFC8446]、セキュリティペイロード（ESP）[RFC4303] [RFC8221]、およびQUIC [RFC9000]でカプセル化されているIPSECで必須です。
While confidentiality and data integrity (the conventional properties of AEAD algorithms) suffice for many applications, some environments demand other uncommon cryptographic properties. These often require additional analysis and research. As the number of such properties and corresponding research papers grows, inevitable misunderstandings and confusion arise. This is a common situation when related but formally different properties are named identically or when some security properties only have folklore understanding and are not formally defined. Consequently, the risk of misusing AEAD algorithms increases, potentially resulting in security issues.
機密性とデータの整合性（AEADアルゴリズムの従来のプロパティ）では多くのアプリケーションで十分ですが、一部の環境では他の珍しい暗号化特性を要求します。これらには、多くの場合、追加の分析と研究が必要です。そのような特性と対応する研究論文の数が増えると、避けられない誤解と混乱が生じます。これは、関連するが正式に異なるプロパティが同一に命名されている場合、または一部のセキュリティプロパティが民間伝承の理解しかなく、正式に定義されていない場合に一般的な状況です。その結果、AEADアルゴリズムを誤用するリスクが高まり、セキュリティの問題が発生する可能性があります。
In Section 4 of this document, we provide a list of the most common additional properties of AEAD algorithms. The properties are divided into two categories, namely, security properties (see Section 4.3) and implementation properties (see Section 4.4). We provide a high-level definition for each property. For security properties, we also reference an informative source where a formal game-based security notion is defined; we do not consider security properties for which no game-based formalization exists. When possible, we offer additional information: synonymous names, examples of algorithms that provide the property, applications that might necessitate the property from an AEAD algorithm, references for further reading, and additional notes containing information outside these categories.
このドキュメントのセクション4では、AEADアルゴリズムの最も一般的な追加プロパティのリストを提供します。プロパティは、2つのカテゴリ、つまりセキュリティプロパティ（セクション4.3を参照）と実装プロパティ（セクション4.4を参照）に分けられます。各プロパティの高レベルの定義を提供します。セキュリティプロパティについては、正式なゲームベースのセキュリティ概念が定義されている有益なソースも参照します。ゲームベースの形式化が存在しないセキュリティプロパティを考慮しません。可能であれば、同義語の名前、プロパティを提供するアルゴリズムの例、AEADアルゴリズムからプロパティを必要とする可能性のあるアプリケーション、さらなる読み取りの参照、およびこれらのカテゴリ以外の情報を含む追加メモを提供します。
The objective of this document is to enhance clarity and establish a common language in the field. In particular, the primary application of the document lies in the following two use cases within the document development process in the IRTF and IETF:
このドキュメントの目的は、透明度を高め、現場で共通言語を確立することです。特に、ドキュメントの主要なアプリケーションは、IRTFおよびIETFのドキュメント開発プロセス内の次の2つのユースケースにあります。
* For an RFC or I-D that defines an AEAD algorithm, it is recommended to use the notations in Section 4 when listing additional properties of the algorithm.
* AEADアルゴリズムを定義するRFCまたはI-Dの場合、アルゴリズムの追加プロパティをリストするときにセクション4の表記を使用することをお勧めします。
* For an RFC or I-D that defines a generic protocol based on an AEAD algorithm, it is recommended to use the notations in Section 4 if any additional properties are required from the algorithm.
* AEADアルゴリズムに基づいて一般的なプロトコルを定義するRFCまたはI-Dの場合、アルゴリズムから追加のプロパティが必要な場合は、セクション4の表記を使用することをお勧めします。
This document represents the consensus of the Crypto Forum Research Group (CFRG). This document is not an IETF product and is not a standard.
このドキュメントは、Crypto Forum Research Group（CFRG）のコンセンサスを表しています。このドキュメントはIETF製品ではなく、標準ではありません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
This section gives a conventional definition of an AEAD algorithm following [RFC5116].
このセクションでは、[RFC5116]に続くAEADアルゴリズムの従来の定義を示します。
Definition:
意味：
An AEAD algorithm is defined by two operations, which are authenticated encryption and authenticated decryption:
AEADアルゴリズムは2つの操作によって定義されます。これは、暗号化と認証された復号化です。
* A deterministic operation of authenticated encryption has four inputs, each a binary string: a secret key K of a fixed bit length, a nonce N, associated data A, and a plaintext P. The plaintext contains the data to be encrypted and authenticated, and the associated data contains the data to be authenticated only. Each nonce value MUST be unique in every distinct invocation of the operation for any particular value of the key. The authenticated encryption operation outputs a ciphertext C.
* 認証された暗号化の決定論的操作には、それぞれのバイナリ文字列の4つの入力があります。固定ビット長のシークレットキーK、ノンセn、関連データA、および平文P。各NonCe値は、キーの特定の値に対する操作のすべての明確な呼び出しにおいて一意でなければなりません。認証された暗号化操作は、暗号文Cを出力します。
* A deterministic operation of authenticated decryption has four inputs, each a binary string: a secret key K of a fixed bit length, a nonce N, associated data A, and a ciphertext C. The operation verifies the integrity of the ciphertext and associated data and decrypts the ciphertext. It returns a special symbol FAIL if the inputs are not authentic; otherwise, the operation returns a plaintext P.
* 認証された復号化の決定論的操作には4つの入力があり、それぞれにバイナリ文字列があります：固定ビット長の秘密キーK、非CEN、関連データA、および暗号文C。操作は、暗号文の完全性と関連するデータの完全性を検証し、暗号文を飾ります。入力が本物でない場合、特別なシンボル障害を返します。それ以外の場合、操作はPlantext Pを返します。
We note that specifications of AEAD algorithms that use authentication tags to ensure integrity may define the authentication tag as an independent output of the encryption operation and an independent input of the decryption operation. Throughout this document, by default, we consider the authentication tag as part of the ciphertext.
認証タグを使用して整合性を確保するAEADアルゴリズムの仕様により、認証タグを暗号化操作の独立した出力と復号化操作の独立した入力として定義できることに注意してください。このドキュメント全体で、デフォルトでは、認証タグを暗号文の一部と見なします。
For more details on the AEAD definition, please refer to [RFC5116].
AEAD定義の詳細については、[RFC5116]を参照してください。
Throughout this document, by default, we consider nonce-based AEAD algorithms, which have an interface as defined above, and we give no other restrictions on their structure. However, some properties considered in the document apply only to particular classes of such algorithms, like AEAD algorithms based on block ciphers (such algorithms use a block cipher as a building block). If that is the case, we explicitly point that out in the corresponding section.
このドキュメント全体で、デフォルトでは、上記のインターフェイスがあるNonCEベースのAEADアルゴリズムを検討し、その構造に関する他の制限はありません。ただし、ドキュメントで検討されている一部のプロパティは、ブロック暗号に基づくAEADアルゴリズムのように、そのようなアルゴリズムの特定のクラスにのみ適用されます（このようなアルゴリズムは、ビルディングブロックとしてブロック暗号を使用します）。その場合、対応するセクションで明示的に指摘します。
In this document, we employ a high-level classification of additional properties. This classification aims to provide insight into how one can benefit from each property. The additional properties are categorized into one of these two groups:
このドキュメントでは、追加のプロパティの高レベルの分類を採用しています。この分類は、各プロパティからどのように利益を得ることができるかについての洞察を提供することを目的としています。追加のプロパティは、これら2つのグループのいずれかに分類されます。
* Security properties: We classify a property as a security property if it either takes into account new threats or extends adversarial capabilities, in addition to those posed by the typical nonce-respecting adversary whose goal is to compromise confidentiality or data integrity.
* セキュリティプロパティ：新しい脅威を考慮するか、敵対的な能力を拡張している場合、セキュリティプロパティを分類します。また、機密性やデータの完全性を損なうことを目標とする典型的な非CE尊敬の敵によってもたらされるものに加えて。
* Implementation properties: We classify a property as an implementation property if it enables more efficient implementations of the AEAD algorithm in specific cases or environments.
* 実装プロパティ：特定のケースまたは環境でAEADアルゴリズムのより効率的な実装を可能にする場合、プロパティを実装プロパティとして分類します。
We note that some additional properties of AEAD algorithms found in the literature could not be allocated to either of these two groups. The observation is that such properties require an extension of the conventional AEAD interface. We refer to these properties as "additional functionality properties" and define the corresponding group as follows:
文献で見つかったAEADアルゴリズムのいくつかの追加の特性を、これら2つのグループのいずれかに割り当てることができないことに注意してください。観察は、そのような特性には従来のAEADインターフェイスの拡張が必要であることです。これらのプロパティを「追加の機能プロパティ」と呼び、対応するグループを次のように定義します。
* Additional functionality properties: We classify a property as an additional functionality property if it introduces new features in addition to the standard AEAD.
* 追加の機能プロパティ：標準のAEADに加えて新しい機能を導入する場合、プロパティを追加の機能プロパティとして分類します。
With the extension of the conventional AEAD interface, each additional functionality property defines a new class of cryptographic algorithms. Consequently, the basic threats and adversarial capabilities must be redefined for each class. As a result, additional functionality properties consider the basic threats and adversarial capabilities for their class of algorithms, in contrast to security properties, which consider the extended ones. For this reason, we do not focus on additional functionality properties in this document. However, for the sake of completeness, in Appendix A, we briefly present two classes of AEAD algorithms with additional functionality.
従来のAEADインターフェイスの拡張により、各追加機能プロパティは、暗号化アルゴリズムの新しいクラスを定義します。したがって、基本的な脅威と敵対能力を各クラスの再定義する必要があります。その結果、追加の機能特性は、拡張されたプロパティを考慮したセキュリティプロパティとは対照的に、アルゴリズムのクラスの基本的な脅威と敵対能力を考慮します。このため、このドキュメントの追加機能プロパティに焦点を当てていません。ただし、完全性のために、付録Aでは、追加の機能を備えた2つのクラスのAEADアルゴリズムを簡単に提示します。
In this section, we recall the conventional properties of an AEAD algorithm. Active nonce-respecting adversaries in a single-key setting are considered.
このセクションでは、AEADアルゴリズムの従来の特性を思い出します。シングルキーの環境でのアクティブな非CEの敵が考慮されます。
We say that an AEAD algorithm provides security if it provides the conventional properties listed in this section.
AEADアルゴリズムは、このセクションにリストされている従来のプロパティを提供する場合、セキュリティを提供すると言います。
Definition:
意味：
An AEAD algorithm guarantees that the plaintext is not available to an active, nonce-respecting adversary.
AEADアルゴリズムは、プレーンテキストがアクティブで非CEの敵対者が利用できないことを保証します。
Security notions:
セキュリティの概念：
IND-CCA [BN08] (or IND-CCA2 [S04])
ind-cca [bn08]（またはind-cca2 [s04]）
Synonyms:
同義語：
Message privacy
メッセージプライバシー
Notes:
注：
Confidentiality against passive adversaries can also be considered. The corresponding security notion is IND-CPA [BN08] [R02].
受動的な敵に対する機密性も考慮することができます。対応するセキュリティの概念は、IND-CPA [BN08] [R02]です。
Further reading:
さらに読む：
[R02], [BN08], [S04]
[R02]、[BN08]、[S04]
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.
AEADアルゴリズムにより、Ciphertextと関連するデータが、アクティブな非CEの敵対者によって変更または偽造されていないことを確認できます。
Security notions:
セキュリティの概念：
INT-CTXT [BN08] (or AUTH [R02])
int-ctxt [bn08]（またはauth [r02]）
Synonyms:
同義語：
Message authentication, authenticity
メッセージ認証、信頼性
Further reading:
さらに読む：
[R02], [BN08], [S04]
[R02]、[BN08]、[S04]
Definition:
意味：
An AEAD algorithm provides confidentiality and data integrity against active, nonce-respecting adversaries.
AEADアルゴリズムは、アクティブで非尊敬の敵に対して機密性とデータの整合性を提供します。
Security notions:
セキュリティの概念：
IND-CPA and INT-CTXT [BN08] [R02] (or equivalently, IND-CCA3 [S04])
IND-CPAおよびINT-CTXT [BN08] [R02]（または同等に、IND-CCA3 [S04]）
Notes:
注：
Please refer to [AEAD-LIMITS] for usage limits on modern AEAD algorithms used in IETF protocols.
IETFプロトコルで使用される最新のAEADアルゴリズムの使用制限については、[AEAD-limits]を参照してください。
Further reading:
さらに読む：
[R02], [BN08], [S04]
[R02]、[BN08]、[S04]
Definition:
意味：
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.
AEADアルゴリズムは、暗号化操作中に既に計算された暗号文化部品に応じて、敵がプレーンテキストの次の部分を適応的に選択できる場合でも、セキュリティを提供します。
Security notions:
セキュリティの概念：
D-LORS-BCPA for confidentiality against passive adversaries, B-INT-CTXT for integrity [EV17]; OAE1 [HRRV15] (a stronger notion; originally OAE (Online Authenticated Encryption) in [FFL12])
受動的な敵に対する機密性のためのD-Lors-BCPA、整合性のためのB-Int-CTXT [EV17];oae1 [hrrv15]（より強い概念、もともと[FFL12]のオンライン認証暗号化））
Examples:
例：
Deoxys [JNPS21], SAEF [ABV21]
Deoxys [Jnps21]、Saef [abv21]
Notes:
注：
Blockwise security is highly relevant for streamable AEAD algorithms (see Section 4.4.8). The OAE1 security notion [HRRV15] and the OAE2 notion [HRRV15] are tailored for streamable AEAD algorithms. OAE1 was first defined in [FFL12] under the name OAE; however, it contained a glitch, and the reformulated definition was presented in [HRRV15]. Blockwise security follows from security in the OAE notion [EV17]. For a discussion on security notions for streamable AEAD algorithms, see [HRRV15].
ブロックワイズセキュリティは、ストリーミング可能なAEADアルゴリズムに非常に関連しています（セクション4.4.8を参照）。OAE1セキュリティ概念[HRRV15]およびOAE2概念[HRRV15]は、ストリーミング可能なAEADアルゴリズムに合わせて調整されています。OAE1は、OAEという名前で[FFL12]で最初に定義されました。ただし、グリッチが含まれており、再定義された定義は[HRRV15]に提示されました。ブロックワイズセキュリティは、OAE概念のセキュリティから続きます[EV17]。ストリーミング可能なAEADアルゴリズムのセキュリティ概念に関する議論については、[HRRV15]を参照してください。
Applications:
アプリケーション：
Real-time streaming protocols, encryption on resource-constrained devices
リアルタイムストリーミングプロトコル、リソース制約のデバイスの暗号化
Further reading:
さらに読む：
[EV17], [JMV2002], [FJMV2004], [HRRV15]
[EV17]、[JMV2002]、[FJMV2004]、[HRRV15]
Definition:
意味：
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.
AEADアルゴリズムは、キー、ノンセ、関連するデータ、およびプレーンテキストの2つ以上の異なるタプルを見つけにくいことを保証し、同じ暗号文に暗号化するようにします。言い換えれば、AEADスキームは、暗号文が認証された暗号化操作のすべての入力に対するコミットメントであることを保証します。
Security notions:
セキュリティの概念：
CMT-4 [BH22], generalized CMT for a restricted setting (see the notes below) [MLGR23]
CMT-4 [BH22]、制限された設定の一般化CMT（以下のメモを参照）[MLGR23]
Examples:
例：
Ascon [DEMS21a] [DEMS21b] [YSS23], full committing versions of Galois/Counter Mode (GCM) and GCM-SIV [BH22], generic constructions [BH22] and [CR22]
ASCON [DEMS21A] [DEMS21B] [YSS23]、Galois/Counter Mode（GCM）およびGCM-SIV [BH22]の完全なコミットバージョン、一般的な構成[BH22]および[CR22]
Notes:
注：
Full commitment can be considered in a weaker setting, where certain restrictions on the tuples produced by an adversary are imposed [MLGR23]. For instance, an adversary must find tuples that all share the same associated data value. In such cases, an AEAD algorithm is said to provide full commitment in a restricted setting. The imposed restrictions MUST be listed.
完全なコミットメントは、より弱い設定で考慮することができます。そこでは、敵によって生成されたタプルの特定の制限が課されます[MLGR23]。たとえば、敵はすべて同じ関連データ値を共有するタプルを見つけなければなりません。そのような場合、AEADアルゴリズムは、制限された設定で完全なコミットメントを提供すると言われています。課された制限をリストする必要があります。
Applications:
アプリケーション：
Message franking [GLR17]
メッセージフランキング[GLR17]
Further reading:
さらに読む：
[BH22], [CR22], [MLGR23]
[BH22]、[CR22]、[MLGR23]
Definition:
意味：
An AEAD algorithm guarantees that it is hard to find two or more different keys and the same number of potentially equal triples of nonce, associated data, and plaintext such that they encrypt to the same ciphertext under corresponding keys. In other words, an AEAD scheme guarantees that a ciphertext is a commitment to the key used for an authenticated encryption operation.
AEADアルゴリズムは、2つ以上の異なるキーと、潜在的に等しい3トリプルの非CE、関連データ、およびプレーンテキストを見つけるのが難しいことを保証し、対応するキーの下で同じ暗号文に暗号化するようにします。言い換えれば、AEADスキームは、暗号文が認証された暗号化操作に使用されるキーへのコミットメントであることを保証します。
Security notions:
セキュリティの概念：
CMT-1 [BH22]
CMT-1 [BH22]
Synonyms:
同義語：
Key robustness, key collision resistance
主要な堅牢性、キー衝突抵抗
Examples:
例：
Ascon [DEMS21a] [DEMS21b] [YSS23], generic constructions from [BH22] and [CR22]
ASCON [DEMS21A] [DEMS21B] [YSS23]、[BH22]および[CR22]の一般的な構成
Notes:
注：
Key commitment follows from full commitment. Full commitment does not follow from key commitment [BH22].
主なコミットメントは、完全なコミットメントから続きます。完全なコミットメントは、重要なコミットメント[BH22]から続きません。
Applications:
アプリケーション：
Password-Authenticated Key Exchange, password-based encryption [LGR21], key rotation, envelope encryption [ADGKLS22]
パスワード - 認識キー交換、パスワードベースの暗号化[LGR21]、キーローテーション、エンベロープ暗号化[ADGKLS22]
Further reading:
さらに読む：
[BH22], [CR22], [FOR17], [LGR21], [GLR17]
[BH22]、[CR22]、[FOR17]、[LGR21]、[GLR17]
Definition:
意味：
An AEAD algorithm provides security even if some additional information about computations of an encryption (and possibly decryption) operation is obtained via side-channel leakages.
AEADアルゴリズムは、暗号化（および場合によっては復号化）操作の計算に関するいくつかの追加情報が、サイドチャネル漏れを介して取得された場合でも、セキュリティを提供します。
Security notions:
セキュリティの概念：
CIL1 [GPPS19] (CIML2 [BPPS17] with leakages in decryption) for integrity, CCAL1 [GPPS19] (CCAmL2 [GPPS19] with leakages in decryption) for authenticated encryption security
CIL1 [GPPS19]（CIML2 [BPPS17]は、復号化の漏れを伴う）、整合性のために、CCAL1 [GPPS19]（CCAML2 [GPPS19]を復byで漏れて）認証暗号化セキュリティのために）
Examples:
例：
Ascon [DEMS21a] [DEMS21b] (security under CIML2 and CCAL1 notions [B20]), TEDT [GPPS19]
ASCON [DEMS21A] [DEMS21B]（CIML2およびCCAL1概念の下でのセキュリティ[B20]）、TEDT [GPPS19]
Notes:
注：
Leakages during AEAD operation executions are implementation-dependent. It is possible to implement symmetric algorithms in a way that every possible physical leakage is entirely independent of the secret inputs of the algorithm (for example, with a masking technique [CJRR99]), meaning the adversary doesn't gain any additional information about the algorithm's computation via side-channel leakages. We say that an AEAD algorithm doesn't provide leakage resistance if it can only achieve leakage resistance with such an implementation. Leakage-resistant AEAD algorithms aim to place requirements on implementations that are as mild as possible to achieve leakage resistance. These requirements SHOULD be listed.
AEAD操作の実行中の漏れは、実装依存です。すべての可能性のある物理的漏れがアルゴリズムの秘密の入力（たとえば、マスキング技術[CJRR99]を使用）に完全に依存しないように対称アルゴリズムを実装することが可能です。AEADアルゴリズムは、そのような実装でのみ漏れ抵抗を達成できる場合、漏れ抵抗を提供しないと言います。漏れ耐性のAEADアルゴリズムは、漏れ抵抗を達成するために可能な限り軽度の実装に要件を置くことを目的としています。これらの要件をリストする必要があります。
Confidentiality of plaintext in the presence of leakages in the encryption operation is unachievable if an adversary can repeat the nonce used to encrypt the plaintext in other encryption queries. Confidentiality can be achieved only for plaintexts encrypted with fresh nonces (analogously to nonce-misuse resilience; see Section 4.3.7). For further discussions, see [GPPS19] and [B20].
暗号化操作に漏れがある場合のプレーンテキストの機密性は、敵が他の暗号化クエリでプレーンテキストを暗号化するために使用されるNonCEを繰り返すことができる場合、達成できません。機密性は、フレッシュノンセスで暗号化されたプレーンテキストでのみ達成できます（NonCe-Misuse Resilienceと同様に、セクション4.3.7を参照）。さらなる議論については、[GPPS19]および[B20]を参照してください。
For primitive-based AEAD algorithms, key evolution (internal re-keying [RFC8645]) can contribute to achieving leakage resistance with leakages in encryption. Confidentiality in the presence of decryption leakages can be achieved by two-pass AEAD algorithms with key evolution, which compute independent ephemeral key values for encryption and tag generation, where the computation of these keys is implemented without any leakages. For more discussion on achieving leakage resistance, see [B20].
プリミティブベースのAEADアルゴリズムの場合、重要な進化（内部再キーリング[RFC8645]）は、暗号化の漏れで漏れ抵抗を達成することに貢献できます。復号化漏れの存在下での機密性は、暗号化とタグ生成の独立した一時的なキー値を計算するキー進化を備えた2パスAEADアルゴリズムによって達成できます。これらのキーの計算は、漏れなく実装されます。漏れ抵抗の達成に関する詳細については、[B20]を参照してください。
Leakage Resilience, a well-known weaker property introduced in [BMOS17], can also be considered. However, following the framework established in [GPPS19] and [B20], this document makes a conscious choice to focus on the stronger Leakage Resistance for its enhanced practicality and comprehensiveness.
[BMOS17]で導入されたよく知られている弱い特性である漏れの回復力も考慮することができます。ただし、[GPPS19]と[B20]で確立されたフレームワークに従って、このドキュメントは、実用性と包括性の向上のために、より強い漏れ抵抗に焦点を合わせることを意識的に選択します。
Applications:
アプリケーション：
Encryption on smart cards, Internet-of-Things devices, or other constrained devices
スマートカード、インターネットのデバイス、またはその他の制約付きデバイスの暗号化
Further reading:
さらに読む：
[GPPS19], [B20], [BPPS17], [BMOS17]
[gpps19]、[b20]、[bpps17]、[bmos17]
Definition:
意味：
The security of an AEAD algorithm degrades slower than linearly with an increase in the number of users.
AEADアルゴリズムのセキュリティは、ユーザー数の増加とともに直線的に低下します。
Security notions:
セキュリティの概念：
mu-ind [BT16]
mu-ind [bt16]
Examples:
例：
AES-GCM [D07], ChaCha20-Poly1305 [RFC8439], AES-GCM-SIV [RFC8452], AEGIS [AEGIS-AEAD]
AES-GCM [D07]、Chacha20-Poly1305 [RFC8439]、AES-GCM-SIV [RFC8452]、aegis [aegis-aead]
Notes:
注：
For any AEAD algorithm, security degrades no worse than linearly with an increase in the number of users [BT16]. However, for some applications with a significant number of users, better multi-user guarantees are required. For example, in the TLS 1.3 protocol, AEAD algorithms are used with a randomized nonce (deterministically derived from a traffic secret and a sequence number) to address this issue. Using nonce randomization in block cipher counter-based AEAD modes can contribute to multi-user security [BT16]. Multi-user usage limits for AES-GCM and ChaCha20-Poly1305 are provided in [AEAD-LIMITS].
AEADアルゴリズムの場合、セキュリティはユーザー数の増加とともに直線的に悪化することはありません[BT16]。ただし、かなりの数のユーザーを抱える一部のアプリケーションでは、より良いマルチユーザー保証が必要です。たとえば、TLS 1.3プロトコルでは、AEADアルゴリズムは、この問題に対処するために、ランダム化された非CE（トラフィックシークレットとシーケンス番号から決定的に導出された）で使用されます。ブロック暗号カウンターベースのAEADモードで非CEランダム化を使用すると、マルチユーザーセキュリティに貢献できます[BT16]。AES-GCMおよびChacha20-Poly1305のマルチユーザーの使用制限は、[AEAD-limits]で提供されます。
A weaker security notion, multi-user key recovery, is also introduced and thoroughly studied in [BT16]. While this document focuses on indistinguishability for security notions, key recovery might be relevant and valuable to study alongside indistinguishability.
より弱いセキュリティの概念、マルチユーザーキーリカバリも[BT16]で導入され、徹底的に研究されています。このドキュメントでは、セキュリティ概念の区画の区別可能性に焦点を当てていますが、キーリカバリーは、区別不可能性とともに研究するために関連性が高く価値がある場合があります。
Applications:
アプリケーション：
Data transmission layer of secure communication protocols (e.g., TLS, IPsec, the Secure Real-time Transport Protocol (SRTP), etc.)
安全な通信プロトコルのデータ伝送層（例：TLS、IPSEC、安全なリアルタイム輸送プロトコル（SRTP）など）
Further reading:
さらに読む：
[BT16], [HTT18], [LMP17], [DGGP21], [BHT18]
[BT16]、[HTT18]、[LMP17]、[DGGP21]、[BHT18]
Definition:
意味：
An AEAD algorithm provides confidentiality for the nonce value used to encrypt plaintext. The algorithm includes information about the nonce in the ciphertext and doesn't require the nonce as input for the decryption operation.
AEADアルゴリズムは、プレーンテキストを暗号化するために使用されるNonCE値の機密性を提供します。アルゴリズムには、暗号文の非CEに関する情報が含まれており、復号化操作の入力としてNonCEを必要としません。
Security notions:
セキュリティの概念：
AE2 [BNT19]
AE2 [BNT19]
Examples:
例：
Hide-Nonce (HN) transforms [BNT19]
Hide-Nonce（HN）変換[BNT19]
Notes:
注：
As discussed in [BNT19], adversary-visible nonces might compromise message and user privacy, similar to the way any metadata might. As pointed out in [B13], even using a counter as a nonce value might compromise privacy. Designing a privacy-preserving way to manage nonces might be a challenging problem for an application.
[BNT19]で説明したように、敵対的な非能力は、メタデータがそうであるように、メッセージとユーザーのプライバシーを妥協する可能性があります。[B13]で指摘されているように、カウンターをNonCE値として使用してもプライバシーを損なう可能性があります。NONCESを管理するためのプライバシー提示方法を設計することは、アプリケーションにとって挑戦的な問題かもしれません。
Applications:
アプリケーション：
Any application that can't rely on a secure "out-of-band" nonce communication
安全な「帯域外」NONCE通信に依存できないアプリケーション
Further reading:
さらに読む：
[BNT19]
[BNT19]
Definition:
意味：
An AEAD algorithm provides security (resilience or resistance) even if an adversary can repeat nonces in its encryption queries. Nonce misuse resilience and resistance are defined as follows:
AEADアルゴリズムは、敵が暗号化クエリでノンースを繰り返すことができる場合でも、セキュリティ（回復力または抵抗）を提供します。Nonceの誤用の回復力と抵抗は次のように定義されます。
Nonce misuse resilience:
非誤用回復力：
Security is provided for messages encrypted with non-repeated (fresh) nonces (correctly encrypted messages).
セキュリティは、非回復（新鮮な）Nonces（正しく暗号化されたメッセージ）で暗号化されたメッセージのために提供されます。
Security notions:
セキュリティの概念：
Chosen-Plaintext Attack (CPA) resilience (confidentiality), authenticity resilience (integrity), Chosen-Ciphertext Attack (CCA) resilience (authenticated encryption) [ADL17]
選択されたプレーンテキスト攻撃（CPA）レジリエンス（機密性）、信頼性の回復力（整合性）、選ばれたカイファテキスト攻撃（CCA）レジリエンス（認証された暗号化）[ADL17]
Examples:
例：
ChaCha20-Poly1305 [RFC8439], AES-GCM [D07] (only confidentiality)
Chacha20-Poly1305 [RFC8439]、AES-GCM [D07]（機密性のみ）
Nonce misuse resistance:
Nonce誤用抵抗：
Security is provided for all messages that were not encrypted with the same nonce value more than once.
セキュリティは、同じNONCE値で複数回暗号化されていないすべてのメッセージに対して提供されます。
Security notions:
セキュリティの概念：
MRAE [RS06]
mrae [rs06]
Examples:
例：
AES-GCM-SIV [RFC8452], Deoxys-II [JNPS21]
AES-GCM-SIV [RFC8452]、Deoxys-II [JNPS21]
Notes:
注：
Synthetic Initialization Vector (SIV) construction [RS06] is a generic construction that provides nonce misuse resistance.
合成初期化ベクトル（SIV）構造[RS06]は、非CE誤用耐性を提供する一般的な構造です。
Notes:
注：
Nonce misuse resilience follows from nonce misuse resistance. Nonce misuse resistance does not follow from nonce misuse resilience.
Nonceの誤用回復力は、NonCe誤用抵抗から続きます。NonCe誤用抵抗は、NonCeの誤用回復力から続きません。
Applications:
アプリケーション：
Any application where nonce uniqueness can't be guaranteed, security against fault-injection attacks and malfunctions, processes parallelization, full disk encryption
Nonceの一意性を保証できないアプリケーション、断層噴射攻撃と誤動作、プロセスの並列化、完全ディスク暗号化に対するセキュリティ
Further reading:
さらに読む：
[RS06], [ADL17], [IIM25]
[RS06]、[ADL17]、[IIM25]
Definition:
意味：
An AEAD algorithm provides security (in a Q1 or Q2 model) against a quantum adversary. Q1 and Q2 models are defined as follows:
AEADアルゴリズムは、量子敵に対して（Q1またはQ2モデルで）セキュリティを提供します。Q1およびQ2モデルは次のように定義されています。
Q1 model:
Q1モデル：
An adversary has access to local quantum computational power. It has classical access to encryption and decryption oracles.
敵は、ローカル量子計算能力にアクセスできます。暗号化と復号化のオラクルへの古典的なアクセスがあります。
Synonyms:
同義語：
Post-quantum security
質量セキュリティ
Examples:
例：
AES-GCM [D07], ChaCha20-Poly1305 [RFC8439], OCB [RFC7253], Multilinear Galois Mode (MGM) [RFC9058], AES-GCM-SIV [RFC8452], AEGIS [AEGIS-AEAD]
AES-GCM [D07]、Chacha20-Poly1305 [RFC8439]、OCB [RFC7253]、多重化ガロアモード（MGM）[RFC9058]、AES-GCM-SIV [RFC8452]、AEGIS [AEGIS-AEAD]
Q2 model:
Q2モデル：
An adversary has access to local quantum computational power. It has quantum access to encryption and decryption oracles, i.e., it can query encryption and decryption oracles with quantum superpositions of inputs to receive quantum superpositions of the outputs.
敵は、ローカル量子計算能力にアクセスできます。暗号化と復号化のオラクルへの量子アクセスがあります。つまり、出力の量子重複を受信するために、入力の量子重ね合わせで暗号化と復号化のオラクルをクエリすることができます。
Synonyms:
同義語：
Superposition-based quantum security
重ねベースの量子セキュリティ
Examples:
例：
QCB [BBCLNSS21]
QCB [BBCLNSS21]
Notes:
注：
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 [G17].
古典モデルで安全なほとんどの対称暗号化アルゴリズムは、Q1モデルの量子セキュリティを提供します。Q1設定のセキュリティは、「今すぐ収穫、後の復号化」攻撃に対するセキュリティに対応しています。第1四半期のセキュリティは、第2四半期のセキュリティから続きます。コンバースは保持されません。Q2モデルの関連性に関する議論については、[G17]を参照してください。
Further reading:
さらに読む：
[KLLNP16], [BBCLNSS21], [G17]
[kllnp16]、[bbclnss21]、[g17]
Definition:
意味：
An AEAD algorithm guarantees that once a successful forgery for the algorithm has been found, it is still hard to find any subsequent forgery.
AEADアルゴリズムは、アルゴリズムの偽造が成功した後、その後の偽造を見つけることが依然として困難であることを保証します。
Security notions:
セキュリティの概念：
j-Int-CTXT [FLLW17]
j-int-ctxt [fllw17]
Examples:
例：
Deoxys [JNPS21], AEGIS [AEGIS-AEAD], Ascon [DEMS21a] [DEMS21b]
deoxys [Jnps21]、aegis [aegis-aead]、ascon [dems21a] [dems21b]
Applications:
アプリケーション：
Voice over IP (VoIP), real-time streaming in a lightweight setting, applications that require small ciphertext expansion (i.e., short tags)
Voice over IP（VoIP）、軽量設定でのリアルタイムストリーミング、小さな暗号文の拡張（つまり、短いタグ）を必要とするアプリケーション
Further reading:
さらに読む：
[BC09], [FLLW17]
[BC09]、[FLLW17]
Definition:
意味：
An AEAD algorithm provides data integrity even if plaintext is released for every ciphertext, including those with failed integrity verification.
AEADアルゴリズムは、整合性の検証が失敗したものを含むすべての暗号文でプレーンテキストがリリースされた場合でも、データの整合性を提供します。
Security notions:
セキュリティの概念：
INT-RUP [A14]
int-rup [a14]
Examples:
例：
GCM [IIM25], GCM-RUP [ADL17]
GCM [IIM25]、GCM-RUP [ADL17]
Applications:
アプリケーション：
Decryption with limited memory [FJMV2004], real-time streaming protocols
限られたメモリによる復号化[FJMV2004]、リアルタイムストリーミングプロトコル
Notes:
注：
In [ADL17], a generic approach to achieve INT-RUP security is introduced.
[ADL17]では、INT-RUPセキュリティを達成するための一般的なアプローチが導入されています。
In the provided definition, we only consider integrity in the RUP setting, since confidentiality, in the usual sense, is unachievable under RUP. 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 besides what it can derive from encryption queries".
提供された定義では、通常の意味での機密性はRUPの下では達成不可能であるため、RUP設定の整合性のみを考慮しています。[A14]では、「プレーンテキスト認識」の概念が導入され、次の意味でRUPの下で可能な限り最高の機密性を獲得します。
Further reading:
さらに読む：
[A14], [ADL17], [IIM25]
[A14]、[ADL17]、[IIM25]
Definition:
意味：
An AEAD algorithm ensures optimal performance when operating on hardware that complies with the specified requirements.
AEADアルゴリズムは、指定された要件に準拠するハードウェアで動作するときに最適なパフォーマンスを保証します。
Notes:
注：
Various classes of hardware may be taken into consideration. Certain algorithms are tailored to minimize the area of dedicated hardware implementations, while others are intended to capitalize on general-purpose CPUs, with or without specific instruction sets. It is RECOMMENDED to specify the minimum platform requirements for the AEAD to fulfill its intended purpose, as well as to match its performance and security claims.
さまざまなクラスのハードウェアを考慮することができます。特定のアルゴリズムは、専用のハードウェア実装の領域を最小限に抑えるように調整されていますが、特定の命令セットの有無にかかわらず、汎用CPUを活用することを目的としているものもあります。AEADの最小プラットフォーム要件を指定して、意図した目的を満たすだけでなく、パフォーマンスとセキュリティの請求を一致させることをお勧めします。
Definition:
意味：
An AEAD algorithm based on a given primitive can be implemented without invoking the inverse of that primitive.
特定のプリミティブに基づくAEADアルゴリズムは、その原始の逆を呼び出すことなく実装できます。
Examples:
例：
AES-GCM [D07], ChaCha20-Poly1305 [RFC8439], MGM [RFC9058], AEGIS [AEGIS-AEAD]
AES-GCM [D07]、Chacha20-Poly1305 [RFC8439]、MGM [RFC9058]、aegis [aegis-aead]
Notes:
注：
In a sponge-based AEAD algorithm, an underlying permutation is viewed as a primitive.
スポンジベースのAEADアルゴリズムでは、根本的な順列が原始と見なされます。
Definition:
意味：
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 [MBTM17].
AEADアルゴリズムは、リソース制約のデバイスに効率的かつ安全に実装できます。特に、NIST軽量暗号競争で必要な基準[MBTM17]を満たしています。
Examples:
例：
OCB [RFC7253], Ascon [DEMS21a] [DEMS21b]
OCB [RFC7253]、ASCON [DEMS21A] [DEMS21B]
Further reading:
さらに読む：
[MBTM17]
[MBTM17]
Definition:
意味：
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.
AEADアルゴリズムは、並列計算インフラストラクチャを完全に活用できます。言い換えれば、並列化可能なAEADアルゴリズムにより、並行して暗号文セグメント（復号化のプレーンテキストセグメント）を計算できます。つまり、暗号文セグメントは個別に計算されます。
Synonyms:
同義語：
Pipelineable
パイプライン可能
Examples:
例：
AES-GCM [D07], ChaCha20-Poly1305 [RFC8439], OCB [RFC7253], MGM [RFC9058], AEGIS [AEGIS-AEAD]
AES-GCM [D07]、Chacha20-Poly1305 [RFC8439]、OCB [RFC7253]、MGM [RFC9058]、aegis [aegis-aead]
Further reading:
さらに読む：
[C20]
[C20]
Definition:
意味：
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.
AEADアルゴリズムの操作は、新しいキーを使用すると、以前のキーの再利用と比較してオーバーヘッドまたは無視できるオーバーヘッドのいずれかが発生しないように実装できます。オーバーヘッドには、ブロック暗号の重要なスケジュールを事前に計算するなど、追加の計算またはストレージスペースの増加が含まれる場合があります。
Examples:
例：
ChaCha20-Poly1305 [RFC8439], AEGIS [AEGIS-AEAD], Ascon [DEMS21a] [DEMS21b]
Chacha20-Poly1305 [rfc8439]、aegis [aegis-aead]、ascon [dems21a] [dems21b]
Definition:
意味：
An AEAD algorithm encryption (decryption) operation can be implemented with a single pass over the plaintext (ciphertext).
AEADアルゴリズム暗号化（復号化）操作は、Plantext（ciphertext）上の単一のパスで実装できます。
Examples:
例：
AES-GCM [D07], ChaCha20-Poly1305 [RFC8439], OCB [RFC7253], MGM [RFC9058], AEGIS [AEGIS-AEAD]
AES-GCM [D07]、Chacha20-Poly1305 [RFC8439]、OCB [RFC7253]、MGM [RFC9058]、aegis [aegis-aead]
Definition:
意味：
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.
AEADアルゴリズムを使用すると、静的（または繰り返し）関連データの事前計算が可能になり、静的関連データが暗号化の計算コストに大きく寄与しないようにします。
Examples:
例：
AES-GCM [D07], ChaCha20-Poly1305 [RFC8439], OCB [RFC7253]
AES-GCM [D07]、Chacha20-Poly1305 [RFC8439]、OCB [RFC7253]
Definition:
意味：
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.
AEADアルゴリズム暗号化（復号化）操作は、一定のメモリ使用量とプレーンテキスト上の単一の1方向パス（ciphertext）で実装でき、そのパス中に結果を書き出します。
Synonyms:
同義語：
Online
オンライン
Examples:
例：
AES-GCM [D07], ChaCha20-Poly1305 [RFC8439], OCB [RFC7253], MGM [RFC9058], AEGIS [AEGIS-AEAD], Ascon [DEMS21a] [DEMS21b]
AES-GCM [D07]、Chacha20-Poly1305 [RFC8439]、OCB [RFC7253]、MGM [RFC9058]、aegis [aegis-aead]、ascon [dems21a] [dems21b]
Applications:
アプリケーション：
Real-time streaming protocols, resource-constrained devices
リアルタイムストリーミングプロトコル、リソース制約デバイス
Notes:
注：
Blockwise security (see Section 4.3.1) and RUP integrity (see Section 4.3.10) might be relevant security properties for streamable AEAD algorithms in certain applications.
ブロックごとのセキュリティ（セクション4.3.1を参照）およびRUPの整合性（セクション4.3.10を参照）は、特定のアプリケーションでストリーミング可能なAEADアルゴリズムの関連するセキュリティプロパティです。
Further reading:
さらに読む：
[HRRV15], [FJMV2004]
[HRRV15]、[FJMV2004]
This document gives high-level definitions of AEAD properties. For each security property, we provide an informational reference to a game-based security notion (or security notions if there are separate notions for integrity and confidentiality) that formalizes the property. We only consider game-based notions and security properties that can be formalized using this approach. However, there are different approaches to formalizing AEAD security, like the indifferentiability framework [BM18]; security in such notions should be studied separately.
このドキュメントは、AEADプロパティの高レベルの定義を提供します。セキュリティプロパティごとに、プロパティを形式化するゲームベースのセキュリティ概念（または、整合性と機密性のための個別の概念がある場合、セキュリティ概念）への情報リファレンスを提供します。このアプローチを使用して形式化できるゲームベースの概念とセキュリティプロパティのみを検討します。ただし、無関心性フレームワーク[BM18]のように、AEADセキュリティを正式化するにはさまざまなアプローチがあります。このような概念のセキュリティは、個別に研究する必要があります。
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.
一部のプロパティでは、それらを提供するAEADアルゴリズムの例が与えられており、一般に遭遇するプロパティに対して標準化されたAEADアルゴリズムが好まれます。ただし、特定のプロパティでは、標準化されていないアルゴリズムのみが存在します。このようなアルゴリズムを実装するには、慎重に検討する必要があり、参照実装と実装ガイドラインについては、アルゴリズム設計者に連絡することをお勧めします。
Every claimed security property of an AEAD algorithm MUST undergo security analysis within a relevant notion. It's RECOMMENDED to use the security notions referenced in the document. If an alternative notion is used, proof of equivalence MUST exist, or use of a non-equivalent notion SHOULD be indicated. For security properties that extend adversarial capabilities, consideration of integrity and confidentiality separately may be relevant. If the algorithm provides only one of these, that SHOULD be indicated.
AEADアルゴリズムのすべての主張されたセキュリティプロパティは、関連する概念内でセキュリティ分析を受ける必要があります。ドキュメントで参照されているセキュリティ概念を使用することをお勧めします。代替の概念が使用されている場合、同等性の証明が存在する必要があるか、非同等の概念の使用を示す必要があります。敵対能力を拡張するセキュリティプロパティの場合、整合性と機密性の考慮が個別に関連する場合があります。アルゴリズムがこれらの1つのみを提供する場合、それを示す必要があります。
When specifying security requirements for an AEAD algorithm in an application, it SHOULD be indicated, for every required security property, whether only integrity or confidentiality is necessary. Additionally, for each security property, it SHOULD be specified whether an analysis in an alternative security notion is required. We also note that some additional properties come with trade-offs in terms of classical security and efficiency, and they may only be supported in non-standardized or modified AEAD algorithms. This immediately implies challenges in deployment and interoperability. In an application, the requirements for additional AEAD properties SHOULD be highly motivated and justified, and all trade-offs should be carefully considered.
アプリケーション内のAEADアルゴリズムのセキュリティ要件を指定する場合、必要なすべてのセキュリティプロパティに対して、整合性または機密性のみが必要であるかどうかを示す必要があります。さらに、セキュリティプロパティごとに、代替セキュリティ概念の分析が必要かどうかを指定する必要があります。また、いくつかの追加のプロパティには、古典的なセキュリティと効率性の観点からトレードオフが付いており、標準化されていないまたは修正されたAEADアルゴリズムでのみサポートされる可能性があることに注意してください。これは、展開と相互運用性の課題をすぐに意味します。アプリケーションでは、追加のAEADプロパティの要件は非常に動機付けられ、正当化される必要があり、すべてのトレードオフを慎重に検討する必要があります。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
[D07] Dworkin, M., "Recommendation for Block Cipher Modes of
Operation: Galois/Counter Mode (GCM) and GMAC", NIST
SP 800-38D, DOI 10.6028/NIST.SP.800-38D, 2007,
<https://csrc.nist.gov/pubs/sp/800/38/d/final>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
<https://www.rfc-editor.org/info/rfc5116>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[A14] Andreeva, E., Bogdanov, A., Luykx, A., Mennink, B., Mouha,
N., and K. Yasuda, "How to Securely Release Unverified
Plaintext in Authenticated Encryption", Advances in
Cryptology - ASIACRYPT 2014, Lecture Notes in Computer
Science, vol. 8873, pp. 105-125,
DOI 10.1007/978-3-662-45611-8_6, 2014,
<https://doi.org/10.1007/978-3-662-45611-8_6>.
[ABV21] Andreeva, E., Bhati, A.S., and D. Vizár, "Nonce-Misuse
Security of the SAEF Authenticated Encryption Mode",
Selected Areas in Cryptography (SAC 2020), Lecture Notes
in Computer Science, vol. 12804, pp. 512-534,
DOI 10.1007/978-3-030-81652-0_20, 2021,
<https://doi.org/10.1007/978-3-030-81652-0_20>.
[ADGKLS22] Albertini, A., Duong, T., Gueron, S., Kölbl, S., Luykx,
A., and S. Schmieg, "How to Abuse and Fix Authenticated
Encryption Without Key Commitment", 31st USENIX Security
Symposium (USENIX Security 22), pp. 3291-3308, 2022.
[ADL17] Ashur, T., Dunkelman, O., and A. Luykx, "Boosting
Authenticated Encryption Robustness with Minimal
Modifications", Advances in Cryptology - CRYPTO 2017,
Lecture Notes in Computer Science, vol. 10403, pp. 3-33,
DOI 10.1007/978-3-319-63697-9_1, 2017,
<https://doi.org/10.1007/978-3-319-63697-9_1>.
[AEAD-LIMITS]
Günther, F., Thomson, M., and C. A. Wood, "Usage Limits on
AEAD Algorithms", Work in Progress, Internet-Draft, draft-
irtf-cfrg-aead-limits-10, 8 April 2025,
<https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-
aead-limits-10>.
[AEGIS-AEAD]
Denis, F. and S. Lucas, "The AEGIS Family of Authenticated
Encryption Algorithms", Work in Progress, Internet-Draft,
draft-irtf-cfrg-aegis-aead-16, 17 February 2025,
<https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-
aegis-aead-16>.
[B13] Bernstein, D. J., "Re: wondering the secret message
number", Message to the Cryptographic Competitions Google
Group, 2013, <https://groups.google.com/d/msg/crypto-
competitions/n5ECGwYr6Vk/bsEfPWqSAU4J>.
[B20] Bellizia, D., Bronchain, O., Cassiers, G., Grosso, V.,
Guo, C., Momin, C., Pereira, O., Peters, T., and F.-X.
Standaert, "Mode-Level vs. Implementation-Level Physical
Security in Symmetric Cryptography: A Practical Guide
Through the Leakage-Resistance Jungle", Advances in
Cryptology - CRYPTO 2020, Lecture Notes in Computer
Science, vol. 12170, pp. 369-400,
DOI 10.1007/978-3-030-56784-2_13, 2020,
<https://doi.org/10.1007/978-3-030-56784-2_13>.
[BBCLNSS21]
Bhaumik, R., Bonnetain, X., Chailloux, A., Leurent, G.,
Naya-Plasencia, M., Schrottenloher, A., and Y. Seurin,
"QCB: Efficient Quantum-Secure Authenticated Encryption",
Advances in Cryptology - ASIACRYPT 2021, Lecture Notes in
Computer Science, vol. 13090, pp. 668-698,
DOI 10.1007/978-3-030-92062-3_23, 2021,
<https://doi.org/10.1007/978-3-030-92062-3_23>.
[BC09] Black, J. and M. Cochran, "MAC Reforgeability", Fast
Software Encryption (FSE 2009), Lecture Notes in Computer
Science, vol. 5665, pp. 345-362,
DOI 10.1007/978-3-642-03317-9_21, 2009,
<https://doi.org/10.1007/978-3-642-03317-9_21>.
[BH22] Bellare, M. and V.T. Hoang, "Efficient Schemes for
Committing Authenticated Encryption", Advances in
Cryptology - EUROCRYPT 2022, Lecture Notes in Computer
Science, vol. 13276, pp. 845-875,
DOI 10.1007/978-3-031-07085-3_29, 2022,
<https://doi.org/10.1007/978-3-031-07085-3_29>.
[BHT18] Bose, P., Hoang, V.T., and S. Tessaro, "Revisiting AES-
GCM-SIV: Multi-user Security, Faster Key Derivation, and
Better Bounds", Advances in Cryptology - EUROCRYPT 2018,
Lecture Notes in Computer Science, vol. 10820, pp.
468-499, DOI 10.1007/978-3-319-78381-9_18, 2018,
<https://doi.org/10.1007/978-3-319-78381-9_18>.
[BKY02] Buonanno, E., Katz, J., and M. Yung, "Incremental
Unforgeable Encryption", Fast Software Encryption (FSE
2001), Lecture Notes in Computer Science, vol. 2355, pp.
109-124, DOI 10.1007/3-540-45473-X_9, 2002,
<https://doi.org/10.1007/3-540-45473-X_9>.
[BM18] Barbosa, M. and P. Farshim, "Indifferentiable
Authenticated Encryption", Advances in Cryptology - CRYPTO
2018, Lecture Notes in Computer Science, vol. 10991, pp.
187-220, DOI 10.1007/978-3-319-96884-1_7, 2018,
<https://doi.org/10.1007/978-3-319-96884-1_7>.
[BMOS17] Barwell, G., Martin, D.P., Oswald, E., and M. Stam,
"Authenticated Encryption in the Face of Protocol and Side
Channel Leakage", Advances in Cryptology - ASIACRYPT 2017,
Lecture Notes in Computer Science, vol. 10624, pp.
693-723, DOI 10.1007/978-3-319-70694-8_24, 2017,
<https://doi.org/10.1007/978-3-319-70694-8_24>.
[BN08] Bellare, M. and C. Namprempre, "Authenticated Encryption:
Relations among Notions and Analysis of the Generic
Composition Paradigm", Journal of Cryptology, vol. 21, pp.
469-491, DOI 10.1007/s00145-008-9026-x, 2008,
<https://doi.org/10.1007/s00145-008-9026-x>.
[BNT19] Bellare, M., Ng, R., and B. Tackmann, "Nonces Are Noticed:
AEAD Revisited", Advances in Cryptology - CRYPTO 2019,
Lecture Notes in Computer Science, vol. 11692, pp.
235-265, DOI 10.1007/978-3-030-26948-7_9, 2019,
<https://doi.org/10.1007/978-3-030-26948-7_9>.
[BPPS17] Berti, F., Pereira, O., Peters, T., and F.-X. Standaert,
"On Leakage-Resilient Authenticated Encryption with
Decryption Leakages", IACR Transactions on Symmetric
Cryptology, vol. 2017, no. 3, pp. 271-293,
DOI 10.13154/tosc.v2017.i3.271-293, 2017,
<https://doi.org/10.13154/tosc.v2017.i3.271-293>.
[BT16] Bellare, M. and B. Tackmann, "The Multi-user Security of
Authenticated Encryption: AES-GCM in TLS 1.3", Advances in
Cryptology - CRYPTO 2016, Lecture Notes in Computer
Science, vol. 9814, pp. 247-276,
DOI 10.1007/978-3-662-53018-4_10, 2016,
<https://doi.org/10.1007/978-3-662-53018-4_10>.
[C20] Chakraborti, A., Datta, N., Jha, A., Mancillas-López, C.,
Nandi, M., and Y. Sasaki, "INT-RUP Secure Lightweight
Parallel AE Modes", IACR Transactions on Symmetric
Cryptology, vol. 2019, no.4, pp. 81-118,
DOI 10.13154/tosc.v2019.i4.81-118, 2020,
<https://doi.org/10.13154/tosc.v2019.i4.81-118>.
[CJRR99] Chari, S., Jutla, C.S., Rao, J.R., and P. Rohatgi,
"Towards Sound Approaches to Counteract Power-Analysis
Attacks", Advances in Cryptology - CRYPTO'99, Lecture
Notes in Computer Science, vol. 1666, pp. 398-412,
DOI 10.1007/3-540-48405-1_26, 1999,
<https://doi.org/10.1007/3-540-48405-1_26>.
[CR22] Chan, J. and P. Rogaway, "On Committing Authenticated-
Encryption", Computer Security - ESORICS 2022, Lecture
Notes in Computer Science, vol. 13555, pp. 275-294,
DOI 10.1007/978-3-031-17146-8_14, 2022,
<https://doi.org/10.1007/978-3-031-17146-8_14>.
[DEMS21a] Dobraunig, C., Eichlseder, M., Mendel, F., and M.
Schläffer, "Ascon v1.2: Lightweight Authenticated
Encryption and Hashing", Journal of Cryptology, vol. 34,
no. 33, DOI 10.1007/s00145-021-09398-9, 2021,
<https://doi.org/10.1007/s00145-021-09398-9>.
[DEMS21b] Dobraunig, C., Eichlseder, M., Mendel, F., and M.
Schläffer, "Ascon v1.2", Submission to the NIST LWC
Competition, 2021.
[DGGP21] Degabriele, J.P., Govinden, J., Günther, F., and K.
Paterson, "The Security of ChaCha20-Poly1305 in the Multi-
User Setting", Proceedings of the 2021 ACM SIGSAC
Conference on Computer and Communications Security (CCS
'21), pp. 1981-2003, DOI 10.1145/3460120.3484814, 2021,
<https://doi.org/10.1145/3460120.3484814>.
[EV17] Endignoux, G. and D. Vizár, "Linking Online Misuse-
Resistant Authenticated Encryption and Blockwise Attack
Models", IACR Transactions on Symmetric Cryptology, vol.
2016, no. 2, pp. 125-144,
DOI 10.13154/TOSC.V2016.I2.125-144, 2017,
<https://doi.org/10.13154/TOSC.V2016.I2.125-144>.
[FFL12] Fleischmann, E., Forler, C., and S. Lucks, "McOE: A Family
of Almost Foolproof On-Line Authenticated Encryption
Schemes", Fast Software Encryption (FSE 2012), Lecture
Notes in Computer Science, vol. 7549, pp. 196-215,
DOI 10.1007/978-3-642-34047-5_12, 2012,
<https://doi.org/10.1007/978-3-642-34047-5_12>.
[FJMV2004] Fouque, P.-A., Joux, A., Martinet, G., and F. Valette,
"Authenticated On-Line Encryption", Selected Areas in
Cryptography (SAC 2003), Lecture Notes in Computer
Science, vol. 3006, DOI 10.1007/978-3-540-24654-1_11,
2004, <https://doi.org/10.1007/978-3-540-24654-1_11>.
[FLLW17] Forler, C., List, E., Lucks, S., and J. Wenzel,
"Reforgeability of Authenticated Encryption Schemes",
Information Security and Privacy (ACISP 2017), Lecture
Notes in Computer Science, vol. 10343, pp. 19-37,
DOI 10.1007/978-3-319-59870-3_2, 2017,
<https://doi.org/10.1007/978-3-319-59870-3_2>.
[FOR17] Farshim, P., Orlandi, C., and R. Rosie, "Security of
Symmetric Primitives under Incorrect Usage of Keys", IACR
Transactions on Symmetric Cryptology, vol. 2017, no. 1,
pp. 449-473, DOI 10.13154/tosc.v2017.i1.449-473, 2017,
<https://doi.org/10.13154/tosc.v2017.i1.449-473>.
[G17] Gagliardoni, T., "Quantum Security of Cryptographic
Primitives", Ph.D. Thesis, Technische Universität
Darmstadt, 2017,
<https://tuprints.ulb.tu-darmstadt.de/6019/>.
[GLR17] Grubbs, P., Lu, J., and T. Ristenpart, "Message Franking
via Committing Authenticated Encryption", Advances in
Cryptology - CRYPTO 2017, Lecture Notes in Computer
Science, vol. 10403, pp. 66-97,
DOI 10.1007/978-3-319-63697-9_3, 2017,
<https://doi.org/10.1007/978-3-319-63697-9_3>.
[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>.
[HKR2015] Hoang, V.T., Krovetz, T., and P. Rogaway, "Robust
Authenticated-Encryption AEZ and the Problem That It
Solves", Advances in Cryptology -- EUROCRYPT 2015, Lecture
Notes in Computer Science, vol. 9056, pp. 15-44,
DOI 10.1007/978-3-662-46800-5_2, 2015,
<https://doi.org/10.1007/978-3-662-46800-5_2>.
[HRRV15] Hoang, VT., Reyhanitabar, R., Rogaway, P., and D. Vizár,
"Online Authenticated-Encryption and its Nonce-Reuse
Misuse-Resistance", Advances in Cryptology -- CRYPTO 2015,
Lecture Notes in Computer Science, vol. 9215, pp. 493-517,
DOI 10.1007/978-3-662-47989-6_24, 2015,
<https://doi.org/10.1007/978-3-662-47989-6_24>.
[HTT18] Hoang, V.T., Tessaro, S., and A. Thiruvengadam, "The
Multi-user Security of GCM, Revisited: Tight Bounds for
Nonce Randomization", Proceedings of the 2018 ACM SIGSAC
Conference on Computer and Communications Security (CCS
'18), pp. 1429-1440, DOI 10.1145/3243734.3243816, 2018,
<https://doi.org/10.1145/3243734.3243816>.
[IIM25] Inoue, A., Iwata, T., and K. Minematsu, "Comprehensive
Robustness Analysis of GCM, CCM, and OCB3", Topics in
Cryptology - CT-RSA 2025, Lecture Notes in Computer
Science, vol. 15598, DOI 10.1007/978-3-031-88661-4_4,
2025, <https://doi.org/10.1007/978-3-031-88661-4_4>.
[JMV2002] Joux, A., Martinet, G., and F. Valette, "Blockwise-
Adaptive Attackers Revisiting the (In)Security of Some
Provably Secure Encryption Modes: CBC, GEM, IACBC",
Advances in Cryptology - CRYPTO 2002, Lecture Notes in
Computer Science, vol. 2442, DOI 10.1007/3-540-45708-9_2,
2002, <https://doi.org/10.1007/3-540-45708-9_2>.
[JNPS21] Jean, M., Nikolić, I., Peyrin, T., and Y. Seurin, "The
Deoxys AEAD family", Journal of Cryptology, vol. 34, no.
31, DOI 10.1007/s00145-021-09397-w, 2021,
<https://doi.org/10.1007/s00145-021-09397-w>.
[KLLNP16] Menda, M., Leurent, G., Leverrier, A., and M. Naya-
Plasencia, "Quantum Differential and Linear
Cryptanalysis", IACR Transactions on Symmetric Cryptology,
vol. 2016, no.1, pp. 71-94,
DOI 10.13154/tosc.v2016.i1.71-94, 2016,
<https://doi.org/10.13154/tosc.v2016.i1.71-94>.
[LGR21] Len, J., Grubbs, P., and T. Ristenpart, "Partitioning
Oracle Attacks", 30th USENIX Security Symposium (USENIX
Security 21), pp. 195-212, 2021.
[LMP17] Luykx, A., Mennink, B., and K. Paterson, "Analyzing Multi-
key Security Degradation", Advances in Cryptology -
ASIACRYPT 2017, Lecture Notes in Computer Science, vol.
10625, pp. 575-605, DOI 10.1007/978-3-319-70697-9_20,
2017, <https://doi.org/10.1007/978-3-319-70697-9_20>.
[M05] McGrew, D., "Efficient authentication of large, dynamic
data sets using Galois/Counter Mode (GCM)", Third IEEE
International Security in Storage Workshop (SISW'05), pp.
6-94, DOI 10.1109/SISW.2005.3, 2005,
<https://doi.org/10.1109/SISW.2005.3>.
[MBTM17] McKay, K., Bassham, L., Turan, MS., and N. Mouha, "Report
on Lightweight Cryptography", NISTIR 8114,
DOI 10.6028/NIST.IR.8114, 2017,
<https://doi.org/10.6028/NIST.IR.8114>.
[MLGR23] Menda, S., Julia, J., Grubbs, P., and T. Ristenpart,
"Context Discovery and Commitment Attacks: How to Break
CCM, EAX, SIV, and More", Advances in Cryptology -
EUROCRYPT 2023, Lecture Notes in Computer Science, vol.
14007, pp. 379-407, DOI 10.1007/978-3-031-30634-1_13,
2023, <https://doi.org/10.1007/978-3-031-30634-1_13>.
[R02] Rogaway, P., "Authenticated-encryption with associated-
data", Proceedings of the 9th ACM Conference on Computer
and Communications Security (CCS '02), pp. 98-107,
DOI 10.1145/586110.586125, 2002,
<https://doi.org/10.1145/586110.586125>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005,
<https://www.rfc-editor.org/info/rfc4303>.
[RFC7253] Krovetz, T. and P. Rogaway, "The OCB Authenticated-
Encryption Algorithm", RFC 7253, DOI 10.17487/RFC7253, May
2014, <https://www.rfc-editor.org/info/rfc7253>.
[RFC8221] Wouters, P., Migault, D., Mattsson, J., Nir, Y., and T.
Kivinen, "Cryptographic Algorithm Implementation
Requirements and Usage Guidance for Encapsulating Security
Payload (ESP) and Authentication Header (AH)", RFC 8221,
DOI 10.17487/RFC8221, October 2017,
<https://www.rfc-editor.org/info/rfc8221>.
[RFC8439] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF
Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018,
<https://www.rfc-editor.org/info/rfc8439>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC8452] Gueron, S., Langley, A., and Y. Lindell, "AES-GCM-SIV:
Nonce Misuse-Resistant Authenticated Encryption",
RFC 8452, DOI 10.17487/RFC8452, April 2019,
<https://www.rfc-editor.org/info/rfc8452>.
[RFC8645] Smyshlyaev, S., Ed., "Re-keying Mechanisms for Symmetric
Keys", RFC 8645, DOI 10.17487/RFC8645, August 2019,
<https://www.rfc-editor.org/info/rfc8645>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/info/rfc9000>.
[RFC9058] Smyshlyaev, S., Ed., Nozdrunov, V., Shishkin, V., and E.
Griboedova, "Multilinear Galois Mode (MGM)", RFC 9058,
DOI 10.17487/RFC9058, June 2021,
<https://www.rfc-editor.org/info/rfc9058>.
[RS06] Rogaway, R. and T. Shrimpton, "A Provable-Security
Treatment of the Key-Wrap Problem", Advances in Cryptology
- EUROCRYPT 2006, Lecture Notes in Computer Science, vol.
4004, pp. 373-390, DOI 10.1007/11761679_23, 2016,
<https://doi.org/10.1007/11761679_23>.
[S04] Shrimpton, T., "A Characterization of Authenticated-
Encryption as a Form of Chosen-Ciphertext Security",
Cryptology ePrint Archive, Paper 2004/272, 2004,
<https://eprint.iacr.org/2004/272>.
[SY16] Sasaki, Y. and K. Yasuda, "A New Mode of Operation for
Incremental Authenticated Encryption with Associated
Data", Selected Areas in Cryptography - SAC 2015, Lecture
Notes in Computer Science, vol. 9566, pp. 397-416,
DOI 10.1007/978-3-319-31301-6_23, 2016,
<https://doi.org/10.1007/978-3-319-31301-6_23>.
[YSS23] Naito, Y., Sasaki, Y., and T. Sugawara, "Committing
Security of Ascon: Cryptanalysis on Primitive and Proof on
Mode", IACR Transactions on Symmetric Cryptology, vol.
2023, no. 4, pp. 420-451,
DOI 10.46586/tosc.v2023.i4.420-451, 2023,
<https://doi.org/10.46586/tosc.v2023.i4.420-451>.
In this section, we briefly discuss AEAD algorithms that provide additional functionality. As noted in Section 4.1, each additional functionality requires a redefinition of the conventional AEAD interface; thus, each additional functionality property defines a new class of cryptographic algorithms.
このセクションでは、追加の機能を提供するAEADアルゴリズムについて簡単に説明します。セクション4.1で述べたように、追加の各機能には、従来のAEADインターフェイスの再定義が必要です。したがって、各追加機能プロパティは、暗号化アルゴリズムの新しいクラスを定義します。
Most importantly, for every AEAD class with additional functionality, conventional security properties must be redefined concerning the targeted additional functionality and the new interface. Although it might be possible to consider a particular AEAD algorithm with additional functionality as a conventional AEAD algorithm and study it for the conventional confidentiality and integrity, security (or insecurity) in that sense won't be sufficient to label that algorithm as a secure (or insecure) additional functionality AEAD. Only security in the sense of the redefined conventional properties would suffice.
最も重要なことは、追加の機能を備えたすべてのAEADクラスについて、ターゲットを絞った追加機能と新しいインターフェイスに関して、従来のセキュリティプロパティを再定義する必要があることです。追加の機能を備えた特定のAEADアルゴリズムを従来のAEADアルゴリズムとして考慮し、従来の機密性と整合性、セキュリティ（または不安）について研究することは、そのアルゴリズムを安全な（または不安定な）追加機能としてラベル付けするのに十分ではありません。再定義された従来の特性の意味でのセキュリティのみで十分です。
For the examples given in this section, we leave it out of scope how to concretely redefine conventional security for these classes; we only briefly describe the additional functionality they offer and provide further references.
このセクションに記載されている例については、これらのクラスの従来のセキュリティを具体的に再定義する方法を範囲外に除外します。彼らが提供する追加の機能について簡単に説明し、さらなる参照を提供します。
Definition:
意味：
For a message that only partly differs from some previous message, an AEAD algorithm allows re-encrypting and authenticating that message (associated data and a plaintext pair) faster than processing it from scratch.
以前のメッセージとは部分的にしか違いないメッセージの場合、AEADアルゴリズムは、そのメッセージ（関連するデータと平文ペア）をゼロから処理するよりも速く再暗号化および認証することを可能にします。
Examples:
例：
Incremental AEAD algorithm of [SY16]
[SY16]の増分AEADアルゴリズム
Security notions:
セキュリティの概念：
Privacy, authenticity [SY16]
プライバシー、信頼性[SY16]
Notes:
注：
When compared with conventional AEAD, the interface of an incremental AEAD algorithm is usually expanded with several operations, which perform different types of updates. For example, one can consider operations such as "Append" or "Chop", which provide a straightforward additional functionality. A comprehensive definition of an incremental AEAD interface is provided in [SY16].
従来のAEADと比較すると、増分AEADアルゴリズムのインターフェイスは通常、さまざまな種類の更新を実行するいくつかの操作で拡張されます。たとえば、単純な追加機能を提供する「追加」や「チョップ」などの操作を考慮することができます。[SY16]には、増分AEADインターフェイスの包括的な定義が提供されています。
Further reading:
さらに読む：
[SY16], [M05], [BKY02]
[Sy16]、[M05]、[BKY02]
Definition:
意味：
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.
AEADアルゴリズムを使用すると、ユーザーは、暗号化操作への入力とともに、目的の暗号文拡張（プレーンテキストの長さと対応する暗号文の差）を選択できます。この機能により、同じアルゴリズムの実装を使用しながら、特定のアプリケーションごとに、暗号文の拡張に依存する目的のデータ整合性保証の規制が可能になります。
Examples:
例：
AEZ [HKR2015]
aez [hkr2015]
Security notions:
セキュリティの概念：
Robust Authenticated Encryption (RAE) [HKR2015]
堅牢な認証された暗号化（RAE）[HKR2015]
Notes:
注：
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.
堅牢なAEADアルゴリズムのセキュリティ目標は、小さな暗号文の拡張（ストレッチと呼ばれる）であっても、可能な限り最高のセキュリティを確保することです。たとえば、Ciphertextを鍛造する確率は1/256以上であるため、従来の完全性のために1バイトのストレッチでAEADアルゴリズムを分析すると、不安が明らかになります。それにもかかわらず、堅牢なAEADの観点から、1バイトの暗号文の拡張にそのような偽造確率を持つアルゴリズムは安全であり、そのシナリオで最も達成可能なセキュリティを表しています。
Further reading:
さらに読む：
[HKR2015]
[HKR2015]
This document benefited greatly from the comments received from the CFRG community, for which we are very grateful. We would also like to extend special appreciation to Liliya Akhmetzyanova, Evgeny Alekseev, Alexandra Babueva, Frank Denis, Kirill Kutsenok, Sergey Kyazhin, Samuel Lucas, Grigory Marshalko, Christopher Patton, and Christopher Wood for their thoughtful comments, proposals, and discussions.
この文書は、CFRGコミュニティから受け取ったコメントから大きな恩恵を受けました。また、リリヤ・アフッツィヤノヴァ、エフゲニー・アレクセフ、アレクサンドラ・バブエバ、フランク・デニス、キリル・クッツェノク、セルゲイ・キャズヒン、サミュエル・ルーカス、グリゴリー・マーシャルコ、クリストファー・パットン、クリストポッパー・ウッドに、思慮深いコメントを求めて、提案することに特別な感謝を拡大したいと思います。
Andrey Bozhko (editor)
CryptoPro
Email: andbogc@gmail.com