RFC5116 日本語訳
5116 An Interface and Algorithms for Authenticated Encryption. D.McGrew. January 2008. (Format: TXT=50539 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group D. McGrew Request for Comments: 5116 Cisco Systems, Inc. Category: Standards Track January 2008
コメントを求めるワーキンググループD.マグリュー要求をネットワークでつないでください: 5116年のシスコシステムズInc.カテゴリ: 標準化過程2008年1月
An Interface and Algorithms for Authenticated Encryption
認証された暗号化のためのインタフェースとアルゴリズム
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
This document defines algorithms for Authenticated Encryption with Associated Data (AEAD), and defines a uniform interface and a registry for such algorithms. The interface and registry can be used as an application-independent set of cryptoalgorithm suites. This approach provides advantages in efficiency and security, and promotes the reuse of crypto implementations.
このドキュメントは、Authenticated EncryptionのためにAssociated Data(AEAD)と共にアルゴリズムを定義して、そのようなアルゴリズムのために一定のインタフェースと登録を定義します。アプリケーションから独立しているセットのcryptoalgorithmスイートとしてインタフェースと登録は使用できます。 このアプローチは、効率とセキュリティに利点を提供して、暗号実装の再利用を促進します。
McGrew Standards Track [Page 1] RFC 5116 Authenticated Encryption January 2008
暗号化2008年1月に認証されたマグリュー標準化過程[1ページ]RFC5116
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4. Conventions Used in This Document . . . . . . . . . . . . 4
2. AEAD Interface . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Authenticated Encryption . . . . . . . . . . . . . . . . . 5
2.2. Authenticated Decryption . . . . . . . . . . . . . . . . . 7
2.3. Data Formatting . . . . . . . . . . . . . . . . . . . . . 7
3. Guidance on the Use of AEAD Algorithms . . . . . . . . . . . . 8
3.1. Requirements on Nonce Generation . . . . . . . . . . . . . 8
3.2. Recommended Nonce Formation . . . . . . . . . . . . . . . 9
3.2.1. Partially Implicit Nonces . . . . . . . . . . . . . . 10
3.3. Construction of AEAD Inputs . . . . . . . . . . . . . . . 11
3.4. Example Usage . . . . . . . . . . . . . . . . . . . . . . 11
4. Requirements on AEAD Algorithm Specifications . . . . . . . . 12
5. AEAD Algorithms . . . . . . . . . . . . . . . . . . . . . . . 14
5.1. AEAD_AES_128_GCM . . . . . . . . . . . . . . . . . . . . . 14
5.1.1. Nonce Reuse . . . . . . . . . . . . . . . . . . . . . 14
5.2. AEAD_AES_256_GCM . . . . . . . . . . . . . . . . . . . . . 15
5.3. AEAD_AES_128_CCM . . . . . . . . . . . . . . . . . . . . . 15
5.3.1. Nonce Reuse . . . . . . . . . . . . . . . . . . . . . 16
5.4. AEAD_AES_256_CCM . . . . . . . . . . . . . . . . . . . . . 16
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
7. Other Considerations . . . . . . . . . . . . . . . . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . . 19
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1。 バックグラウンド. . . . . . . . . . . . . . . . . . . . . . . . 3 1.2。 範囲. . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3。 利益. . . . . . . . . . . . . . . . . . . . . . . . . 4 1.4。 コンベンションは本書では.4 2を使用しました。 AEADは.52.1を連結します。 暗号化. . . . . . . . . . . . . . . . . 5 2.2を認証しました。 復号化. . . . . . . . . . . . . . . . . 7 2.3を認証しました。 データ形式. . . . . . . . . . . . . . . . . . . . . 7 3。 AEADアルゴリズム. . . . . . . . . . . . 8 3.1の使用の指導。 一回だけの世代. . . . . . . . . . . . . 8 3.2に関する要件。 お勧めの一回だけの構成. . . . . . . . . . . . . . . 9 3.2.1。 部分的に暗黙の一回だけ. . . . . . . . . . . . . . 10 3.3。 AEADの構造は.113.4を入力します。 例の用法. . . . . . . . . . . . . . . . . . . . . . 11 4。 AEADアルゴリズム仕様. . . . . . . . 12 5に関する要件。 AEADアルゴリズム. . . . . . . . . . . . . . . . . . . . . . . 14 5.1。 AEAD_AES_128_GCM. . . . . . . . . . . . . . . . . . . . . 14 5.1.1。 一回だけの再利用. . . . . . . . . . . . . . . . . . . . . 14 5.2。 AEAD_AES_256_GCM. . . . . . . . . . . . . . . . . . . . . 15 5.3。 AEAD_AES_128_立方センチメートル. . . . . . . . . . . . . . . . . . . . . 15 5.3.1。 一回だけの再利用. . . . . . . . . . . . . . . . . . . . . 16 5.4。 AEAD_AES_256_立方センチメートル. . . . . . . . . . . . . . . . . . . . . 16 6。 IANA問題. . . . . . . . . . . . . . . . . . . . . 16 7。 他の問題. . . . . . . . . . . . . . . . . . . . . 17 8。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 18 9。 承認. . . . . . . . . . . . . . . . . . . . . . . 18 10。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 19 10.1。 引用規格. . . . . . . . . . . . . . . . . . . 19 10.2。 有益な参照. . . . . . . . . . . . . . . . . . 19
McGrew Standards Track [Page 2] RFC 5116 Authenticated Encryption January 2008
暗号化2008年1月に認証されたマグリュー標準化過程[2ページ]RFC5116
1. Introduction
1. 序論
Authenticated encryption [BN00] is a form of encryption that, in addition to providing confidentiality for the plaintext that is encrypted, provides a way to check its integrity and authenticity. Authenticated Encryption with Associated Data, or AEAD [R02], adds the ability to check the integrity and authenticity of some Associated Data (AD), also called "additional authenticated data", that is not encrypted.
認証された暗号化[BN00]は暗号化された平文に秘密性を提供することに加えてその保全と信憑性をチェックする方法を提供する暗号化のフォームです。 Associated Dataと認証されたEncryption、またはAEAD[R02]がまた、「追加認証されたデータ」と呼ばれるいくらかの暗号化されなかったAssociated Data(AD)の保全と信憑性をチェックする能力を加えます。
1.1. Background
1.1. バックグラウンド
Many cryptographic applications require both confidentiality and message authentication. Confidentiality is a security service that ensures that data is available only to those authorized to obtain it; usually it is realized through encryption. Message authentication is the service that ensures that data has not been altered or forged by unauthorized entities; it can be achieved by using a Message Authentication Code (MAC). This service is also called data integrity. Many applications use an encryption method and a MAC together to provide both of those security services, with each algorithm using an independent key. More recently, the idea of providing both security services using a single cryptoalgorithm has become accepted. In this concept, the cipher and MAC are replaced by an Authenticated Encryption with Associated Data (AEAD) algorithm.
多くの暗号のアプリケーションが秘密性と通報認証の両方を必要とします。 秘密性はデータがそれを得るのが認可されたものだけに利用可能であることを確実にするセキュリティー・サービスです。 通常、それは暗号化で実感されます。 通報認証はデータが権限のない実体によって変更もされませんし、作り出されてもいないのを確実にするサービスです。 メッセージ立証コード(MAC)を使用することによって、それを達成できます。 また、このサービスはデータ保全と呼ばれます。 多くのアプリケーションがそれらのセキュリティー・サービスの両方を提供するのに暗号化メソッドとMACを一緒に使用します、各アルゴリズムが独立しているキーを使用していて。 より最近、単一のcryptoalgorithmを使用することで両方のセキュリティー・サービスを提供するという考えは受け入れるようになりました。 この概念では、Associated Data(AEAD)アルゴリズムで暗号とMACをAuthenticated Encryptionに取り替えます。
Several crypto algorithms that implement AEAD algorithms have been defined, including block cipher modes of operation and dedicated algorithms. Some of these algorithms have been adopted and proven useful in practice. Additionally, AEAD is close to an 'idealized' view of encryption, such as those used in the automated analysis of cryptographic protocols (see, for example, Section 2.5 of [BOYD]).
AEADにアルゴリズムを実装するいくつかの暗号アルゴリズムが定義されました、ブロック暗号運転モードとひたむきなアルゴリズムを含んでいて。これらのアルゴリズムのいくつかが、採用されて、実際には有用であることが分かりました。 さらに、暗号化の'理想化された'視点の近くにAEADがあります、暗号のプロトコルの自動分析法に使用されるものなどのように(例えば、見てください、[ボイド]のセクション2.5)。
The benefits of AEAD algorithms, and this interface, are outlined in Section 1.3.
AEADアルゴリズムの利益、およびこのインタフェースはセクション1.3に概説されています。
1.2. Scope
1.2. 範囲
In this document, we define an AEAD algorithm as an abstraction, by specifying an interface to an AEAD and defining an IANA registry for AEAD algorithms. We populate this registry with four AEAD algorithms based on the Advanced Encryption Standard (AES) in Galois/Counter Mode [GCM] with 128- and 256-bit keys, and AES in Counter and CBC MAC Mode [CCM] with 128- and 256-bit keys.
本書では、私たちはAEADアルゴリズムを抽象化と定義します、AEADにインタフェースを指定して、AEADアルゴリズムのためにIANA登録を定義することによって。私たちはガロア/カウンタMode[GCM]で128でエー・イー・エス(AES)に基づく、4つのAEADアルゴリズム、256ビットのキー、およびAESと共にCounterとCBC MAC Mode[CCM]で128と256ビットのキーでこの登録に居住します。
In the following, we define the AEAD interface (Section 2), and then provide guidance on the use of AEAD algorithms (Section 3), and outline the requirements that each AEAD algorithm must meet
以下では、次に、私たちは、AEADインタフェース(セクション2)を定義して、AEADアルゴリズム(セクション3)の使用のときに指導を提供して、それぞれのAEADアルゴリズムに満たされなければならないという要件について概説します。
McGrew Standards Track [Page 3] RFC 5116 Authenticated Encryption January 2008
暗号化2008年1月に認証されたマグリュー標準化過程[3ページ]RFC5116
(Section 4). Then we define several AEAD algorithms (Section 5), and establish an IANA registry for AEAD algorithms (Section 6). Lastly, we discuss some other considerations (Section 7).
(セクション4。) 次に、私たちは、いくつかのAEADアルゴリズム(セクション5)を定義して、AEADアルゴリズム(セクション6)のためにIANA登録を確立します。 最後に、私たちはある他の問題(セクション7)について議論します。
The AEAD interface specification does not address security protocol issues such as anti-replay services or access control decisions that are made on authenticated data. Instead, the specification aims to abstract the cryptography away from those issues. The interface, and the guidance about how to use it, are consistent with the recommendations from [EEM04].
反再生サービスかオンにされるアクセス制御決定がデータを認証したので、AEADインターフェース仕様はセキュリティプロトコル問題にそのようなものを扱いません。 代わりに、仕様はそれらの問題から遠くの暗号を要約に目的とします。 インタフェース、およびどうそれを使用するかに関する指導は[EEM04]からの推薦と一致しています。
1.3. Benefits
1.3. 利益
The AEAD approach enables applications that need cryptographic security services to more easily adopt those services. It benefits the application designer by allowing them to focus on important issues such as security services, canonicalization, and data marshaling, and relieving them of the need to design crypto mechanisms that meet their security goals. Importantly, the security of an AEAD algorithm can be analyzed independent from its use in a particular application. This property frees the user of the AEAD of the need to consider security aspects such as the relative order of authentication and encryption and the security of the particular combination of cipher and MAC, such as the potential loss of confidentiality through the MAC. The application designer that uses the AEAD interface need not select a particular AEAD algorithm during the design stage. Additionally, the interface to the AEAD is relatively simple, since it requires only a single key as input and requires only a single identifier to indicate the algorithm in use in a particular case.
AEADアプローチは、暗号のセキュリティー・サービスを必要とするアプリケーションが、より容易にそれらのサービスを採用するのを可能にします。 整理して、それらのセキュリティ目標を達成する暗号メカニズムを設計する必要性をそれらに取り除くセキュリティー・サービスや、canonicalizationや、データなどの切迫した課題に焦点を合わせるのが、それらを許容することによって、アプリケーション設計者のためになります。 重要に、特定用途における使用によって独立していた状態でAEADアルゴリズムのセキュリティを分析できます。 この特性は認証と暗号化の相対オーダや暗号とMACの特定の組み合わせのセキュリティなどのセキュリティ局面を考える必要性のAEADのユーザを解放します、MACを通した秘密性の潜在的損失などのように。 AEADインタフェースを使用するアプリケーション設計者は設計段階の間、特定のAEADアルゴリズムを選択する必要はありません。 さらに、AEADへのインタフェースは比較的簡単です、特定の場合で使用中のアルゴリズムを示すのが入力されるように単一のキーだけを必要として、ただ一つの識別子だけを必要とするので。
The AEAD approach benefits the implementer of the crypto algorithms by making available optimizations that are otherwise not possible to reduce the amount of computation, the implementation cost, and/or the storage requirements. The simpler interface makes testing easier; this is a considerable benefit for a crypto algorithm implementation. By providing a uniform interface to access cryptographic services, the AEAD approach allows a single crypto implementation to more easily support multiple applications. For example, a hardware module that supports the AEAD interface can easily provide crypto acceleration to any application using that interface, even to applications that had not been designed when the module was built.
AEADアプローチは、そうでなければ計算の量、実装費用、そして/または、ストレージ要件を減らすのにおいて可能でない利用可能な最適化をすることによって、暗号アルゴリズムのimplementerのためになります。 より簡単なインタフェースで、テストは、より簡単になります。 これは暗号アルゴリズム実装のためのかなりの利益です。 暗号のサービスにアクセスするために一定のインタフェースを提供することによって、ただ一つの暗号実装はAEADアプローチで、より容易に複数のアプリケーションをサポートすることができます。 例えば、AEADインタフェースをサポートするハードウェアモジュールはそのインタフェースを使用することで暗号加速を容易にどんなアプリケーションにも提供できます、モジュールが築き上げられたとき設計されていなかったアプリケーションにさえ。
1.4. Conventions Used in This Document
1.4. 本書では使用されるコンベンション
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
McGrew Standards Track [Page 4] RFC 5116 Authenticated Encryption January 2008
暗号化2008年1月に認証されたマグリュー標準化過程[4ページ]RFC5116
2. AEAD Interface
2. AEADインタフェース
An AEAD algorithm has two operations, authenticated encryption and authenticated decryption. The inputs and outputs of these algorithms are defined below in terms of octet strings.
AEADアルゴリズムには、2つの操作、認証された暗号化、および認証された復号化があります。 これらのアルゴリズムの入力と出力は以下で八重奏ストリングで定義されます。
An implementation MAY accept additional inputs. For example, an input could be provided to allow the user to select between different implementation strategies. However, such extensions MUST NOT affect interoperability with other implementations.
実装は追加入力を受け入れるかもしれません。 例えば、異なった実装戦略の間で選ぶユーザを許容するために入力を提供できました。 しかしながら、そのような拡大は他の実装で相互運用性に影響してはいけません。
2.1. Authenticated Encryption
2.1. 認証された暗号化
The authenticated encryption operation has four inputs, each of which is an octet string:
認証された暗号化操作には、4つの入力があります:それはそれぞれ八重奏ストリングです。
A secret key K, which MUST be generated in a way that is uniformly
random or pseudorandom.
秘密鍵K。(一様に無作為の道か擬似ランダムでそのKを生成しなければなりません)。
A nonce N. Each nonce provided to distinct invocations of the
Authenticated Encryption operation MUST be distinct, for any
particular value of the key, unless each and every nonce is zero-
length. Applications that can generate distinct nonces SHOULD use
the nonce formation method defined in Section 3.2, and MAY use any
other method that meets the uniqueness requirement. Other
applications SHOULD use zero-length nonces.
Authenticated Encryption操作の異なった実施に提供された一回だけのN.Each一回だけは異なるに違いありません、キーのどんな特定の値のためにも、一回だけがありとあらゆる無の長さでないなら。 異なった一回だけがSHOULDであると生成することができるアプリケーションは、セクション3.2で定義された一回だけの構成メソッドを使用して、ユニークさの必要条件を満たすいかなる他のメソッドも使用するかもしれません。 他のアプリケーションSHOULDはゼロ・レングス一回だけを使用します。
A plaintext P, which contains the data to be encrypted and
authenticated.
平文P。(その平文は暗号化された、認証されるべきデータを含みます)。
The associated data A, which contains the data to be
authenticated, but not encrypted.
関連データA。(その関連データは認証されましたが、暗号化されるべきでないデータを含みます)。
There is a single output:
ただ一つの出力があります:
A ciphertext C, which is at least as long as the plaintext, or
または暗号文C。(それは、平文と少なくとも同じくらい長いです)。
an indication that the requested encryption operation could not be
performed.
要求された暗号化操作を実行できなかったという指示。
All of the inputs and outputs are variable-length octet strings, whose lengths obey the following restrictions:
入力と出力のすべてが長さが以下の制限に従う可変長の八重奏ストリングです:
The number of octets in the key K is between 1 and 255. For each
AEAD algorithm, the length of K MUST be fixed.
主要なKにおける、八重奏の数は、1〜255です。 それぞれのAEADアルゴリズムにおいて、Kの長さを固定しなければなりません。
McGrew Standards Track [Page 5] RFC 5116 Authenticated Encryption January 2008
暗号化2008年1月に認証されたマグリュー標準化過程[5ページ]RFC5116
For any particular value of the key, either 1) each nonce provided
to distinct invocations of the Authenticated Encryption operation
MUST be distinct, or 2) each and every nonce MUST be zero-length.
If zero-length nonces are used with a particular key, then each
and every nonce used with that key MUST have a length of zero.
Otherwise, the number of octets in the nonce SHOULD be twelve
(12). Nonces with different lengths MAY be used with a particular
key. Some algorithms cannot be used with zero-length nonces, but
others can; see Section 4. Applications that conform to the
recommended nonce length will avoid having to construct nonces
with different lengths, depending on the algorithm that is in use.
This guidance helps to keep algorithm-specific logic out of
applications.
キーのどんな特定の値のためにも、各一回だけがAuthenticated Encryption操作の異なった実施に提供した1は)異なるに違いありませんか、それぞれ2と)あらゆる一回だけがゼロ・レングスでなければなりません。 ゼロ・レングス一回だけが特定のキーと共に使用されるなら、そのキーと共に使用されるありとあらゆる一回だけがゼロの長さを持たなければなりません。 そうでなければ、数、一回だけのSHOULDの八重奏では、12(12)になってください。 異なった長さがある一回だけは特定のキーと共に使用されるかもしれません。 ゼロ・レングス一回だけと共にいくつかのアルゴリズムを使用できませんが、他のものは使用できます。 セクション4を見てください。 お勧めの一回だけの長さに従うアプリケーションは、異なった長さで一回だけを組み立てなければならないのを避けるでしょう、使用中のアルゴリズムによって。 この指導は、アルゴリズム特有の論理をアプリケーションに入れないようにするのを助けます。
The number of octets in the plaintext P MAY be zero.
平文Pにおける、八重奏の数はゼロであるかもしれません。
The number of octets in the associated data A MAY be zero.
関連データAの八重奏の数はゼロであるかもしれません。
The number of octets in the ciphertext C MAY be zero.
暗号文Cにおける、八重奏の数はゼロであるかもしれません。
This specification does not put a maximum length on the nonce, the plaintext, the ciphertext, or the additional authenticated data. However, a particular AEAD algorithm MAY further restrict the lengths of those inputs and outputs. A particular AEAD implementation MAY further restrict the lengths of its inputs and outputs. If a particular implementation of an AEAD algorithm is requested to process an input that is outside the range of admissible lengths, or an input that is outside the range of lengths supported by that implementation, it MUST return an error code and it MUST NOT output any other information. In particular, partially encrypted or partially decrypted data MUST NOT be returned.
この仕様は一回だけ、平文、暗号文、または追加認証されたデータに最大の長さを載せません。 しかしながら、特定のAEADアルゴリズムはさらにそれらの入力と出力の長さを制限するかもしれません。 特定のAEAD実装はさらにその入力と出力の長さを制限するかもしれません。 AEADアルゴリズムの特定の実装が容認できる長さの範囲の外にある入力、またはその実装によってサポートされた長さの範囲の外にある入力を処理するよう要求されるなら、エラーコードを返さなければなりません、そして、いかなる他の情報も出力してはいけません。 特に、部分的に暗号化されたか部分的に解読されたデータを返してはいけません。
Both confidentiality and message authentication are provided on the plaintext P. When the length of P is zero, the AEAD algorithm acts as a Message Authentication Code on the input A.
秘密性と通報認証の両方はPの長さが平文P.Whenでは、ゼロであるかどうかということです、入力Aに関するメッセージ立証コードとしてのAEADアルゴリズム条例。
The associated data A is used to protect information that needs to be authenticated, but does not need to be kept confidential. When using an AEAD to secure a network protocol, for example, this input could include addresses, ports, sequence numbers, protocol version numbers, and other fields that indicate how the plaintext or ciphertext should be handled, forwarded, or processed. In many situations, it is desirable to authenticate these fields, though they must be left in the clear to allow the network or system to function properly. When this data is included in the input A, authentication is provided without copying the data into the plaintext.
関連データAは、認証されるのが必要ですが、秘密にされる必要はない情報を保護するのに使用されます。 ネットワーク・プロトコルを保証するのにAEADを使用するとき、例えば、この入力は平文か暗号文を扱うべきであるか、進めるべきであるか、またはどう処理するべきであるかを示すアドレス、ポート、一連番号、プロトコルバージョン番号、および他の分野を含むかもしれません。 多くの状況で、これらの分野を認証するのは望ましいです、明確にネットワークかシステムが適切に機能するのを許容するのをそれらを残さなければなりませんが。 入力Aにこのデータを含んでいるとき、平文にデータをコピーしないで、認証を提供します。
McGrew Standards Track [Page 6] RFC 5116 Authenticated Encryption January 2008
暗号化2008年1月に認証されたマグリュー標準化過程[6ページ]RFC5116
The secret key K MUST NOT be included in any of the other inputs (N, P, and A). (This restriction does not mean that the values of those inputs must be checked to ensure that they do not include substrings that match the key; instead, it means that the key must not be explicitly copied into those inputs.)
他の入力(N、P、およびA)のいずれにも秘密鍵Kを含んではいけません。 (この制限は、キーに合っているサブストリングを含んでいないのを保証するためにそれらの入力の値をチェックしなければならないことを意味しません; 代わりに、それは、明らかにそれらの入力にキーをコピーしてはいけないことを意味します。)
The nonce is authenticated internally to the algorithm, and it is not necessary to include it in the AD input. The nonce MAY be included in P or A if it is convenient to the application.
一回だけは内部的にアルゴリズムに認証されます、そして、AD入力にそれを含むのは必要ではありません。 アプリケーションに都合がよければ、一回だけはPかAに含まれるかもしれません。
The nonce MAY be stored or transported with the ciphertext, or it MAY be reconstructed immediately prior to the authenticated decryption operation. It is sufficient to provide the decryption module with enough information to allow it to construct the nonce. (For example, a system could use a nonce consisting of a sequence number in a particular format, in which case it could be inferred from the order of the ciphertexts.) Because the authenticated decryption process detects incorrect nonce values, no security failure will result if a nonce is incorrectly reconstructed and fed into an authenticated decryption operation. Any nonce reconstruction method will need to take into account the possibility of loss or reorder of ciphertexts between the encryption and decryption processes.
一回だけが、暗号文で保存されるか、輸送されるかもしれません、またはそれは認証された復号化操作のすぐ前に再建されるかもしれません。 一回だけを組み立てるのを許容できるくらいの情報を復号化モジュールに提供するのは十分です。 (例えば、システムは特定の形式で一連番号から成る一回だけを使用するかもしれなくて、その場合、暗号文の注文からそれは推論できました。) 認証された復号化プロセスが不正確な一回だけの値を検出するので、一回だけが認証された復号化操作に不当に再建されて、食べさせられると、セキュリティ失敗は全く結果として生じないでしょう。 どんな一回だけの再建メソッドも、暗号化と復号化プロセスの間の暗号文の損失か追加注文の可能性を考慮に入れる必要があるでしょう。
Applications MUST NOT assume any particular structure or formatting of the ciphertext.
アプリケーションは暗号文のどんな特定の構造か形式も仮定してはいけません。
2.2. Authenticated Decryption
2.2. 認証された復号化
The authenticated decryption operation has four inputs: K, N, A, and C, as defined above. It has only a single output, either a plaintext value P or a special symbol FAIL that indicates that the inputs are not authentic. A ciphertext C, a nonce N, and associated data A are authentic for key K when C is generated by the encrypt operation with inputs K, N, P, and A, for some values of N, P, and A. The authenticated decrypt operation will, with high probability, return FAIL whenever the inputs N, P, and A were crafted by a nonce- respecting adversary that does not know the secret key (assuming that the AEAD algorithm is secure).
認証された復号化操作には、4つの入力があります: 上で定義されるとしてのK、N、A、およびC。 それには、ただ一つの出力しかなくて、平文値Pか特別なシンボルのどちらかが入力が正統でないことを示すFAILです。 Cが生成されるとき、キーKに、暗号文C、一回だけN、および関連データAが正統である、A、入力Kで操作を暗号化してください、N、P、A. N、P、および認証のいくつかの値のために、操作が意志であると解読してください、高い確率で、入力N、P、およびAが秘密鍵を知らない敵を尊敬しながら(AEADアルゴリズムが安全であると仮定して)一回だけによって作られたときはいつも、リターンFAIL。
2.3. Data Formatting
2.3. データ形式
This document does not specify any particular encoding for the AEAD inputs and outputs, since the encoding does not affect the security services provided by an AEAD algorithm.
このドキュメントはAEAD入力と出力のためのどんな特定のコード化も指定しません、コード化がAEADアルゴリズムで提供されたセキュリティー・サービスに影響しないので。
When choosing the format of application data, an application SHOULD position the ciphertext C so that it appears after any other data that is needed to construct the other inputs to the authenticated
アプリケーションデータの形式を選ぶアプリケーションSHOULDが暗号文Cを置くのでいかなる他のデータの後にもそれが他の入力を認証に構成するのに必要であるように見える場合
McGrew Standards Track [Page 7] RFC 5116 Authenticated Encryption January 2008
暗号化2008年1月に認証されたマグリュー標準化過程[7ページ]RFC5116
decryption operation. For instance, if the nonce and ciphertext both appear in a packet, the former value should precede the latter. This rule facilitates efficient and simple hardware implementations of AEAD algorithms.
復号化操作。 例えば、一回だけと暗号文がパケットにともに現れるなら、前の値は後者に先行するべきです。 この規則はAEADアルゴリズムの効率的で簡単なハードウェア実装を容易にします。
3. Guidance on the Use of AEAD Algorithms
3. AEADアルゴリズムの使用の指導
This section provides advice that must be followed in order to use an AEAD algorithm securely.
このセクションはしっかりとAEADアルゴリズムを使用するために従わなければならないアドバイスを提供します。
If an application is unable to meet the uniqueness requirement on nonce generation, then it MUST use a zero-length nonce. Randomized or stateful algorithms, which are defined below, are suitable for use with such applications. Otherwise, an application SHOULD use nonces with a length of twelve octets. Since algorithms are encouraged to support that length, applications should use that length to aid interoperability.
アプリケーションが一回だけの世代に関するユニークさの必要条件を満たすことができないなら、それはゼロ・レングス一回だけを使用しなければなりません。 ランダマイズされたかstatefulなアルゴリズム(以下で定義される)はそのようなアプリケーションによる使用に適しています。 さもなければ、アプリケーションSHOULDは12の八重奏の長さがある一回だけを使用します。 アルゴリズムがその長さをサポートするよう奨励されるので、アプリケーションは相互運用性を支援するのにその長さを使用するべきです。
3.1. Requirements on Nonce Generation
3.1. 一回だけの世代に関する要件
It is essential for security that the nonces be constructed in a manner that respects the requirement that each nonce value be distinct for each invocation of the authenticated encryption operation, for any fixed value of the key. In this section, we call attention to some consequences of this requirement in different scenarios.
方法で組み立てられて、一回だけがあるセキュリティのために、それが認証された暗号化操作の各実施において、それぞれの一回だけの値が異なっているという要件を尊敬するのは、不可欠です、キーのどんな一定の価値のためにも。 このセクションでは、私たちは異なったシナリオのこの要件のいくつかの結果に注意を促します。
When there are multiple devices performing encryption using a single key, those devices must coordinate to ensure that the nonces are unique. A simple way to do this is to use a nonce format that contains a field that is distinct for each one of the devices, as described in Section 3.2. Note that there is no need to coordinate the details of the nonce format between the encrypter and the decrypter, as long the entire nonce is sent or stored with the ciphertext and is thus available to the decrypter. If the complete nonce is not available to the decrypter, then the decrypter will need to know how the nonce is structured so that it can reconstruct it. Applications SHOULD provide encryption engines with some freedom in choosing their nonces; for example, a nonce could contain both a counter and a field that is set by the encrypter but is not processed by the receiver. This freedom allows a set of encryption devices to more readily coordinate to ensure the distinctness of their nonces.
単一のキーを使用することで暗号化を実行する複数のデバイスがあるとき、それらのデバイスは、一回だけが確実にユニークになるようにするために調整されなければなりません。 これをする簡単な方法はデバイスのそれぞれにおいて、異なった分野を含む一回だけの形式を使用することです、セクション3.2で説明されるように。 全体の一回だけがdecrypterに送るか、暗号文で保存して、またはその結果、利用可能であるという長いとしてのencrypterとdecrypterの間の一回だけの形式の詳細を調整する必要は全くないことに注意してください。 完全な一回だけがdecrypterに利用可能でないなら、decrypterは、一回だけがそれを再建できるようにどのように構造化されるかを知る必要があるでしょう。 アプリケーションSHOULDはそれらの一回だけを選ぶ際に何らかの自由を暗号化エンジンに提供します。 例えば、一回だけはカウンタとencrypterによって設定されますが、受信機によって処理されない分野の両方を含むかもしれません。この自由は、1セットの暗号化デバイスがそれらの一回だけの明暸さを確実にするために、より容易に調整されるのを許容します。
If a secret key will be used for a long period of time, e.g., across multiple reboots, then the nonce will need to be stored in non- volatile memory. In such cases, it is essential to use checkpointing of the nonce; that is, the current nonce value should be stored to provide the state information needed to resume encryption in case of
秘密鍵が長い年月の間使用されると、例えば、複数のリブートの向こう側に、一回だけは、非揮発性メモリーに保存される必要があるでしょう。 そのような場合、一回だけのcheckpointingを使用するのは不可欠です。 の場合にすなわち、現在の一回だけの値が情報が暗号化を再開する必要があった状態を提供するために保存されるべきである。
McGrew Standards Track [Page 8] RFC 5116 Authenticated Encryption January 2008
暗号化2008年1月に認証されたマグリュー標準化過程[8ページ]RFC5116
unexpected failure. One simple way to provide a high assurance that a nonce value will not be used repeatedly is to wait until the encryption process receives confirmation from the storage process indicating that the succeeding nonce value has already been stored. Because this method may add significant latency, it may be desirable to store a nonce value that is several values ahead in the sequence. As an example, the nonce 100 could be stored, after which the nonces 1 through 99 could be used for encryption. The nonce value 200 could be stored at the same time that nonces 1 through 99 are being used, and so on.
予期していなかった失敗。 一回だけの値が繰り返して使用されないという高い保証を提供する1つの簡単な方法は暗号化プロセスが続く一回だけの値が既に保存されたのを示すストレージプロセスから確認を受け取るまで待つことです。 このメソッドが重要な潜在を加えるかもしれないので、系列の先のいくつかの値である一回だけの値を保存するのは望ましいかもしれません。 例として、一回だけの100(暗号化に一回だけ1〜99を使用できた)を保存できました。 一回だけ1〜99が使用される同時間、などに一回だけの値200を保存できました。
Many problems with nonce reuse can be avoided by changing a key in a situation in which nonce coordination is difficult.
一回だけのコーディネートが難しい状況でキーを変えることによって、一回だけの再利用に関する多くの問題を避けることができます。
Each AEAD algorithm SHOULD describe what security degradation would result from an inadvertent reuse of a nonce value.
それぞれのAEADアルゴリズムSHOULDは、どんなセキュリティ退行が一回だけの価値の不注意な再利用から生じるかを説明します。
3.2. Recommended Nonce Formation
3.2. お勧めの一回だけの構成
The following method to construct nonces is RECOMMENDED. The nonce is formatted as illustrated in Figure 1, with the initial octets consisting of a Fixed field, and the final octets consisting of a Counter field. For each fixed key, the length of each of these fields, and thus the length of the nonce, is fixed. Implementations SHOULD support 12-octet nonces in which the Counter field is four octets long.
一回だけを組み立てる以下のメソッドはRECOMMENDEDです。 一回だけは図1で例証されるようにフォーマットされます、初期の八重奏がFixed分野から成っていて、最終的な八重奏がCounter分野から成っていて。 それぞれの固定キーに関しては、それぞれのこれらの分野の長さ、およびその結果、一回だけの長さは固定されています。 実装SHOULDは長い間Counter分野が4つの八重奏である12八重奏の一回だけをサポートします。
<----- variable ----> <----------- variable ----------->
+---------------------+----------------------------------+
| Fixed | Counter |
+---------------------+----------------------------------+
<。----- 変数----><。----------- 変数----------->+---------------------+----------------------------------+ | 修理されています。| カウンタ| +---------------------+----------------------------------+
Figure 1: Recommended nonce format
図1: お勧めの一回だけの形式
The Counter fields of successive nonces form a monotonically increasing sequence, when those fields are regarded as unsigned integers in network byte order. The length of the Counter field MUST remain constant for all nonces that are generated for a given encryption device. The Counter part SHOULD be equal to zero for the first nonce, and increment by one for each successive nonce that is generated. However, any particular Counter value MAY be skipped over, and left out of the sequence of values that are used, if it is convenient. For example, an application could choose to skip the initial Counter=0 value, and set the Counter field of the initial nonce to 1. Thus, at most 2^(8*C) nonces can be generated when the Counter field is C octets in length.
連続した一回だけのCounter分野は単調に増加する系列を形成します、それらの分野がネットワークバイトオーダーにおける符号のない整数と見なされるとき。 Counter分野の長さは与えられた暗号化デバイスのために生成されるすべての一回だけに一定のままで残らなければなりません。 最初の一回だけのためにゼロに合わせて、それぞれの連続した一回だけあたり1つ増加する同輩が発生していたなら、CounterはSHOULDを分けます。 しかしながら、どんな特定のCounter値も、使用された値の系列から飛ばされて、外されるかもしれません、都合がよければ。 例えば、アプリケーションは、初期のCounter=0値をスキップするのを選んで、初期の一回だけのCounter分野を1に設定するかもしれません。 Counter分野が長さがC八重奏であるときに、したがって、高々、2^(8*C)一回だけを生成することができます。
McGrew Standards Track [Page 9] RFC 5116 Authenticated Encryption January 2008
暗号化2008年1月に認証されたマグリュー標準化過程[9ページ]RFC5116
The Fixed field MUST remain constant for all nonces that are generated for a given encryption device. If different devices are performing encryption with a single key, then each distinct device MUST use a distinct Fixed field, to ensure the uniqueness of the nonces. Thus, at most 2^(8*F) distinct encrypters can share a key when the Fixed field is F octets in length.
Fixed分野は与えられた暗号化デバイスのために生成されるすべての一回だけに一定のままで残らなければなりません。 異なったデバイスが単一のキーによる暗号化を実行しているなら、それぞれの異なったデバイスは、一回だけのユニークさを確実にするのに異なったFixed分野を使用しなければなりません。 Fixed分野が長さがF八重奏であるときに、したがって、高々、2^(8*F)の異なったencryptersはキーを共有できます。
3.2.1. Partially Implicit Nonces
3.2.1. 部分的に暗黙の一回だけ
In some cases, it is desirable to not transmit or store an entire nonce, but instead to reconstruct that value from contextual information immediately prior to decryption. As an example, ciphertexts could be stored in sequence on a disk, and the nonce for a particular ciphertext could be inferred from its location, as long as the rule for generating the nonces is known by the decrypter. We call the portion of the nonce that is stored or sent with the ciphertext the explicit part. We call the portion of the nonce that is inferred the implicit part. When part of the nonce is implicit, the following specialization of the above format is RECOMMENDED. The Fixed field is divided into two sub-fields: a Fixed-Common field and a Fixed-Distinct field. This format is shown in Figure 2. If different devices are performing encryption with a single key, then each distinct device MUST use a distinct Fixed-Distinct field. The Fixed-Common field is common to all nonces. The Fixed-Distinct field and the Counter field MUST be in the explicit part of the nonce. The Fixed-Common field MAY be in the implicit part of the nonce. These conventions ensure that the nonce is easy to reconstruct from the explicit data.
いくつかの場合、復号化のすぐ前に文脈上の情報からその値を再建するために代わりに全体の一回だけを伝えないか、または保存しないのが望ましいです。 例として、連続してディスクの上に暗号文を保存できました、そして、位置から特定の暗号文のための一回だけを推論できました、一回だけを生成するための規則がdecrypterによって知られている限り。 私たちは、暗号文と共に保存されるか、または送られる一回だけの部分を明白な部分と呼びます。 私たちは、推論される一回だけの部分を内在している部分と呼びます。 一回だけの部分が内在しているとき、上の形式の以下の専門化はRECOMMENDEDです。 Fixed分野は2つのサブ分野に分割されます: Fixed-共同耕地とFixed異なった分野。 この書式は図2に示されます。 異なったデバイスが単一のキーによる暗号化を実行しているなら、それぞれの異なったデバイスは異なったFixed異なった分野を使用しなければなりません。 Fixed-共同耕地はすべての一回だけに共通です。 Fixed異なった分野とCounter分野が一回だけの明白な部分にあるに違いありません。 Fixed-共同耕地が一回だけの内在している部分にあるかもしれません。 これらのコンベンションは、一回だけは明白なデータから再建しやすいのを確実にします。
+-------------------+--------------------+---------------+
| Fixed-Common | Fixed-Distinct | Counter |
+-------------------+--------------------+---------------+
<---- implicit ---> <------------ explicit ------------>
+-------------------+--------------------+---------------+ | 修理されて一般的です。| 修理されて異なります。| カウンタ| +-------------------+--------------------+---------------+ <。---- 暗黙---><。------------ 明白------------>。
Figure 2: Partially implicit nonce format
図2: 部分的に暗黙の一回だけの形式
The rationale for the partially implicit nonce format is as
follows. This method of nonce construction incorporates the best
known practice; it is used by both GCM Encapuslating Security
Payload (ESP) [RFC4106] and CCM ESP [RFC4309], in which the Fixed
field contains the Salt value and the lowest eight octets of the
nonce are explicitly carried in the ESP packet. In GCM ESP, the
Fixed field must be at least four octets long, so that it can
contain the Salt value. In CCM ESP, the Fixed field must be at
least three octets long for the same reason. This nonce
generation method is also used by several counter mode variants
including CTR ESP.
部分的に暗黙の一回だけの形式のための原理は以下の通りです。 一回だけの工事のこのメソッドは最もよく知られている習慣を取り入れます。 それはGCM Encapuslating Security有効搭載量(超能力)[RFC4106]とFixed分野がSalt値を含むCCM ESP[RFC4309]の両方によって使用されます、そして、一回だけの最も低い8つの八重奏が超能力パケットで明らかに運ばれます。 GCM ESPでは、長い間、Fixed分野は少なくとも4つの八重奏であるに違いありません、Salt値を含むことができるように。 CCM ESPでは、長い間、Fixed分野は同じ理由から少なくとも3つの八重奏であるに違いありません。 また、この一回だけの世代メソッドはCTR ESPを含むいくつかのカウンタモード異形によって使用されます。
McGrew Standards Track [Page 10] RFC 5116 Authenticated Encryption January 2008
暗号化2008年1月に認証されたマグリュー標準化過程[10ページ]RFC5116
3.3. Construction of AEAD Inputs
3.3. AEAD入力の工事
If the AD input is constructed out of multiple data elements, then it is essential that it be unambiguously parseable into its constituent elements, without the use of any unauthenticated data in the parsing process. (In mathematical terms, the AD input must be an injective function of the data elements.) If an application constructs its AD input in such a way that there are two distinct sets of data elements that result in the same AD value, then an attacker could cause a receiver to accept a bogus set by substituting one set for the other. The requirement that the AD be uniquely parseable ensures that this attack is not possible. This requirement is trivially met if the AD is composed of fixed-width elements. If the AD contains a variable- length string, for example, this requirement can be met by also including the length of the string in the AD.
AD入力が複数のデータ要素から構成されるなら、それが明白に構成分子に分析可能であることは、不可欠です、構文解析プロセスにおけるどんな非認証されたデータの使用なしでも。 (数学的に説明すると、AD入力はデータ要素のinjective関数であるに違いありません。) アプリケーションが同じAD値をもたらす異なった2セットのデータ要素があるような方法でAD入力を構成するなら、攻撃者は、受信機に1セットをもう片方の代わりに用いることによって、にせのセットを受け入れさせるかもしれません。 ADが唯一分析可能であるという要件は、この攻撃が可能でないことを確実にします。 ADが固定幅の要素で構成されるなら、この必要条件は些細なことに満たされます。 ADが可変長さのストリングを含んでいるなら、例えば、また、ADのストリングの長さを含んでいることによって、この必要条件を満たすことができます。
Similarly, if the plaintext is constructed out of multiple data elements, then it is essential that it be unambiguously parseable into its constituent elements, without using any unauthenticated data in the parsing process. Note that data included in the AD may be used when parsing the plaintext, though of course since the AD is not encrypted there is a potential loss of confidentiality when information about the plaintext is included in the AD.
同様に、平文が複数のデータ要素から構成されるなら、それが明白に構成分子に分析可能であることは、不可欠です、構文解析プロセスのどんな非認証されたデータも使用しないで。 平文を分析するとき、ADのときにデータを含んでいるのが使用されるかもしれないというメモ、ADがそうので、情報であるときに、暗号化されないで、秘密性の潜在的損失がもちろん周囲にありますが、平文はADのときに含まれています。
3.4. Example Usage
3.4. 例の用法
To make use of an AEAD algorithm, an application must define how the encryption algorithm's inputs are defined in terms of application data, and how the ciphertext and nonce are conveyed. The clearest way to do this is to express each input in terms of the data that form it, then to express the application data in terms of the outputs of the AEAD encryption operation.
AEADアルゴリズムを利用するために、アプリケーションは、暗号化アルゴリズムの入力がアプリケーションデータでどのように定義されるか、そして、暗号文と一回だけがどのように伝えられるかを定義しなければなりません。 それを形成するデータでそれぞれ入力された急行にはこれをする最も明確な方法があります、AEAD暗号化操作の出力でアプリケーションデータを言い表すために、当時です。
For example, AES-GCM ESP [RFC4106] can be expressed as follows. The AEAD inputs are
例えば、以下の通り、AES-GCM ESP[RFC4106]を急送できます。 AEAD入力はそうです。
P = RestOfPayloadData || TFCpadding || Padding || PadLength ||
NextHeader
PはRestOfPayloadDataと等しいです。|| TFCpadding|| 詰め物|| PadLength|| NextHeader
N = Salt || IV
Nは塩と等しいです。|| IV
A = SPI || SequenceNumber
=SPI|| SequenceNumber
where the symbol "||" denotes the concatenation operation, and the fields RestOfPayloadData, TFCpadding, Padding, PadLength, NextHeader, SPI, and SequenceNumber are as defined in [RFC4303], and the fields Salt and IV are as defined in [RFC4106]. The field RestOfPayloadData contains the plaintext data that is described by the NextHeader
「どこ、シンボル、」||「連結演算、RestOfPayloadData、TFCpadding、Padding、PadLength、NextHeader、SPI、およびSequenceNumberが定義されるとしている分野[RFC4303]、およびSaltとIVが定義されるとしている分野[RFC4106]を指示します。」 分野RestOfPayloadDataはNextHeaderによって説明される平文データを含んでいます。
McGrew Standards Track [Page 11] RFC 5116 Authenticated Encryption January 2008
暗号化2008年1月に認証されたマグリュー標準化過程[11ページ]RFC5116
field, and no other data. (Recall that the PayloadData field contains both the IV and the RestOfPayloadData; see Figure 2 of [RFC4303] for an illustration.)
分野にもかかわらず、他のデータがありません。 (PayloadData分野がIVとRestOfPayloadDataの両方を含むと思い出してください; イラストに関して[RFC4303]の図2を見てください。)
The format of the ESP packet can be expressed as
パケットを言い表すことができる超能力の形式
ESP = SPI || SequenceNumber || IV || C
超能力はSPIと等しいです。|| SequenceNumber|| IV|| C
where C is the AEAD ciphertext (which in this case incorporates the authentication tag). Please note that here we have not described the use of the ESP Extended Sequence Number.
CがAEAD暗号文(この場合認証タグを組み込む)であるところ。 ここで、私たちは超能力Extended Sequence Numberの使用について説明していません。
4. Requirements on AEAD Algorithm Specifications
4. AEADアルゴリズム仕様に関する要件
Each AEAD algorithm MUST only accept keys with a fixed key length K_LEN, and MUST NOT require any particular data format for the keys provided as input. An algorithm that requires such structure (e.g., one with subkeys in a particular parity-check format) will need to provide it internally.
それぞれのAEADアルゴリズムは、_固定キー長K LENと共にキーを受け入れるだけでよくて、入力されるように提供されたキーのために少しの特定のデータの形式も必要としてはいけません。 そのような構造(例えば、特定のパリティチェック形式のサブキーがある1)を必要とするアルゴリズムは、内部的にそれを提供する必要があるでしょう。
Each AEAD algorithm MUST accept any plaintext with a length between zero and P_MAX octets, inclusive, where the value P_MAX is specific to that algorithm. The value of P_MAX MUST be larger than zero, and SHOULD be at least 65,536 (2^16) octets. This size is a typical upper limit for network data packets. Other applications may use even larger values of P_MAX, so it is desirable for general-purpose algorithms to support higher values.
ゼロとP_MAX八重奏の間には、長さがある状態で、それぞれのAEADアルゴリズムはどんな平文も受け入れなければなりません、包括的です、値のP_MAXがそのアルゴリズムに特定であるところで。 P_マックスの値は少なくともゼロ、およびSHOULDより大きい6万5536(2^16)の八重奏でなければなりません。 このサイズはネットワークデータ・パケットのための典型的な上限です。 他のアプリケーションがP_MAXのさらに大きい値を使用するかもしれないので、汎用アルゴリズムが、より高い値をサポートするのは、望ましいです。
Each AEAD algorithm MUST accept any associated data with a length between zero and A_MAX octets, inclusive, where the value A_MAX is specific to that algorithm. The value of A_MAX MUST be larger than zero, and SHOULD be at least 65,536 (2^16) octets. Other applications may use even larger values of A_MAX, so it is desirable for general-purpose algorithms to support higher values.
ゼロとA_MAX八重奏の間には、長さがある状態で、それぞれのAEADアルゴリズムはどんな関連データも受け入れなければなりません、包括的です、値のA_MAXがそのアルゴリズムに特定であるところで。 A_マックスの値は少なくともゼロ、およびSHOULDより大きい6万5536(2^16)の八重奏でなければなりません。 他のアプリケーションがA_MAXのさらに大きい値を使用するかもしれないので、汎用アルゴリズムが、より高い値をサポートするのは、望ましいです。
Each AEAD algorithm MUST accept any nonce with a length between N_MIN and N_MAX octets, inclusive, where the values of N_MIN and N_MAX are specific to that algorithm. The values of N_MAX and N_MIN MAY be equal. Each algorithm SHOULD accept a nonce with a length of twelve (12) octets. Randomized or stateful algorithms, which are described below, MAY have an N_MAX value of zero.
N_MINとN_MAX八重奏の間には、長さがある状態で、それぞれのAEADアルゴリズムはどんな一回だけも受け入れなければなりません、包括的です、N_MINとN_MAXの値がそのアルゴリズムに特定であるところで。 値、N_MAXとN_MIN MAYでは、等しくいてください。 各アルゴリズムSHOULDは12(12)八重奏の長さで一回だけを受け入れます。 ランダマイズされたかstatefulなアルゴリズム(以下で説明される)には、ゼロのN_MAX値があるかもしれません。
An AEAD algorithm MAY structure its ciphertext output in any way; for example, the ciphertext can incorporate an authentication tag. Each algorithm SHOULD choose a structure that is amenable to efficient processing.
AEADアルゴリズムは何らかの方法で暗号文出力を構造化するかもしれません。 例えば、暗号文は認証タグを組み込むことができます。 各アルゴリズムSHOULDは効率的な処理に従順な構造を選びます。
McGrew Standards Track [Page 12] RFC 5116 Authenticated Encryption January 2008
暗号化2008年1月に認証されたマグリュー標準化過程[12ページ]RFC5116
An Authenticated Encryption algorithm MAY incorporate or make use of a random source, e.g., for the generation of an internal initialization vector that is incorporated into the ciphertext output. An AEAD algorithm of this sort is called randomized; though note that only encryption is random, and decryption is always deterministic. A randomized algorithm MAY have a value of N_MAX that is equal to zero.
Authenticated Encryptionアルゴリズムは、例えば、法人組織であることの内部の初期化ベクトルの世代に暗号文出力に無作為のソースを取り入れるか、または利用するかもしれません。 この種類のAEADアルゴリズムはランダマイズされていると呼ばれます。 注意ですが、その唯一の暗号化が無作為です、そして、復号化はいつも決定論的です。 確率的アルゴリズムには、ゼロに合わせるために等しいN_MAXの値があるかもしれません。
An Authenticated Encryption algorithm MAY incorporate internal state information that is maintained between invocations of the encrypt operation, e.g., to allow for the construction of distinct values that are used as internal nonces by the algorithm. An AEAD algorithm of this sort is called stateful. This method could be used by an algorithm to provide good security even when the application inputs zero-length nonces. A stateful algorithm MAY have a value of N_MAX that is equal to zero.
Authenticated Encryptionアルゴリズムが実施の間で保守される内部の州の情報を取り入れるかもしれない、操作を暗号化して、例えば内部の一回だけとしてアルゴリズムで使用される異なった値の工事を考慮してください。 この種類のAEADアルゴリズムはstatefulと呼ばれます。 アプリケーションがゼロ・レングス一回だけを入力さえするとき、優れた警備体制を提供するのにアルゴリズムでこのメソッドを使用できるでしょう。 statefulアルゴリズムには、ゼロに合わせるために等しいN_MAXの値があるかもしれません。
The specification of an AEAD algorithm MUST include the values of K_LEN, P_MAX, A_MAX, N_MIN, and N_MAX defined above. Additionally, it MUST specify the number of octets in the largest possible ciphertext, which we denote C_MAX.
AEADアルゴリズムの仕様はK_LEN、P_MAX、A_MAX、N_MIN、および上で定義されたN_MAXの値を含まなければなりません。 さらに、それは可能な限り大きい暗号文における、八重奏の数を指定しなければなりません。(私たちは暗号文を指示します)。C_MAX。
Each AEAD algorithm MUST provide a description relating the length of the plaintext to that of the ciphertext. This relation MUST NOT depend on external parameters, such as an authentication strength parameter (e.g., authentication tag length). That sort of dependence would complicate the use of the algorithm by creating a situation in which the information from the AEAD registry was not sufficient to ensure interoperability.
それぞれのAEADアルゴリズムは暗号文のものに平文の長さに関連する記述を提供しなければなりません。 この関係は認証強度定数などの外部のパラメタ(例えば、認証タグの長さ)に依存してはいけません。 その種類の依存は、AEAD登録からの情報が相互運用性を確実にするために十分でなかった状況を作成することによって、アルゴリズムの使用を複雑にするでしょう。
EACH AEAD algorithm specification SHOULD describe what security degradation would result from an inadvertent reuse of a nonce value.
EACH AEADアルゴリズム仕様SHOULDは、どんなセキュリティ退行が一回だけの価値の不注意な再利用から生じるかを説明します。
Each AEAD algorithm specification SHOULD provide a reference to a detailed security analysis. This document does not specify a particular security model, because several different models have been used in the literature. The security analysis SHOULD define or reference a security model.
それぞれのAEADアルゴリズム仕様SHOULDは詳細な証券分析の参照を提供します。 数個の異なったモデルが文学で使用されたので、このドキュメントは特定の機密保護モデルを指定しません。 SHOULDが定義する証券分析かセキュリティがモデル化する参照。
An algorithm that is randomized or stateful, as defined above, SHOULD describe itself using those terms.
ランダマイズされるアルゴリズムかstateful、上で定義されるように、SHOULDはそれらの用語を使用することでそれ自体について説明します。
McGrew Standards Track [Page 13] RFC 5116 Authenticated Encryption January 2008
暗号化2008年1月に認証されたマグリュー標準化過程[13ページ]RFC5116
5. AEAD Algorithms
5. AEADアルゴリズム
This section defines four AEAD algorithms; two are based on AES GCM, two are based on AES CCM. Each pair includes an algorithm with a key size of 128 bits and one with a key size of 256 bits.
このセクションは4つのAEADアルゴリズムを定義します。 2はAES GCMに基づいていて、2はAES CCMに基づいています。 各組は256ビットの主要なサイズで128ビットと1の主要なサイズがあるアルゴリズムを入れます。
5.1. AEAD_AES_128_GCM
5.1. AEAD_AES_128_GCM
The AEAD_AES_128_GCM authenticated encryption algorithm works as specified in [GCM], using AES-128 as the block cipher, by providing the key, nonce, and plaintext, and associated data to that mode of operation. An authentication tag with a length of 16 octets (128 bits) is used. The AEAD_AES_128_GCM ciphertext is formed by appending the authentication tag provided as an output to the GCM encryption operation to the ciphertext that is output by that operation. Test cases are provided in the appendix of [GCM]. The input and output lengths are as follows:
AEAD_AES_128_GCMは[GCM]の指定されるとしての暗号化アルゴリズム作品を認証しました、ブロック暗号としてAES-128を使用して、その運転モードへのキー、一回だけ、および平文を提供して、関連データで。 16の八重奏(128ビット)の長さがある認証タグは使用されています。 AEAD_AES_128_GCM暗号文は、その操作によって出力としてGCM暗号化操作に提供された認証タグを出力である暗号文に追加することによって、形成されます。 [GCM]の付録にテストケースを提供します。 入出力の長さは以下の通りです:
K_LEN is 16 octets,
K_LENは16の八重奏です。
P_MAX is 2^36 - 31 octets,
P_MAXは2^36--31の八重奏です。
A_MAX is 2^61 - 1 octets,
_MAXは2^61--1八重奏です。
N_MIN and N_MAX are both 12 octets, and
そしてN_MINとN_MAXが両方の12の八重奏である。
C_MAX is 2^36 - 15 octets.
C_MAXは2^36--15の八重奏です。
An AEAD_AES_128_GCM ciphertext is exactly 16 octets longer than its corresponding plaintext.
対応する平文より八重奏長い間、AEAD_AES_128_GCM暗号文はまさに16です。
A security analysis of GCM is available in [MV04].
GCMの証券分析は[MV04]で利用可能です。
5.1.1. Nonce Reuse
5.1.1. 一回だけの再利用
The inadvertent reuse of the same nonce by two invocations of the GCM encryption operation, with the same key, but with distinct plaintext values, undermines the confidentiality of the plaintexts protected in those two invocations, and undermines all of the authenticity and integrity protection provided by that key. For this reason, GCM should only be used whenever nonce uniqueness can be provided with assurance. The design feature that GCM uses to achieve minimal latency causes the vulnerabilities on the subsequent uses of the key. Note that it is acceptable to input the same nonce value multiple times to the decryption operation.
GCM暗号化操作の2つの実施による同じ一回だけの不注意な再利用は、同じキーにもかかわらず、異なった平文値でそれらの2つの実施で保護された平文の秘密性を弱体化させて、そのキーによって提供された信憑性と保全保護のすべてを弱体化させます。 この理由のために、一回だけのユニークさを自信を持って提供できるときはいつも、GCMは使用されるだけであるべきです。 GCMが最小量の潜在を達成するのに使用する設計上の特徴はキーのその後の用途のときに脆弱性を引き起こします。 複数の回同じ一回だけの値を復号化操作に入力するのが許容できることに注意してください。
The security consequences are quite serious if an attacker observes two ciphertexts that were created using the same nonce and key
攻撃者が同じ一回だけとキーを使用することで作成された2つの暗号文を観測するなら、セキュリティ結果はかなり重大です。
McGrew Standards Track [Page 14] RFC 5116 Authenticated Encryption January 2008
暗号化2008年1月に認証されたマグリュー標準化過程[14ページ]RFC5116
values, unless the plaintext and AD values in both invocations of the encrypt operation were identical. First, a loss of confidentiality ensues because he will be able to reconstruct the bitwise exclusive-or of the two plaintext values. Second, a loss of integrity ensues because the attacker will be able to recover the internal hash key used to provide data integrity. Knowledge of this key makes subsequent forgeries trivial.
平文とADが中で両方の実施を評価しない場合評価する、暗号化、操作は同じです。 彼がいるために再建できて望んでいるので最初に秘密性の損失が続く、bitwiseする、2つの平文値の排他的論理和。 2番目に、攻撃者がデータ保全を提供するのに使用される内部のナンバー記号のキーを回収できるので、保全の損失は続きます。 このキーに関する知識で、その後の偽造は些細になります。
5.2. AEAD_AES_256_GCM
5.2. AEAD_AES_256_GCM
This algorithm is identical to AEAD_AES_128_GCM, but with the following differences:
このアルゴリズムは、AEAD_AES_128_GCMと同じですが、以下の違いで同じです:
K_LEN is 32 octets, instead of 16 octets, and
そしてK_LENが16の八重奏の代わりに32の八重奏である。
AES-256 GCM is used instead of AES-128 GCM.
AES-256 GCMはAES-128 GCMの代わりに使用されます。
5.3. AEAD_AES_128_CCM
5.3. AEAD_AES_128_立方センチメートル
The AEAD_AES_128_CCM authenticated encryption algorithm works as specified in [CCM], using AES-128 as the block cipher, by providing the key, nonce, associated data, and plaintext to that mode of operation. The formatting and counter generation function are as specified in Appendix A of that reference, and the values of the parameters identified in that appendix are as follows:
AEAD_AES_128_CCMは[CCM]の指定されるとしての暗号化アルゴリズム作品を認証しました、ブロック暗号としてAES-128を使用して、主要で、一回だけの関連データ、および平文をその運転モードに提供することによって。 形式とカウンタ世代機能がその参照のAppendix Aで指定されるようにあります、そして、その付録で特定されたパラメタの値は以下の通りです:
the nonce length n is 12,
一回だけの長さnは12です。
the tag length t is 16, and
そしてタグの長さtが16である。
the value of q is 3.
qの値は3です。
An authentication tag with a length of 16 octets (128 bits) is used. The AEAD_AES_128_CCM ciphertext is formed by appending the authentication tag provided as an output to the CCM encryption operation to the ciphertext that is output by that operation. Test cases are provided in [CCM]. The input and output lengths are as follows:
16の八重奏(128ビット)の長さがある認証タグは使用されています。 AEAD_AES_128_CCM暗号文は、その操作によって出力としてCCM暗号化操作に提供された認証タグを出力である暗号文に追加することによって、形成されます。 [CCM]にテストケースを提供します。 入出力の長さは以下の通りです:
K_LEN is 16 octets,
K_LENは16の八重奏です。
P_MAX is 2^24 - 1 octets,
P_MAXは2^24--1八重奏です。
A_MAX is 2^64 - 1 octets,
_MAXは2^64--1八重奏です。
N_MIN and N_MAX are both 12 octets, and
そしてN_MINとN_MAXが両方の12の八重奏である。
C_MAX is 2^24 + 15 octets.
C_MAXは2^24+15の八重奏です。
McGrew Standards Track [Page 15] RFC 5116 Authenticated Encryption January 2008
暗号化2008年1月に認証されたマグリュー標準化過程[15ページ]RFC5116
An AEAD_AES_128_CCM ciphertext is exactly 16 octets longer than its corresponding plaintext.
対応する平文より八重奏長い間、AEAD_AES_128_CCM暗号文はまさに16です。
A security analysis of AES CCM is available in [J02].
AES CCMの証券分析は[J02]で利用可能です。
5.3.1. Nonce Reuse
5.3.1. 一回だけの再利用
Inadvertent reuse of the same nonce by two invocations of the CCM encryption operation, with the same key, undermines the security for the messages processed with those invocations. A loss of confidentiality ensues because an adversary will be able to reconstruct the bitwise exclusive-or of the two plaintext values.
同じキーで、CCM暗号化操作の2つの実施による同じ一回だけの不注意な再利用はそれらの実施で処理されたメッセージのためにセキュリティを弱体化させます。 敵がいるために再建できて望んでいるので秘密性の損失が続く、bitwiseする、2つの平文値の排他的論理和。
5.4. AEAD_AES_256_CCM
5.4. AEAD_AES_256_立方センチメートル
This algorithm is identical to AEAD_AES_128_CCM, but with the following differences:
このアルゴリズムは、AEAD_AES_128_CCMと同じですが、以下の違いで同じです:
K_LEN is 32 octets, instead of 16, and
そしてK_LENが16の代わりに32の八重奏である。
AES-256 CCM is used instead of AES-128 CCM.
AES-256 CCMはAES-128 CCMの代わりに使用されます。
6. IANA Considerations
6. IANA問題
The Internet Assigned Numbers Authority (IANA) has defined the "AEAD Registry" described below. An algorithm designer MAY register an algorithm in order to facilitate its use. Additions to the AEAD Registry require that a specification be documented in an RFC or another permanent and readily available reference, in sufficient detail that interoperability between independent implementations is possible. Each entry in the registry contains the following elements:
インターネットAssigned民数記Authority(IANA)は以下で説明された「AEAD登録」を定義しました。 アルゴリズムデザイナーは、使用を容易にするためにアルゴリズムを登録するかもしれません。 AEAD Registryへの追加は、仕様がRFCか別の永久的で容易に利用可能な参照に記録されるのを必要とします、独立している実装の間の相互運用性が可能であるという十分な詳細に。 登録の各エントリーは以下の要素を含んでいます:
a short name, such as "AEAD_AES_128_GCM", that starts with the
string "AEAD",
ストリング"AEAD"から始まる「AEAD_AES_128_GCM」などの省略名
a positive number, and
そして正の数。
a reference to a specification that completely defines an AEAD
algorithm and provides test cases that can be used to verify the
correctness of an implementation.
実装の正当性について確かめるのにAEADアルゴリズムを完全に定義して、それをテストケースに提供する仕様の参照を使用できます。
Requests to add an entry to the registry MUST include the name and the reference. The number is assigned by IANA. These number assignments SHOULD use the smallest available positive number. Submitters SHOULD have their requests reviewed by the IRTF Crypto
登録にエントリーを加えるという要求は名前と指示するものを含まなければなりません。 数はIANAによって割り当てられます。 これらの数の課題SHOULDは最もわずかな有効な正の数を使用します。 Submitters SHOULDはIRTF Cryptoに彼らの要求を再検討させます。
McGrew Standards Track [Page 16] RFC 5116 Authenticated Encryption January 2008
暗号化2008年1月に認証されたマグリュー標準化過程[16ページ]RFC5116
Forum Research Group (CFRG) at cfrg@ietf.org. Interested applicants that are unfamiliar with IANA processes should visit http://www.iana.org.
cfrg@ietf.org のフォーラム研究グループ(CFRG)。 IANAプロセスになじみがない関心がある応募者は http://www.iana.org を訪問するべきです。
The numbers between 32,768 (binary 1000000000000000) and 65,535 (binary 1111111111111111) inclusive, will not be assigned by IANA, and are reserved for private use; no attempt will be made to prevent multiple sites from using the same value in different (and incompatible) ways [RFC2434].
そして、3万2768(2進の1000000000000000)の間の数、6万5535 (2進の1111111111111111) 包括的です、意志は、IANAによって割り当てられて、私的使用目的で予約されません。 複数のサイトが異なって(非互換)の方法[RFC2434]で同じ値を使用するのを防ぐのを試みを全くしないでしょう。
IANA has added the following entries to the AEAD Registry:
IANAは以下のエントリーをAEAD Registryに加えました:
+------------------+-------------+--------------------+
| Name | Reference | Numeric Identifier |
+------------------+-------------+--------------------+
| AEAD_AES_128_GCM | Section 5.1 | 1 |
| AEAD_AES_256_GCM | Section 5.2 | 2 |
| AEAD_AES_128_CCM | Section 5.3 | 3 |
| AEAD_AES_256_CCM | Section 5.4 | 4 |
+------------------+-------------+--------------------+
+------------------+-------------+--------------------+ | 名前| 参照| 数値識別子| +------------------+-------------+--------------------+ | AEAD_AES_128_GCM| セクション5.1| 1 | | AEAD_AES_256_GCM| セクション5.2| 2 | | AEAD_AES_128_立方センチメートル| セクション5.3| 3 | | AEAD_AES_256_立方センチメートル| セクション5.4| 4 | +------------------+-------------+--------------------+
An IANA registration of an AEAD does not constitute an endorsement of that algorithm or its security.
AEADのIANA登録はそのアルゴリズムかそのセキュリティの裏書きを構成しません。
7. Other Considerations
7. 他の問題
Directly testing a randomized AEAD encryption algorithm using test cases with fixed inputs and outputs is not possible, since the encryption process is non-deterministic. However, it is possible to test a randomized AEAD algorithm using the following technique. The authenticated decryption algorithm is deterministic, and it can be directly tested. The authenticated encryption algorithm can be tested by encrypting a plaintext, decrypting the resulting ciphertext, and comparing the original plaintext to the post- decryption plaintext. Combining both of these tests covers both the encryption and decryption algorithms.
固定的投入量と出力があるテストケースを使用することで直接ランダマイズされたAEAD暗号化アルゴリズムをテストするのは可能ではありません、暗号化プロセスが非決定論的であるので。 しかしながら、以下のテクニックを使用するランダマイズされたAEADアルゴリズムをテストするのは可能です。 認証された復号化アルゴリズムは決定論的です、そして、直接それはテストできます。 平文を暗号化することによって、認証された暗号化アルゴリズムをテストできます、ポスト復号化平文に結果として起こる暗号文を解読して、オリジナルの平文をたとえて。 これらのテストの両方を結合すると、暗号化と復号化アルゴリズムの両方がカバーされます。
The AEAD algorithms selected reflect those that have been already adopted by standards. It is an open question as to what other AEAD algorithms should be added. Many variations on basic algorithms are possible, each with its own advantages. While it is desirable to admit any algorithms that are found to be useful in practice, it is also desirable to limit the total number of registered algorithms. The current specification requires that a registered algorithm provide a complete specification and a set of validation data; it is hoped that these prerequisites set the admission criteria appropriately.
アルゴリズムが選択したAEADは規格によって既に採用されたものを反映します。 それはどんな他のAEADアルゴリズムが加えられるべきであるかに関する未決問題です。 基本的なアルゴリズムの多くの変化がそれぞれそれ自身の利点で可能です。 実際には役に立つのがわかっているどんなアルゴリズムも認めるのは望ましいのですが、また、登録されたアルゴリズムの総数を制限するのも望ましいです。現在の仕様は、登録されたアルゴリズムが完全な仕様と合法化データのセットを提供するのを必要とします。 これらの前提条件が適切に入場評価基準を設定することが望まれています。
McGrew Standards Track [Page 17] RFC 5116 Authenticated Encryption January 2008
暗号化2008年1月に認証されたマグリュー標準化過程[17ページ]RFC5116
It may be desirable to define an AEAD algorithm that uses the generic composition with the encrypt-then-MAC method [BN00], combining a common encryption algorithm, such as CBC [MODES], with a common message authentication code, such as HMAC-SHA1 [RFC2104] or AES CMAC [CMAC]. An AEAD algorithm of this sort would reflect the best current practice, and might be more easily supported by crypto modules that lack support for other AEAD algorithms.
当時のMACを暗号化しているメソッド[BN00]でジェネリック構成を使用するAEADアルゴリズムを定義するのは望ましいかもしれません、一般的な暗号化アルゴリズムを結合して、CBC[MODES]などのように、一般的なメッセージ確認コードで、HMAC-SHA1[RFC2104]やAES CMAC[CMAC]のように。 この種類のAEADアルゴリズムは、最も良い現在の習慣を反映して、他のAEADアルゴリズムのサポートを欠いている暗号モジュールで、より容易にサポートされるかもしれません。
8. Security Considerations
8. セキュリティ問題
This document describes authenticated encryption algorithms, and provides guidance on their use. While these algorithms make it easier, in some ways, to design a cryptographic application, it should be borne in mind that strong cryptographic security is difficult to achieve. While AEAD algorithms are quite useful, they do nothing to address the issues of key generation [RFC4086] and key management [RFC4107].
このドキュメントは、認証された暗号化アルゴリズムを説明して、彼らの使用に指導を提供します。 暗号のアプリケーションを設計するためにこれらのアルゴリズムである点ではより簡単になっている間、強い暗号のセキュリティは達成するのが難しいのが覚えておかれるべきです。 AEADアルゴリズムがかなり役に立つ間、それらはキー生成[RFC4086]とかぎ管理[RFC4107]の問題を扱うようなことを何もしません。
AEAD algorithms that rely on distinct nonces may be inappropriate for some applications or for some scenarios. Application designers should understand the requirements outlined in Section 3.1.
いくつかのアプリケーションかいくつかのシナリオに、異なった一回だけを当てにするAEADアルゴリズムは不適当であるかもしれません。 アプリケーション設計者はセクション3.1に概説された要件を理解するべきです。
A software implementation of the AEAD encryption operation in a Virtual Machine (VM) environment could inadvertently reuse a nonce due to a "rollback" of the VM to an earlier state [GR05]. Applications are encouraged to document potential issues to help the user of the application and the VM avoid unintentional mistakes of this sort. The possibility exists that an attacker can cause a VM rollback; threats and mitigations in that scenario are an area of active research. For perspective, we note that an attacker who can trigger such a rollback may have already succeeded in subverting the security of the system, e.g., by causing an accounting error.
Virtual Machine(VM)環境における、AEAD暗号化操作のソフトウェア実行はVMの「ロールバック」のためうっかり以前の状態[GR05]に一回だけを再利用するかもしれません。 アプリケーションがアプリケーションとVMのユーザがこの種類の意図的でない誤りを避けるのを助けるために潜在的問題を記録するよう奨励されます。 攻撃者がVMロールバックを引き起こす場合がある可能性は存在しています。 そのシナリオにおける脅威と緩和は活発な研究の領域です。 見解によって、私たちは、そのようなロールバックの引き金となることができる攻撃者が、システムのセキュリティを打倒するのに既に成功したかもしれないことに注意します、例えば、会計誤りを引き起こすことによって。
An IANA registration of an AEAD algorithm MUST NOT be regarded as an endorsement of its security. Furthermore, the perceived security level of an algorithm can degrade over time, due to cryptanalytic advances or to "Moore's Law", that is, the diminishing cost of computational resources over time.
AEADアルゴリズムのIANA登録をセキュリティの裏書きと見なしてはいけません。 その上、アルゴリズムの知覚されたセキュリティー・レベルは時間がたつにつれて、cryptanalytic進歩か「ムーアの法則」(すなわち、時間がたつにつれてのコンピュータのリソースの原価漸減)まで下がることができます。
9. Acknowledgments
9. 承認
Many reviewers provided valuable comments on earlier drafts of this document. Some fruitful discussions took place on the email list of the Crypto Forum Research Group in 2006.
多くの評論家がこのドキュメントの以前の草稿の貴重なコメントを提供しました。 いくつかの有意義な論議が2006年にCrypto Forum Research Groupのメールリストで行われました。
McGrew Standards Track [Page 18] RFC 5116 Authenticated Encryption January 2008
暗号化2008年1月に認証されたマグリュー標準化過程[18ページ]RFC5116
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[CCM] Dworkin, M., "NIST Special Publication 800-38C: The CCM
Mode for Authentication and Confidentiality", U.S.
National Institute of Standards and Technology,
<http://csrc.nist.gov/publications/nistpubs/800-38C/
SP800-38C.pdf>.
ドーキン、[立方センチメートル]M.、「NISTの特別な公表800-38C:」 「認証と秘密性のための立方センチメートルモード」、米国米国商務省標準技術局、<http://csrc.nist.gov/刊行物/nistpubs/800-38C/SP800-38C. pdf>。
[GCM] Dworkin, M., "NIST Special Publication 800-38D:
Recommendation for Block Cipher Modes of Operation:
Galois/Counter Mode (GCM) and GMAC.", U.S. National
Institute of Standards and Technology, November 2007,
<http://csrc.nist.gov/publications/nistpubs/800-38D/
SP-800-38D.pdf>.
[GCM]ドーキン、M.、「NISTの特別な公表800-38D:」 ブロック暗号運転モードのための推薦: 「ガロア/カウンタモード(GCM)とGMAC」、米国米国商務省標準技術局、2007年11月、<http://csrc.nist.gov/刊行物/nistpubs/800-38D/SP-800-38D. pdf>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
10.2. Informative References
10.2. 有益な参照
[BN00] Bellare, M. and C. Namprempre, "Authenticated encryption:
Relations among notions and analysis of the generic
composition paradigm", Proceedings of ASIACRYPT 2000,
Springer-Verlag, LNCS 1976, pp. 531-545, 2002.
[BN00] Bellare、M.、およびC.Namprempre、「認証された暗号化:」 「ジェネリック構成パラダイムの概念と分析の中の関係」、ASIACRYPT2000、Springer-Verlag、LNCS1976、ページのProceedings 531-545, 2002.
[BOYD] Boyd, C. and A. Mathuria, "Protocols for Authentication
and Key Establishment", Springer 2003.
[ボイド]ボイド、C.とA.Mathuria、「認証と主要な設立のためのプロトコル」追出石2003。
[CMAC] "NIST Special Publication 800-38B", <http://csrc.nist.gov/
publications/nistpubs/800-38B/SP_800-38B.pdf>.
[CMAC]「NIST特別な公表800-38B」、<http://csrc.nist.gov/刊行物/nistpubs/800-38B/SP_800-38B.pdf>。
[EEM04] Bellare, M., Namprempre, C., and T. Kohno, "Breaking and
provably repairing the SSH authenticated encryption
scheme: A case study of the Encode-then-Encrypt-and-MAC
paradigm", ACM Transactions on Information and
System Security,
<http://www-cse.ucsd.edu/users/tkohno/papers/TISSEC04/>.
[EEM04] Bellare、M.、Namprempre、C.、およびT.河野、「SSHを壊して、証明可能、修理すると、暗号化体系は認証されました」。 「ケーススタディ、次に、Encodeが暗号化する、MAC、パラダイム、」、情報とSystem Securityの上のACM Transactions、<http://www-cse.ucsd.edu/users/tkohno/papers/TISSEC04/>。
[GR05] Garfinkel, T. and M. Rosenblum, "When Virtual is Harder
than Real: Security Challenges in Virtual Machine Based
Computing Environments", Proceedings of the 10th Workshop
on Hot Topics in Operating Systems,
<http://www.stanford.edu/~talg/papers/HOTOS05/
virtual-harder-hotos05.pdf>.
[GR05] ガーフィンケル、T.、およびM.ローゼンブラム、「いつVirtualはレアルよりハーダーです」。 「Virtual Machine Based Computing EnvironmentsのセキュリティChallenges」、Operating Systems(<http://www.stanford.edu/~仮想により固いtalg/書類/HOTOS05/hotos05.pdf>)のHot Topicsの上の第10WorkshopのProceedings。
McGrew Standards Track [Page 19] RFC 5116 Authenticated Encryption January 2008
暗号化2008年1月に認証されたマグリュー標準化過程[19ページ]RFC5116
[J02] Jonsson, J., "On the Security of CTR + CBC-MAC",
Proceedings of the 9th Annual Workshop on Selected Areas
on Cryptography, 2002, <http://csrc.nist.gov/groups/ST/
toolkit/BCM/documents/proposedmodes/ccm/ccm-ad1.pdf>.
[J02]イェンソン、「CTR+CBC-MACのセキュリティ」のJ.、暗号における選択された領域における第9例年のワークショップの議事、2002、<が://csrc.nist.gov/グループ/をhttpする、/立方センチメートルツールキット/BCM/書類/proposedmodes/立方センチメートル/ad1.pdf第>。
[MODES] Dworkin, M., "NIST Special Publication 800-38:
Recommendation for Block Cipher Modes of Operation", U.S.
National Institute of Standards and Technology,
<http://csrc.nist.gov/publications/nistpubs/800-38a/
sp800-38a.pdf>.
[モード]ドーキン、M.、「NISTの特別な公表800-38:」 「OperationのBlock Cipher Modesのための推薦」、米国米国商務省標準技術局、/sp800-38a. pdf>あたり<http://csrc.nist.gov/刊行物/nistpubs/800-38。
[MV04] McGrew, D. and J. Viega, "The Security and Performance of
the Galois/Counter Mode (GCM)", Proceedings of
INDOCRYPT '04, December 2004,
<http://eprint.iacr.org/2004/193>.
[MV04] マグリュー、D.、およびJ.Viega、「ガロア/のセキュリティと実績はモード(GCM)を打ち返します」、INDOCRYPT'04の2004年12月<httpな://eprint.iacr.org/2004/193>'の議事。
[R02] Rogaway, P., "Authenticated encryption with Associated-
Data", ACM Conference on Computer and Communication
Security (CCS'02), pp. 98-107, ACM Press, 2002,
<http://www.cs.ucdavis.edu/~rogaway/papers/ad.html>.
[R02]RogawayとP.と「Associatedデータとの認証された暗号化」とコンピュータの上のACMコンファレンスとCommunication Security(CCS'02)、ページ、' 98-107、ACMプレス、2002、<http://www.cs.ucdavis.edu/~rogaway/書類/ad.html>。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104,
February 1997.
[RFC2104] Krawczyk、H.、Bellare、M.、およびR.カネッティ、「HMAC:」 「通報認証のための合わせられた論じ尽くす」RFC2104、1997年2月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC2434]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]イーストレークとD.とシラー、J.とS.クロッカー、「セキュリティのための偶発性要件」BCP106、2005年6月のRFC4086。
[RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode
(GCM) in IPsec Encapsulating Security Payload (ESP)",
RFC 4106, June 2005.
[RFC4106] ViegaとJ.とD.マグリュー、「セキュリティが有効搭載量(超能力)であるとカプセル化するIPsecにおけるガロア/カウンタモード(GCM)の使用」、RFC4106、2005年6月。
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic
Key Management", BCP 107, RFC 4107, June 2005.
[RFC4107]Bellovin、S.とR.Housley、「暗号化キー管理のためのガイドライン」BCP107、2005年6月のRFC4107。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[RFC4303]ケント、S.、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC4303、2005年12月。
[RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM
Mode with IPsec Encapsulating Security Payload (ESP)",
RFC 4309, December 2005.
[RFC4309]Housley、R.、「IPsecが、セキュリティが有効搭載量(超能力)であるとカプセル化しているエー・イー・エス(AES)立方センチメートルモードを使用します」、RFC4309、2005年12月。
McGrew Standards Track [Page 20] RFC 5116 Authenticated Encryption January 2008
暗号化2008年1月に認証されたマグリュー標準化過程[20ページ]RFC5116
Author's Address
作者のアドレス
David A. McGrew Cisco Systems, Inc. 510 McCarthy Blvd. Milpitas, CA 95035 US
デヴィッドA.マグリューシスコシステムズInc.510マッカーシーBlvd. ミルピタス、カリフォルニア95035米国
Phone: (408) 525 8651 EMail: mcgrew@cisco.com URI: http://www.mindspring.com/~dmcgrew/dam.htm
以下に電話をしてください。 (408) 525 8651はメールされます: mcgrew@cisco.com ユリ: http://www.mindspring.com/~dmcgrew/dam.htm
McGrew Standards Track [Page 21] RFC 5116 Authenticated Encryption January 2008
暗号化2008年1月に認証されたマグリュー標準化過程[21ページ]RFC5116
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(2008)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
McGrew Standards Track [Page 22]
マグリュー標準化過程[22ページ]
一覧
スポンサーリンク
