Network Working Group D. Harkins
Request for Comments: 5297 Aruba Networks
Category: Informational October 2008
Synthetic Initialization Vector (SIV) Authenticated Encryption
Using the Advanced Encryption Standard (AES)
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Abstract
抽象
This memo describes SIV (Synthetic Initialization Vector), a block cipher mode of operation. SIV takes a key, a plaintext, and multiple variable-length octet strings that will be authenticated but not encrypted. It produces a ciphertext having the same length as the plaintext and a synthetic initialization vector. Depending on how it is used, SIV achieves either the goal of deterministic authenticated encryption or the goal of nonce-based, misuse-resistant authenticated encryption.
このメモは、SIV（合成初期化ベクトル）、操作のブロック暗号モードを記述する。 SIVは、鍵、平文、および認証されたが暗号化されていないことになる複数の可変長のオクテット文字列を取ります。これは、平文および合成初期化ベクトルと同じ長さの暗号文を生成します。それが使用されている方法に応じて、SIVは、決定論的、認証、暗号化の目標やナンスベース、誤用耐性認証された暗号化の目的のいずれかを達成します。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Background .................................................3
1.2. Definitions ................................................4
1.3. Motivation .................................................4
1.3.1. Key Wrapping ........................................4
1.3.2. Resistance to Nonce Misuse/Reuse ....................4
1.3.3. Key Derivation ......................................5
1.3.4. Robustness versus Performance .......................6
1.3.5. Conservation of Cryptographic Primitives ............6
2. Specification of SIV ............................................6
2.1. Notation ...................................................6
2.2. Overview ...................................................7
2.3. Doubling ...................................................7
2.4. S2V ........................................................8
2.5. CTR .......................................................10
2.6. SIV Encrypt ...............................................10
2.7. SIV Decrypt ...............................................12
3. Nonce-Based Authenticated Encryption with SIV ..................14
4. Deterministic Authenticated Encryption with SIV ................15
5. Optimizations ..................................................15
6. IANA Considerations ............................................15
6.1. AEAD_AES_SIV_CMAC_256 .....................................17
6.2. AEAD_AES_SIV_CMAC_384 .....................................17
6.3. AEAD_AES_SIV_CMAC_512 .....................................18
7. Security Considerations ........................................18
8. Acknowledgments ................................................19
9. References .....................................................19
9.1. Normative References ......................................19
9.2. Informative References ....................................19
Appendix A. Test Vectors ....................................... 22
A.1. Deterministic Authenticated Encryption Example ........... 22
A.2. Nonce-Based Authenticated Encryption Example ............. 23
Various attacks have been described (e.g., [BADESP]) when data is merely privacy protected and not additionally authenticated or integrity protected. Therefore, combined modes of encryption and authentication have been developed ([RFC5116], [RFC3610], [GCM], [JUTLA], [OCB]). These provide conventional authenticated encryption when used with a nonce ("a number used once") and typically accept additional inputs that are authenticated but not encrypted, hereinafter referred to as "associated data" or AD.
データは単にプライバシーが保護され、さらに認証済みまたは完全性が保護されていない場合、様々な攻撃（例えば、[BADESP]）に記載されています。したがって、暗号化と認証の合成モードが開発されている（[RFC5116]、[RFC3610]、[GCM]、[JUTLA]、[OCB]）。これらは、ノンス（「一度使用数」）で使用した場合、従来の認証された暗号化を提供し、典型的には、認証が、暗号化されていない追加の入力、以下、「関連データ」またはADと呼ばを受け入れます。
A deterministic, nonce-less, form of authenticated encryption has been used to protect the transportation of cryptographic keys (e.g., [X9F1], [RFC3217], [RFC3394]). This is generally referred to as "Key Wrapping".
認証された暗号化の決定論、ナンスレス、フォームは、暗号鍵の輸送（例えば、[X9F1]、[RFC3217]、[RFC3394]）を保護するために使用されてきました。これは、一般的に「キーラッピング」と呼ばれています。
This memo describes a new block cipher mode, SIV, that provides both nonce-based authenticated encryption as well as deterministic, nonce-less key wrapping. It contains a Pseudo-Random Function (PRF) construction called S2V and an encryption/decryption construction, called CTR. SIV was specified by Phillip Rogaway and Thomas Shrimpton in [DAE]. The underlying block cipher used herein for both S2V and CTR is AES with key lengths of 128 bits, 192 bits, or 256 bits. S2V uses AES in Cipher-based Message Authentication Code ([CMAC]) mode, CTR uses AES in counter ([MODES]) mode.
このメモは、両方のナンスベースの認証済みの暗号化だけでなく、決定論的、ナンスレスキーラッピングを提供する新しいブロック暗号モード、SIVを、説明しています。それはS2Vと呼ばれる擬似ランダム関数（PRF）建設とCTRと呼ばれる暗号化/復号化工事が含まれています。 SIVは、[DAE]でフィリップ・ロガウェイとトーマス・シュリンプトンで指定されました。 S2VとCTRの両方のために本明細書で使用される基礎となるブロック暗号は、128ビット、192ビット、または256ビットのキー長とAESです。 S2Vは、暗号ベースのメッセージ認証コード（[CMAC]）モードでAESを使用して、CTRはカウンタ（[MODES]）モードでAESを使用します。
Associated data is data input to an authenticated-encryption mode that will be authenticated but not encrypted. [RFC5116] says that associated data can include "addresses, ports, sequence numbers, protocol version numbers, and other fields that indicate how the plaintext or ciphertext should be handled, forwarded, or processed". These are multiple, distinct inputs and may not be contiguous. Other authenticated-encryption cipher modes allow only a single associated data input. Such a limitation may require implementation of a scatter/gather form of data marshalling to combine the multiple components of the associated data into a single input or may require a pre-processing step where the associated data inputs are concatenated together. SIV accepts multiple variable-length octet strings (hereinafter referred to as a "vector of strings") as associated data inputs. This obviates the need for data marshalling or pre-processing of associated data to package it into a single input.
関連するデータは、認証が暗号化されていないされます、認証・暗号化モードへのデータ入力です。 [RFC5116]は、関連するデータが「平文または暗号文の取扱い、転送、または処理されるべき方法を示すアドレス、ポート、シーケンス番号、プロトコルバージョン番号、および他のフィールド」を含むことができることを述べています。これらは、複数の別個の入力であり、連続でなくてもよいです。他の認証された暗号化暗号モードは、単一の関連するデータの入力を可能にします。そのような制限は、単一の入力に関連付けられたデータの複数のコンポーネントを結合するまたは関連するデータ入力が一緒に連結された前処理工程を必要とし得るマーシャリングデータのスキャッター/ギャザー形態の実装を必要とするかもしれません。 SIVは、関連するデータ入力として（以下、「文字列のベクター」と称する）は、複数の可変長オクテット列を受け付けます。これは、データマーシャリングまたは単一の入力にそれをパッケージに関連付けられるデータの前処理の必要がなくなります。
By allowing associated data to consist of a vector of strings SIV also obviates the requirement to encode the length of component fields of the associated data when those fields have variable length.
関連するデータが文字列SIVのベクトルで構成することを可能にすることによっても、これらのフィールドは可変長を有する場合、関連するデータの構成要素のフィールドの長さを符号化する必要がなくなります。
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 RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
A key distribution protocol must protect keys it is distributing. This has not always been done correctly. For example, RADIUS [RFC2865] uses Microsoft Point-to-Point Encryption (MPPE) [RFC2548] to encrypt a key prior to transmission from server to client. It provides no integrity checking of the encrypted key. [RADKEY] specifies the use of [RFC3394] to wrap a key in a RADIUS request but because of the inability to pass associated data, a Hashed Message Authentication Code (HMAC) [RFC2104] is necessary to provide authentication of the entire request.
鍵配布プロトコルは、それが配布された鍵を保護しなければなりません。これは常に正しく行われていません。たとえば、RADIUS [RFC2865]は、サーバからクライアントへの送信前にキーを暗号化するために、Microsoft Point-to-Point暗号化（MPPE）[RFC2548]を使用しています。それは、暗号化キーのない整合性チェックを提供していません。 【RADKEY]は関連するデータを渡すためにRADIUS要求ではなく、なぜなら不能のキーをラップする[RFC3394]の使用を指定し、ハッシュメッセージ認証コード（HMAC）[RFC2104]は全体の要求の認証を提供することが必要です。
SIV can be used as a drop-in replacement for any specification that uses [RFC3394] or [RFC3217], including the aforementioned use. It is a more general purpose solution as it allows for associated data to be specified.
SIVは、前述の使用を含む[RFC3394]または[RFC3217]を、使用するすべての仕様のドロップイン代替品として使用することができます。関連するデータを指定することが可能となるように、より汎用的な解決策です。
The nonce-based authenticated encryption schemes described above are susceptible to reuse and/or misuse of the nonce. Depending on the specific scheme there are subtle and critical requirements placed on the nonce (see [SP800-38D]). [GCM] states that it provides "excellent security" if its nonce is guaranteed to be distinct but provides "no security" otherwise. Confidentiality guarantees are voided if a counter in [RFC3610] is reused. In many cases, guaranteeing no reuse of a nonce/counter/IV is not a problem, but in others it will be.
上記ノンスベースの認証された暗号化方式は、再利用および/またはノンスの誤用の影響を受けやすいです。ナンスの上に置かれ、微妙な、重要な要件があり、特定の方式に応じて、（[SP800-38D]を参照）。 [GCM]そのナンスが明瞭であることが保証それ以外「はセキュリティ」を提供されていない場合、それは「優秀なセキュリティ」を提供することを述べています。 [RFC3610]でカウンタが再利用された場合に機密性の保証は無効とされています。多くの場合、ナンス/カウンタ/ IVのない再利用を保証していないことは問題ではありませんが、他の人にそれがされます。
For example, many applications obtain access to cryptographic functions via an application program interface to a cryptographic library. These libraries are typically not stateful and any nonce, initialization vector, or counter required by the cipher mode is passed to the cryptographic library by the application. Putting the construction of a security-critical datum outside the control of the encryption engine places an onerous burden on the application writer who may not provide the necessary cryptographic hygiene. Perhaps his random number generator is not very good or maybe an application fault causes a counter to be reset. The fragility of the cipher mode may result in its inadvertent misuse. Also, if one's environment is (knowingly or unknowingly) a virtual machine, it may be possible to roll back a virtual state machine and cause nonce reuse thereby gutting the security of the authenticated encryption scheme (see [VIRT]).
例えば、多くのアプリケーションでは、暗号化ライブラリへのアプリケーション・プログラム・インタフェースを介して暗号化機能へのアクセスを得ます。これらのライブラリは、通常、ステートフルでないと暗号モードで必要とされる任意のナンス、初期化ベクトル、またはカウンタは、アプリケーションによって暗号化ライブラリに渡されます。暗号化エンジンの制御外でセキュリティ上重要な基準の構築を置くことは必要な暗号衛生を提供することはできませんアプリケーションライターに面倒な負担を課します。おそらく、彼の乱数生成器は非常に良いではありませんか、多分アプリケーションの障害は、カウンタがリセットされます。暗号モードの脆弱性は、その不注意による誤用が生じることがあります。自分の環境が（故意または無意識の）仮想マシンをある場合も、それは仮想状態マシンをロールバックし、それによって認証された暗号化方式のセキュリティをguttingナンスの再利用を引き起こすことも可能である（[VIRT]を参照）。
If the nonce is random, a requirement that it never repeat will limit the amount of data that can be safely protected with a single key to one block. More sensibly, a random nonce is required to "almost always" be non-repeating, but that will drastically limit the amount of data that can be safely protected.
nonceがランダムである場合、それは二度と繰り返さない要件は、安全に一つのブロックに単一の鍵で保護することができるデータの量を制限します。もっと賢明に、ランダムなナンスは「ほとんど常に」非反復であることが要求されるが、それは劇的に安全に保護することができるデータの量を制限します。
SIV provides a level of resistance to nonce reuse and misuse. If the nonce is never reused, then the usual notion of nonce-based security of an authenticated encryption mode is achieved. If, however, the nonce is reused, authenticity is retained and confidentiality is only compromised to the extent that an attacker can determine that the same plaintext (and same associated data) was protected with the same nonce and key. See Security Considerations (Section 7).
SIVは一回だけの再利用及び誤用に対する抵抗性のレベルを提供します。ナンスが再使用されることはありません場合は、認証済み暗号化モードのナンスベースのセキュリティの通常の概念が達成されます。しかし、ノンスが再利用される場合、真偽が保持され、機密性のみ、攻撃者が同じ平文（同じ関連データ）が同じノンスとキーで保護されたと判断することができる程度に損なわれる。セキュリティの考慮事項（第7節）を参照してください。
A PRF is frequently used as a key derivation function (e.g., [WLAN]) by passing it a key and a single string. Typically, this single string is the concatenation of a series of smaller strings -- for example, a label and some context to bind into the derived string.
PRFは、しばしば、それをキーと単一の文字列を渡すことによって、鍵導出関数（例えば、[WLAN]）として使用されます。例えば、ラベルと派生文字列に結合するためにいくつかのコンテキスト - 典型的には、この単一の文字列は、より小さな一連の文字列の連結です。
These are usually multiple strings but are mapped to a single string because of the way PRFs are typically defined -- two inputs: a key and data. Such a crude mapping is inefficient because additional data must be included -- the length of variable-length inputs must be encoded separately -- and, depending on the PRF, memory allocation and copying may be needed. Also, if only one or two of the inputs changed when deriving a new key, it may still be necessary to process all of the other constants that preceded it every time the PRF is invoked.
これらは通常、複数の文字列ですが、一般的に定義されている方法のためのPRFの単一の文字列にマッピングされている - 二つの入力：キーとデータを。可変長入力の長さが別々に符号化されなければならない - - と、PRF、メモリの割り当てとコピーに応じて必要とされる追加のデータが含まれていなければならないので、このような粗マッピングは非効率的です。また、もし1つまたは2つの入力の新しいキーを導出する際に、まだそれをPRFが呼び出されるたびに先行する他の定数のすべてを処理する必要があるかもしれない変更しました。
When a PRF is used in this manner its input is a vector of strings and not a single string and the PRF should handle the data as such. The S2V ("string to vector") PRF construction accepts a vector of inputs and provides a more natural mapping of input that does not require additional lengths encodings and obviates the memory and processing overhead to marshal inputs and their encoded lengths into a single string. Constant inputs to the PRF need only be computed once.
PRFがこのように使用される場合、その入力は、文字列のベクトルではなく、単一の文字列とPRFのようなデータを処理します。 S2V（「ベクターに文字列」）PRF構造の入力ベクトルを受け取り、追加の長さのエンコーディングを必要とし、単一の文字列に入力し、その符号化された長さをマーシャリングするためのメモリと処理オーバーヘッドをなくすない入力のより自然なマッピングを提供します。 PRFの定数の入力は一度だけ計算される必要があります。
SIV cannot perform at the same high throughput rates that other authenticated encryption schemes can (e.g., [GCM] or [OCB]) due to the requirement for two passes of the data, but for situations where performance is not a limiting factor -- e.g., control plane applications -- it can provide a robust alternative, especially when considering its resistance to nonce reuse.
SIVは、同じ高スループット・レートで行うことができない他の認証された暗号化方式（例えば、[GCM]または[OCB]）による性能制限要因ではなく、状況のために2つのデータパスのための要件に - 例えば、プレーン・アプリケーションを制御する - それは、特に一回だけの再利用に対する抵抗性を考慮した場合、堅牢な代替手段を提供することができます。
The cipher mode described herein can do authenticated encryption, key wrapping, key derivation, and serve as a generic message authentication algorithm. It is therefore possible to implement all these functions with a single tool, instead of one tool for each function. This is extremely attractive for devices that are memory and/or processor constrained and that cannot afford to implement multiple cryptographic primitives to accomplish these functions.
本明細書中に記載の暗号方式は、認証、暗号化、鍵ラッピング、鍵導出を行うと、一般的なメッセージ認証アルゴリズムとして機能することができます。その代わりに、各機能のための1つのツール、単一のツールを用いてこれらのすべての機能を実現することが可能です。これは、メモリおよび/またはプロセッサに拘束され、それは、これらの機能を達成するために、複数の暗号プリミティブを実装する余裕がないデバイスのための非常に魅力的です。
SIV and S2V use the following notation:
SIVとS2Vは、以下の表記を使用します。
len(A) returns the number of bits in A.
LEN（A）はAのビット数を返します
pad(X) indicates padding of string X, len(X) < 128, out to 128 bits by the concatenation of a single bit of 1 followed by as many 0 bits as are necessary.
パッド（X）が必要と同じ数の0のビットに続いて1つのビットの連結によってLEN（X）<128、128ビットのうち、文字列Xのパディングを示しています。
leftmost(A,n) the n most significant bits of A.
左端（A、N）Aの最上位ビット
rightmost(A,n) the n least significant bits of A.
右端（A、N）Aの最下位ビット
A || B means concatenation of string A with string B.
|| Bは、文字列Bと文字列Aの連結を意味します
A xor B is the exclusive OR operation on two equal length strings, A and B.
XOR Bは二つの等しい長さの文字列、AとBの排他的論理和演算であります
A xorend B where len(A) >= len(B), means xoring a string B onto the end of string A -- i.e., leftmost(A, len(A)-len(B)) || (rightmost(A, len(B)) xor B).
xorendのB LEN（A）> = LEN（B）、列Aの最後に文字列BをXOR演算手段 - （A、LEN（A）-len（B））、すなわち、左端|| （右端（A、LEN（B））のXOR B）。
A bitand B is the logical AND operation on two equal length strings, A and B.
BITAND Bは二つの等しい長さの文字列、AとBの論理AND演算であります
dbl(S) is the multiplication of S and 0...010 in the finite field represented using the primitive polynomial x^128 + x^7 + x^2 + x + 1. See Doubling (Section 2.3).
DBL（S）は原始多項式X ^ 128 + X ^ 7 + X ^ 2 + X + 1倍増を参照してください（セクション2.3）を使用して表現有限体でSと0 ... 010の乗算です。
a^b indicates a string that is "b" bits, each having the value "a".
^ Bは、それぞれ値「A」を有し、「B」ビットである列を示しています。
<zero> indicates a string that is 128 zero bits.
<ゼロ> 128ゼロビットである列を示しています。
<one> indicates a string that is 127 zero bits concatenated with a single one bit, that is 0^127 || 1^1.
<1>単一の1ビットと連結127ゼロビットである列を示し、それは^ 127 0 || 1 ^ 1。
A/B indicates the greatest integer less than or equal to the real-valued quotient of A and B.
A / Bは、AとBの実数値の商の最大整数以下を示し
E(K,X) indicates AES encryption of string X using key K.
E（K、X）は、鍵Kを用いて、文字列XのAES暗号化を示し
SIV-AES uses AES in CMAC mode (S2V) and in counter mode (CTR). SIV-AES takes either a 256-, 384-, or 512-bit key (which is broken up into two equal-sized keys, one for S2V and the other for CTR), a variable length plaintext, and multiple variable-length strings representing associated data. Its output is a ciphertext that comprises a synthetic initialization vector concatenated with the encrypted plaintext.
SIV-AESは、CMACモード（S2V）およびカウンタモード（CTR）にAESを使用します。 SIV-AESは、可変長平文、および複数の可変長文字列（2つの等サイズのキー、S2V用とCTRのための他に分割されている）256、384、または512ビットのキーのいずれかを取り関連するデータを表します。その出力は暗号化された平文と連結合成初期化ベクトルを含む暗号文です。
The doubling operation on a 128-bit input string is performed using a left-shift of the input followed by a conditional xor operation on the result with the constant:
128ビットの入力列に倍増操作が一定で結果を条件XOR演算続い入力の左シフトを用いて実行されます。
00000000 00000000 00000000 00000087
００００００００ ００００００００ ００００００００ ００００００８７
The condition under which the xor operation is performed is when the bit being shifted off is one.
オフシフトされたビットが1である場合にXOR演算が実行される条件です。
Note that this is the same operation used to generate sub-keys for CMAC-AES.
これはCMAC-AES用のサブ鍵を生成するために使用したのと同じ動作であることに留意されたいです。
The S2V operation consists of the doubling and xoring of the outputs of a pseudo-random function, CMAC, operating over individual strings in the input vector: S1, S2, ... , Sn. It is bootstrapped by performing CMAC on a 128-bit string of zeros. If the length of the final string in the vector is greater than or equal to 128 bits, the output of the double/xor chain is xored onto the end of the final input string. That result is input to a final CMAC operation to produce the output V. If the length of the final string is less than 128 bits, the output of the double/xor chain is doubled once more and it is xored with the final string padded using the padding function pad(X). That result is input to a final CMAC operation to produce the output V.
S1、S2、...、Snの：S2V操作は、入力ベクトルの個々の文字列で動作し、擬似ランダム関数、CMACの出力の倍増と排他的論理和から成ります。これは、ゼロの128ビット列でCMACを実行することによってブートストラップされます。ベクターの最後の文字列の長さがより大きいか128ビットに等しい場合、二重/ XORチェーンの出力は、最終入力文字列の末尾にXORされます。その結果、最終的な文字列の長さが128ビット未満である場合、出力Vを生成するために、最終的なCMAC動作に入力され、二重/ XORチェーンの出力が再び倍増され、それは最終の列とXORされ、使用パディングパディング機能パッド（X）。その結果は、出力Vを生成するために、最終的なCMAC操作に入力されます
S2V with key K on a vector of n inputs S1, S2, ..., Sn-1, Sn, and len(Sn) >= 128:
N個の入力S1、S2、...、Sn-1に、SnおよびLEN（SN）のベクトルのキーKとS2V> = 128：
+----+ +----+ +------+ +----+
| S1 | | S2 | . . . | Sn-1 | | Sn |
+----+ +----+ +------+ +----+
<zero> K | | | |
| | | | | V
V | V V V /----> xorend
+-----+ | +-----+ +-----+ +-----+ | |
| AES-|<----->| AES-| K-->| AES-| K--->| AES-| | |
| CMAC| | CMAC| | CMAC| | CMAC| | |
+-----+ +-----+ +-----+ +-----+ | V
| | | | | +-----+
| | | | | K-->| AES-|
| | | | | | CMAC|
| | | | | +-----+
\-> dbl -> xor -> dbl -> xor -> dbl -> xor---/ |
V
+---+
| V |
+---+
Figure 2
図2
S2V with key K on a vector of n inputs S1, S2, ..., Sn-1, Sn, and len(Sn) < 128:
N個の入力S1、S2、...、Sn-1に、SnおよびLEN（SN）<128のベクトルのキーKとS2V。
+----+ +----+ +------+ +---------+
| S1 | | S2 | . . . | Sn-1 | | pad(Sn) |
+----+ +----+ +------+ +---------+
<zero> K | | | |
| | | | | V
V | V V V /------> xor
+-----+ | +-----+ +-----+ +-----+ | |
| AES-|<--->| AES-| K-->| AES-| K-->| AES-| | |
| CMAC| | CMAC| | CMAC| | CMAC| | |
+-----+ +-----+ +-----+ +-----+ | V
| | | | | +-----+
| | | | | K-->| AES-|
| | | | | | CMAC|
| | | | | +-----+
\-> dbl -> xor -> dbl -> xor -> dbl -> xor-> dbl |
V
+---+
| V |
+---+
Figure 3
図3
Algorithmically S2V can be described as:
アルゴリズムS2Vは次のように説明することができます。
S2V(K, S1, ..., Sn) { if n = 0 then return V = AES-CMAC(K, <one>) fi D = AES-CMAC(K, <zero>) for i = 1 to n-1 do D = dbl(D) xor AES-CMAC(K, Si) done if len(Sn) >= 128 then T = Sn xorend D else T = dbl(D) xor pad(Sn) fi return V = AES-CMAC(K, T) }
S2V（K、S1、...、Sn）の{n = 0の場合、戻りV = AES-CMAC（K、<1>）のfi D = AES-CMAC（K、<ゼロ>）のためにI = 1からnまでlenの場合は-1のD =のDBL（D）XOR AES-CMAC（K、Si）は（SN）> = 128次いでT = Sn系xorend他DのT = DBL（D）のXORパッド（SN）のfi戻りV = AES行いません-CMAC（K、T）}
CTR is a counter mode of AES. It takes as input a plaintext P of arbitrary length, a key K of length 128, 192, or 256 bits, and a counter X that is 128 bits in length, and outputs Z, which represents a concatenation of a synthetic initialization vector V and the ciphertext C, which is the same length as the plaintext.
CTRは、AESのカウンタモードです。それは、入力として任意の長さの平文Pをとり、合成初期ベクトルVの連結を表す鍵長128、192 K、または256ビットで、長さは128ビットであり、およびZを出力するカウンタX、及び平文と同じ長さである暗号文C、。
The ciphertext is produced by xoring the plaintext with the first len(P) bits of the following string:
暗号文は、次の文字列の最初のLEN（P）ビットで平文のXORをとることによって生成されます。
E(K, X) || E(K, X+1) || E(K, X+2) || ...
E（K、X）|| E（K、X + 1）|| E（K、X + 2）|| ...
Before beginning counter mode, the 31st and 63rd bits (where the rightmost bit is the 0th bit) of the counter are cleared. This enables implementations that support native 32-bit (64-bit) addition to increment the counter modulo 2^32 (2^64) in a manner that cannot be distinguished from 128-bit increments, as long as the number of increment operations is limited by an upper bound that safely avoids carry to occur out of the respective pre-cleared bit. More formally, for 32-bit addition, the counter is incremented as:
カウンタモードを開始する前に、カウンタの第31及び第63ビットが（右端のビットが0ビットである場合）をクリアしています。これは、長いインクリメント操作の数であるように、128ビットずつ区別できないようにして、カウンタモジュロ2 ^ 32（2 ^ 64）をインクリメントするネイティブの32ビット（64ビット）加算をサポートする実装を可能にします上限によって制限安全に各プレクリアビットから発生する運ぶ避けること。より形式的には、32ビットの加算のために、カウンタは次のようにインクリメントされます。
SALT=leftmost(X,96)
SALT =左端（X、96）
n=rightmost(X,32)
N =右端（X、32）
X+i = SALT || (n + i mod 2^32).
X + I = SALT || （N + iが2 ^ 32をMOD）。
For 64-bit addition, the counter is incremented as:
64ビット加算のために、カウンタは次のようにインクリメントされます。
SALT=leftmost(X,64)
SALT =左端（X、64）
n=rightmost(X,64)
N =右端（X、64）
X+i = SALT || (n + i mod 2^64).
X + I = SALT || （N + iが2 ^ 64をMOD）。
Performing 32-bit or 64-bit addition on the counter will limit the amount of plaintext that can be safely protected by SIV-AES to 2^39 - 128 bits or 2^71 - 128 bits, respectively.
それぞれ、128ビット - 128ビットまたは2 ^ 71 - カウンターで32ビットまたは64ビットの加算を行うことにより、安全に2 ^ 39にSIV-AESによって保護することができる平文の量を制限します。
SIV-encrypt takes as input a key K of length 256, 384, or 512 bits, plaintext of arbitrary length, and a vector of associated data AD[ ] where the number of components in the vector is not greater than 126 (see Section 7). It produces output, Z, which is the concatenation of a 128-bit synthetic initialization vector and ciphertext whose length is equal to the length of the plaintext.
SIV暗号化入力として鍵長256、384 K、または512ビット、任意の長さの平文、ベクトル中の成分の数が126より大きくない関連データAD []のベクトルをとり（セクション7参照）。それは長さ平文の長さに等しい、128ビット合成の初期化ベクトル及び暗号文の連結された出力、Zを生成します。
The key is split into equal halves, K1 = leftmost(K, len(K)/2) and K2 = rightmost(K, len(K)/2). K1 is used for S2V and K2 is used for CTR.
鍵が等しい半分に分割され、K1 =左端（K、LEN（K）/ 2）及びK2 =右端（K、LEN（K）/ 2）。 K1はS2Vのために使用され、K2は、CTRのために使用されています。
In the encryption mode, the associated data and plaintext represent the vector of inputs to S2V, with the plaintext being the last string in the vector. The output of S2V is a synthetic IV that represents the initial counter to CTR.
暗号化モードでは、関連データと平文が平文ベクトルにおける最後の文字列であると、S2Vへの入力のベクトルを表します。 S2Vの出力は、CTRの初期カウンタを表す合成IVです。
The encryption construction of SIV is as follows:
次のようにSIVの暗号化構造は次のとおりです。
+------+ +------+ +------+ +---+
| AD 1 | | AD 2 |...| AD n | | P |
+------+ +------+ +------+ +---+
| | | |
| | ... | ------------------|
\ | / / |
\ | / / +------------+ |
\ | / / | K = K1||K2 | |
\ | / / +------------+ V
\ | / / | | +-----+
\ | / / K1 | | K2 | |
\ | / / ------/ \------>| CTR |
\ | / / / ------->| |
| | | | | | +-----+
V V V V V | |
+------------+ +--------+ V
| S2V |------>| V | +----+
+------------+ +--------+ | C |
| +----+
| |
-----\ |
\ |
\ |
V V
+-----+
| Z |
+-----+
where the plaintext is P, the associated data is AD1 through ADn, V is the synthetic IV, the ciphertext is C, and Z is the output.
平文がPである場合、関連するデータは、貫通AD1であり、Vは、合成IVであり、暗号文がCであり、そしてZが出力されます。
Figure 8
図8
Algorithmically, SIV Encrypt can be described as:
アルゴリズム的に、SIV暗号化は次のように説明することができます。
SIV-ENCRYPT(K, P, AD1, ..., ADn) { K1 = leftmost(K, len(K)/2) K2 = rightmost(K, len(K)/2) V = S2V(K1, AD1, ..., ADn, P) Q = V bitand (1^64 || 0^1 || 1^31 || 0^1 || 1^31) m = (len(P) + 127)/128
SIV-ENCRYPT（K、P、AD1、...、ADnを）{K1 =左端（K、LEN（K）/ 2）K2 =右端（K、LEN（K）/ 2）V = S2V（K1、AD1 、...、ADnを、P）、Q = V BITAND（1 ^ 64 || 0 ^ 1 || 1 ^ 31 || 0 ^ 1 || 1 ^ 31）、M =（LEN（P）+ 127）/ 128
for i = 0 to m-1 do Xi = AES(K2, Q+i) done X = leftmost(X0 || ... || Xm-1, len(P)) C = P xor X
M-1にI = 0西= AES（K2、Q + i）はX =左端（X0 || ... || XM-1、LEN（P））C = P XOR X行いません
return V || C }
Vを返す|| C}
where the key length used by AES in CTR and S2V is len(K)/2 and will each be either 128 bits, 192 bits, or 256 bits.
ここで、CTRとS2VにAESにより使用されるキーの長さは、（K）/ 2でlenされ、各128ビット、192ビット、または256ビットのいずれかであろう。
The 31st and 63rd bit (where the rightmost bit is the 0th) of the counter are zeroed out just prior to being used by CTR for optimization purposes, see Section 5.
カウンタの31及び63ビット（右端のビットが0番目である）セクション5を参照して、直前の最適化のためにCTRによって使用されることにゼロにされます。
SIV-decrypt takes as input a key K of length 256, 384, or 512 bits, Z, which represents a synthetic initialization vector V concatenated with a ciphertext C, and a vector of associated data AD[ ] where the number of components in the vector is not greater than 126 (see Section 7). It produces either the original plaintext or the special symbol FAIL.
SIV-復号化は、入力として、鍵長256 K、384、または512ビット、暗号文Cとの連結合成初期ベクトルVを表し、Z、および関連するデータADのベクトルのコンポーネントの[]数を取りベクターが126より大きくない（セクション7参照）。これは、元の平文または特殊記号FAILのいずれかを生成します。
The key is split as specified in Section 2.6
2.6節に指定されているキーが分割され、
The synthetic initialization vector acts as the initial counter to CTR to decrypt the ciphertext. The associated data and the output of CTR represent a vector of strings that is passed to S2V, with the CTR output being the last string in the vector. The output of S2V is then compared against the synthetic IV that accompanied the original ciphertext. If they match, the output from CTR is returned as the decrypted and authenticated plaintext; otherwise, the special symbol FAIL is returned.
合成初期化ベクトルは、暗号文を解読するCTRの初期カウンタとして作用します。関連データとCTRの出力は、CTRの出力は、ベクトルの最後の列であると、S2Vに渡される文字列のベクトルを表します。 S2Vの出力は、元の暗号文を伴う合成IVと比較されます。それらが一致した場合、CTRからの出力は、復号化され、認証された平文として返されます。それ以外の場合は、特殊記号FAILが返されます。
The decryption construction of SIV is as follows:
次のようにSIVの復号化構造は次のとおりです。
+------+ +------+ +------+ +---+
| AD 1 | | AD 2 |...| AD n | | P |
+------+ +------+ +------+ +---+
| | | ^
| | ... / |
| | / /----------------|
| | / / |
\ | / / +------------+ |
\ | / / | K = K1||k2 | |
\ | / / +------------+ |
\ | / / | | +-----+
\ | / / K1 | | K2 | |
\ | | | /-----/ \----->| CTR |
\ | | | | ------->| |
| | | | | | +-----+
V V V V V | ^
+-------------+ +--------+ |
| S2V | | V | +---+
+-------------+ +--------+ | C |
| | ^ +---+
| | | ^
| | \ |
| | \___ |
V V \ |
+-------+ +---------+ +---+
| T |----->| if != | | Z |
+-------+ +---------+ +---+
|
|
V
FAIL
Figure 10
図10
Algorithmically, SIV-Decrypt can be described as:
アルゴリズム的に、SIV-復号化は次のように説明することができます。
SIV-DECRYPT(K, Z, AD1, ..., ADn) { V = leftmost(Z, 128) C = rightmost(Z, len(Z)-128) K1 = leftmost(K, len(K)/2) K2 = rightmost(K, len(K)/2) Q = V bitand (1^64 || 0^1 || 1^31 || 0^1 || 1^31)
SIV-解読（K、Z、AD1、...、？N）= {左端W（Z、128）右端C（Z、のみ（Z）-128）K1 =左端（C、のみ（C）/ 2 ）K2 =右端（C、のみ（C）/ 2）Q = W BITAND（1 ^ 64 ^ 1 || 0 || 1 || 0 ^ 31 ^ 1 ^ || 31）
m = (len(C) + 127)/128 for i = 0 to m-1 do Xi = AES(K2, Q+i) done X = leftmost(X0 || ... || Xm-1, len(C)) P = C xor X T = S2V(K1, AD1, ..., ADn, P)
M = M-1にI = 0（LEN（C）+ 127）/ 128西= AES（K2、Q + i）はX =左端行わない（X0 || ... || XM-1、LEN（ C））P = C XOR XT = S2V（K1、AD1、...、ADnを、P）
if T = V then return P else return FAIL fi }
T = Vは、次にPを返す場合はそう} FAIL FIを返します
where the key length used by AES in CTR and S2V is len(K)/2 and will each be either 128 bits, 192 bits, or 256 bits.
ここで、CTRとS2VにAESにより使用されるキーの長さは、（K）/ 2でlenされ、各128ビット、192ビット、または256ビットのいずれかであろう。
The 31st and 63rd bit (where the rightmost bit is the 0th) of the counter are zeroed out just prior to being used in CTR mode for optimization purposes, see Section 5.
カウンタの31及び63ビット（右端のビットが0番目である）セクション5を参照して、直前の最適化のためにCTRモードで使用されることにゼロにされます。
SIV performs nonce-based authenticated encryption when a component of the associated data is a nonce. For purposes of interoperability the final component -- i.e., the string immediately preceding the plaintext in the vector input to S2V -- is used for the nonce. Other associated data are optional. It is up to the specific application of SIV to specify how the rest of the associated data are input.
関連するデータの成分が一回だけである場合には、SIVナンスベースの認証済みの暗号化を行います。相互運用性の目的の最後の構成要素のために - つまり、直ちにS2Vにベクトル入力における平文の前に文字列が - 一回だけのために使用されます。他の関連するデータはオプションです。これは、関連するデータの残りの部分が入力されている方法を指定するSIVの特定のアプリケーション次第です。
If the nonce is random, it SHOULD be at least 128 bits in length and be harvested from a pool having at least 128 bits of entropy. A non-random source MAY also be used, for instance, a time stamp, or a counter. The definition of a nonce precludes reuse, but SIV is resistant to nonce reuse. See Section 1.3.2 for a discussion on the security implications of nonce reuse.
nonceがランダムである場合、それは長さが少なくとも128ビットであるべきであり、エントロピーの少なくとも128ビットを有するプールから採取されます。非ランダムソースはまた、例えば、タイムスタンプ、またはカウンタを併用してもよいです。ナンスの定義は、再利用を排除するが、SIVは一回だけの再利用に耐性があります。一回だけの再利用のセキュリティへの影響についての議論は、セクション1.3.2を参照してください。
It MAY be necessary to transport this nonce with the output generated by S2V.
S2Vによって生成された出力と、このナンスを輸送する必要があるかもしれません。
When the plaintext to encrypt and authenticate contains data that is unpredictable to an adversary -- for example, a secret key -- SIV can be used in a deterministic mode to perform "key wrapping". Because S2V allows for associated data and imposes no unnatural size restrictions on the data it is protecting, it is a more useful and general purpose solution than [RFC3394]. Protocols that use SIV for deterministic authenticated encryption (i.e., for more than just wrapping of keys) MAY define associated data inputs to SIV. It is not necessary to add a nonce component to the AD in this case.
暗号化と認証する平文が敵に予測できないデータが含まれている場合 - 例えば、秘密鍵 - SIVは、「キーラッピング」を実行するために、決定論モードで使用することができます。 S2Vは、関連するデータを可能にし、それが保護しているデータには不自然なサイズ制限を課していないので、それは[RFC3394]より有用な汎用ソリューションです。 （即ち、単に鍵のラッピングよりための）決定的認証、暗号化のためのSIVを使用するプロトコルは、SIVに関連付けられたデータ入力を定義することができます。この場合にはADにナンス・コンポーネントを追加する必要はありません。
Implementations that cannot or do not wish to support addition modulo 2^128 can take advantage of the fact that the 31st and 63rd bits (where the rightmost bit is the 0th bit) in the counter are cleared before being used by CTR. This allows implementations that natively support 32-bit or 64-bit addition to increment the counter naturally. Of course, in this case, the amount of plaintext that can be safely protected by SIV is reduced by a commensurate amount -- addition modulo 2^32 limits plaintext to (2^39 - 128) bits, addition modulo 2^64 limits plaintext to (2^71 - 128) bits.
または加算剰余2 ^ 128をサポートしたくないことはできない実装は、カウンターでの（右端のビットは0ビットです）31日と第63ビットはCTRによって使用される前にクリアされているという事実を利用することができます。これは、ネイティブ自然にカウンタを増分する32ビットまたは64ビットの加算をサポートする実装を可能にします。平文ビット、加算モジュロ2 ^ 64件の限界 - （128 2 ^ 39）に2 ^ 32の制限平文加算モジュロ - もちろん、この場合には、安全SIVによって保護することができる平文の量は相応の量だけ減少しますビット - （128 2 ^ 71）へ。
It is possible to optimize an implementation of S2V when it is being used as a key derivation function (KDF), for example in [WLAN]. This is because S2V operates on a vector of distinct strings and typically the data passed to a KDF contains constant strings. Depending on the location of variant components of the input different optimizations are possible. The CMACed output of intermediate and invariant components can be computed once and cached. This can then be doubled and xored with the running sum to produce the output. Or an intermediate value that represents the doubled and xored output of multiple components, up to the variant component, can be computed once and cached.
[WLAN]で、例えば鍵導出関数（KDF）として使用されている場合S2Vの実装を最適化することが可能です。 S2Vは明確な文字列のベクトルに作用し、一般的にKDFに渡されるデータは、定数文字列が含まれているためです。入力異なる最適化の変形成分の位置に応じて可能です。中間体および不変成分のCMACed出力は、一度計算しキャッシュすることができます。そして、これは倍増し、出力を生成するために実行しているサムとXORすることができます。または複数の構成要素の倍増とXORさ出力を表す中間値は、バリアントの成分まで、一度計算しキャッシュすることができます。
[RFC5116] defines a uniform interface to cipher modes that provide nonce-based Authenticated Encryption with Associated Data (AEAD). It does this via a registry of AEAD algorithms.
[RFC5116]は、関連するデータ（AEAD）とノンスベースの認証の暗号化を提供する暗号モードに統一されたインタフェースを定義します。それはAEADアルゴリズムのレジストリを経由してこれを行います。
The Internet Assigned Numbers Authority (IANA) assigned three entries from the AEAD Registry for AES-SIV-CMAC-256 (15), AES-SIV-CMAC-384 (16), and AES-SIV-CMAC-512 (17) based upon the following AEAD algorithm definitions. [RFC5116] defines operations in octets, not bits. Limits in this section will therefore be specified in octets. The security analysis for each of these algorithms is in [DAE].
AES-SIV-CMAC-256のためAEADレジストリからの3つのエントリを割り当てられたインターネット割り当て番号機関（IANA）（15）は、AES-SIV-CMAC-384（16）、およびAES-SIV-CMAC-512（17）ベース次AEADアルゴリズムの定義に依存します。 [RFC5116]はオクテットではないビットでの動作を定義します。このセクションの制限は、したがって、オクテットで指定されます。これらのアルゴリズムのそれぞれのためのセキュリティ分析は、[DAE]です。
Unfortunately, [RFC5116] restricts AD input to a single component and limits the benefit SIV offers for dealing in a natural fashion with AD consisting of multiple distinct components. Therefore, when it is required to access SIV through the interface defined in [RFC5116], it is necessary to marshal multiple AD inputs into a single string (see Section 1.1) prior to invoking SIV. Note that this requirement is not unique to SIV. All cipher modes using [RFC5116] MUST similarly marshal multiple AD inputs into a single string, and any technique used for any other AEAD mode (e.g., a scatter/gather technique) can be used with SIV.
残念ながら、[RFC5116]は、単一のコンポーネントにAD入力を制限し、SIVは、複数の別個の構成要素からなるADと自然な方法で処理するための提供の利益を制限します。 [RFC5116]で定義されたインタフェースを介してSIVにアクセスするために必要とされる場合、したがって、SIVを呼び出す前に（セクション1.1を参照）は、単一の文字列に複数のAD入力をマーシャリングする必要があります。この要件は、SIVに特有のものではないことに注意してください。 [RFC5116]を使用して、すべての暗号モードは同様に単一の文字列に複数のAD入力をマーシャリングする必要があり、そして他のAEADモードに使用される任意の技術（例えば、散乱/技術を収集）SIVと共に使用することができます。
[RFC5116] requires AEAD algorithm specifications to include maximal limits to the amount of plaintext, the amount of associated data, and the size of a nonce that the AEAD algorithm can accept.
[RFC5116]は平文の量は、関連するデータの量、およびAEADアルゴリズムが受け入れることができるノンスのサイズに対する最大の制限を含むようにAEADアルゴリズムの仕様を必要とします。
SIV uses AES in counter mode and the security guarantees of SIV would be lost if the counter was allowed to repeat. Since the counter is 128 bits, a limit to the amount of plaintext that can be safely protected by a single invocation of SIV is 2^128 blocks.
SIVは、カウンタモードでAESを使用し、カウンタはリピートさせた場合のSIVのセキュリティ保証が失われてしまいます。カウンタが128ビットであるので、安全にSIVの単一の呼び出しによって保護することができる平文の量には制限が2 ^ 128ブロックです。
To prevent the possibility of collisions, [CMAC] recommends that no more than 2^48 invocations be made to CMAC with the same key. This is not a limit on the amount of data that can be passed to CMAC, though. There is no practical limit to the amount of data that can be made to a single invocation of CMAC, and likewise, there is no practical limit to the amount of associated data or nonce material that can be passed to SIV.
衝突の可能性を防止するために、[CMAC]はもはや48 ^ 2より呼び出しが同じキーでCMACに対して行われることをお勧めします。これは、しかし、CMACに渡すことができるデータの量に制限はありません。 CMACの単一の呼び出しにすることができるデータの量に実際的な制限はありません、そして、同様に、SIVに渡すことができ、関連するデータまたはノンス材料の量に実際的な制限はありません。
A collision in the output of S2V would mean the same counter would be used with different plaintext in counter mode. This would void the security guarantees of SIV. The "Birthday Paradox" (see [APPCRY]) would imply that no more than 2^64 distinct invocations to SIV be made with the same key. It is prudent to follow the example of [CMAC] though, and further limit the number of distinct invocations of SIV using the same key to 2^48. Note that [RFC5116] does not provide a variable to describe this limit.
S2Vの出力における衝突は、カウンタモードで異なる平文で使用される同一のカウンタを意味します。これは、SIVのセキュリティ保証が無効になるでしょう。 「誕生日パラドックス」（[APPCRY]参照）SIVにこれ以上64 ^ 2以上の別個の呼び出しは、同じキーで作られることを暗示します。しかし[CMAC]の例に従う、さらに2 ^ 48に同じ鍵を使用して、SIVの別個の呼び出しの数を制限することが賢明です。 [RFC5116]はこの制限を記述するための変数を提供していないことに注意してください。
The counter-space for SIV is 2^128. Each invocation of SIV consumes a portion of that counter-space and the amount consumed depends on the amount of plaintext being passed to that single invocation. Multiple invocations of SIV with the same key can increase the possibility of distinct invocations overlapping the counter-space. The total amount of plaintext that can be safely protected with a single key is, therefore, a function of the number of distinct invocations and the amount of plaintext protected with each invocation.
SIVのためのカウンタースペースは2 ^ 128です。 SIVの各呼び出しは、そのカウンタースペースの一部を消費し、消費量は、その単一の呼び出しに渡される平文の量に依存します。同じキーを持つSIVの複数の呼び出しは、カウンタースペースを重複異なる呼び出しの可能性を高めることができます。安全に単一のキーを用いて保護することができる平文の総量は、したがって、異なる呼び出しの数と各呼び出しで保護平文の量の関数です。
The AES-SIV-CMAC-256 AEAD algorithm works as specified in Sections 2.6 and 2.7. The input and output lengths for AES-SIV-CMAC-256 as defined by [RFC5116] are:
セクション2.6および2.7に指定されているAES-SIV-CMAC-256 AEADアルゴリズムが動作します。 [RFC5116]で定義されるようにAES-SIV-CMAC-256の入力および出力長さです。
K_LEN is 32 octets.
K_LENは32オクテットです。
P_MAX is 2^132 octets.
P_MAXは2 ^ 132オクテットです。
A_MAX is unlimited.
A_MAXは無制限です。
N_MIN is 1 octet.
N_minは1つのオクテットです。
N_MAX is unlimited.
N_MAXは無制限です。
C_MAX is 2^132 + 16 octets.
C_MAXは2 ^ 132 + 16オクテットです。
The security implications of nonce reuse and/or misuse are described in Section 1.3.2.
一回だけの再利用および/または誤用のセキュリティへの影響は、1.3.2項で説明されています。
The AES-SIV-CMAC-384 AEAD algorithm works as specified in Sections 2.6 and 2.7. The input and output lengths for AES-SIV-CMAC-384 as defined by [RFC5116] are:
セクション2.6および2.7に指定されているAES-SIV-CMAC-384 AEADアルゴリズムが動作します。 [RFC5116]で定義されるようにAES-SIV-CMAC-384の入力および出力長さです。
K_LEN is 48 octets.
K_LENは48オクテットです。
P_MAX is 2^132 octets.
P_MAXは2 ^ 132オクテットです。
A_MAX is unlimited.
A_MAXは無制限です。
N_MIN is 1 octet.
N_minは1つのオクテットです。
N_MAX is unlimited.
N_MAXは無制限です。
C_MAX is 2^132 + 16 octets.
C_MAXは2 ^ 132 + 16オクテットです。
The security implications of nonce reuse and/or misuse are described in Section 1.3.2.
一回だけの再利用および/または誤用のセキュリティへの影響は、1.3.2項で説明されています。
The AES-SIV-CMAC-512 AEAD algorithm works as specified in Sections 2.6 and 2.7. The input and output lengths for AES-SIV-CMAC-512 as defined by [RFC5116] are:
セクション2.6および2.7に指定されているAES-SIV-CMAC-512 AEADアルゴリズムが動作します。 [RFC5116]で定義されるようにAES-SIV-CMAC-512の入力および出力長さです。
K_LEN is 64 octets.
K_LENは64オクテットです。
P_MAX is 2^132 octets.
P_MAXは2 ^ 132オクテットです。
A_MAX is unlimited.
A_MAXは無制限です。
N_MIN is 1 octet.
N_minは1つのオクテットです。
N_MAX is unlimited.
N_MAXは無制限です。
C_MAX is 2^132 + 16 octets.
C_MAXは2 ^ 132 + 16オクテットです。
The security implications of nonce reuse and/or misuse are described in Section 1.3.2.
一回だけの再利用および/または誤用のセキュリティへの影響は、1.3.2項で説明されています。
SIV provides confidentiality in the sense that the output of SIV-Encrypt is indistinguishable from a random string of bits. It provides authenticity in the sense that an attacker is unable to construct a string of bits that will return other than FAIL when input to SIV-Decrypt. A proof of the security of SIV with an "all-in-one" notion of security for an authenticated encryption scheme is provided in [DAE].
SIVは、SIV-暗号化の出力は、ビットのランダムな文字列と区別できないという意味で機密性を提供します。これは、攻撃者はSIV、復号化に失敗したときに入力以外返されたビット列を構築することができないという意味で信頼性を提供します。認証された暗号化方式のセキュリティの「オールインワン」という概念とSIVのセキュリティの証明は[DAE]で提供されています。
SIV provides deterministic "key wrapping" when the plaintext contains data that is unpredictable to an adversary (for instance, a cryptographic key). Even when this key is made available to an attacker the output of SIV-Encrypt is indistinguishable from random bits. Similarly, even when this key is made available to an attacker, she is unable to construct a string of bits that when input to SIV-Decrypt will return anything other than FAIL.
平文は、（例えば、暗号鍵）敵に予測不能なデータが含まれている場合、SIVは、確定「キーラッピング」を提供します。このキーが攻撃者に利用可能となる場合であってもSIV暗号化の出力は、ランダム・ビットと区別できません。同様に、このキーは、攻撃者が利用できるようにする場合であっても、彼女はSIV-復号化するための入力がFAIL以外のものを返しますビットの文字列を構築することができません。
When the nonce used in the nonce-based authenticated encryption mode of SIV-AES is treated with the care afforded a nonce or counter in other conventional nonce-based authenticated encryption schemes -- i.e., guarantee that it will never be used with the same key for two distinct invocations -- then SIV achieves the level of security described above. If, however, the nonce is reused SIV continues to provide the level of authenticity described above but with a slightly reduced amount of privacy (see Section 1.3.2).
SIV-AESのナンスベースの認証済み暗号化モードで使用されるナンスは、他の従来ナンスベースの認証済みの暗号化方式にナンスやカウンタを与え、注意して処理した場合 - すなわち、それは同じキーで使用されることはありませんことを保証二つの別個の呼び出しのために - 、次にSIVは、上述したセキュリティのレベルを達成します。しかし、nonceが再利用されるSIVは、上記しかしプライバシーのわずかに減少した量で記載真正性のレベルを提供し続けている場合（セクション1.3.2を参照）。
If S2V is used as a key derivation function, the secret input MUST be generated uniformly at random. S2V is a pseudo-random function and is not suitable for use as a random oracle as defined in [RANDORCL].
S2Vは、鍵導出関数として使用する場合、秘密の入力をランダムに一様に発生しなければなりません。 S2Vは、擬似ランダム関数であり、[RANDORCL]で定義されるようにランダムオラクルとして使用するのに適していません。
The security bound set by the proof of security of S2V in [DAE] depends on the number of vector-based queries made by an adversary and the total number of all components in those queries. The security is only proven when the number of components in each query is limited to n-1, where n is the blocksize of the underlying pseudo-random function. The underlying pseudo-random function used here is based on AES whose blocksize is 128 bits. Therefore, S2V must not be passed more than 127 components. Since SIV includes the plaintext as a component to S2V, that limits the number of components of associated data that can be safely passed to SIV to 126.
セキュリティが[DAE]でS2Vのセキュリティの証明によって設定された結合した敵およびそれらのクエリ内のすべてのコンポーネントの総数製ベクトルベースのクエリの数に依存します。セキュリティのみ各クエリ内のコンポーネントの数がn-1、nは、基礎となる擬似ランダム関数のブロックサイズであるに限定されているときに証明されています。ここで使用される基本的な擬似ランダム関数は、そのブロックサイズ128ビットであるAESに基づいています。したがって、S2Vは127個の以上の部品を通過してはなりません。 SIVはS2Vの成分として平文を含んでいるので、それは安全126にSIVに渡すことができ、関連するデータの構成要素の数を制限します。
Thanks to Phil Rogaway for patiently answering numerous questions on SIV and S2V and for useful critiques of earlier versions of this paper. Thanks also to David McGrew for numerous helpful comments and suggestions for improving this paper. Thanks to Jouni Malinen for reviewing this paper and producing another independent implementation of SIV, thereby confirming the correctness of the test vectors.
辛抱強くSIVとS2Vにこの論文の以前のバージョンの便利な批判のための多数の質問に答えるためのフィルRogawayに感謝します。この論文を向上させるため、多くの有益なコメントや提案のためのデビッドマグリューにも感謝します。これにより、テストベクトルの正当性を確認し、この論文を見直し、SIVの別の独立した実装を生成するためのJouni Malinenに感謝します。
[CMAC] Dworkin, M., "Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication", NIST Special Pulication 800-38B, May 2005.
[CMAC] Dworkin、M.、 "操作のブロック暗号モードのための推薦：認証のためのCMACモード"、NIST特別Pulication 800-38B、2005年5月。
[MODES] Dworkin, M., "Recommendation for Block Cipher Modes of Operation: Methods and Techniques", NIST Special Pulication 800-38A, 2001 edition.
[MODES] Dworkin、M.、 "ブロック暗号操作モードのための勧告：方法と技術"、NIST特別Pulication 800-38A、2001年版。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, January 2008.
[RFC5116]マグリュー、D.、 "認証暗号化のためのインタフェースとアルゴリズム"、RFC 5116、2008年1月。
[APPCRY] Menezes, A., van Oorshot, P., and S. Vanstone, "Handbook of Applied Cryptography", CRC Press Series on Discrete Mathematics and Its Applications, 1996.
離散数学とその応用、1996年[APPCRY]メネゼス、A.、バンOorshot、P.、およびS. Vanstone著、 "応用暗号のハンドブック"、CRCプレスシリーズ。
[BADESP] Bellovin, S., "Problem Areas for the IP Security Protocols", Proceedings from the 6th Usenix UNIX Security Symposium, July 22-25 1996.
[BADESP] Bellovin氏、S.、「IPセキュリティプロトコルの問題領域」、第六のUsenix UNIXセキュリティシンポジウム、1996年7月22〜25からの議事録。
[RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with CBC-MAC (CCM)", RFC 3610, September 2003.
[RFC3610]ホワイティング、D.、Housley氏、R.、およびN.ファーガソン、 "CBC-MAC（CCM）とカウンター"、RFC 3610、2003年9月。
[DAE] Rogaway, P. and T. Shrimpton, "Deterministic Authenticated Encryption, A Provable-Security Treatment of the Key-Wrap Problem", Advances in Cryptology -- EUROCRYPT '06 St. Petersburg, Russia, 2006.
[DAE] Rogaway、P.およびT.シュリンプトン、「決定的認証暗号化、鍵ラップ問題の証明可能安全性、セキュリティの治療」は、暗号理論の進歩 - EUROCRYPT '06サンクトペテルブルク、ロシア、2006。
[GCM] McGrew, D. and J. Viega, "The Galois/Counter Mode of Operation (GCM)".
[GCM]マグリュー、D.およびJ. Viega、 "操作のガロア/カウンタ・モード（GCM）"。
[JUTLA] Jutla, C., "Encryption Modes With Almost Free Message Integrity", Proceedings of the International Conference on the Theory and Application of Cryptographic Techniques: Advances in Cryptography.
[JUTLA] Jutla、C.、暗号技術の理論と応用に関する国際会議の議事録「ほぼ無料メッセージ整合性と暗号化モード」：暗号の進歩。
[OCB] Krovetz, T. and P. Rogaway, "The OCB Authenticated Encryption Algorithm", Work in Progress, March 2005.
[OCB] Krovetz、T.およびP. Rogaway、 "OCB認証暗号化アルゴリズム"、進歩、2005年3月に作業。
[RADKEY] Zorn, G., Zhang, T., Walker, J., and J. Salowey, "RADIUS Attributes for the Delivery of Keying Material", Work in Progress, April 2007.
[RADKEY]ソーン、G.、張、T.、ウォーカー、J.、およびJ. Saloweyは、進捗状況、2007年4月に、作業 "RADIUSは、鍵材料を送達するための属性"。
[RANDORCL] Bellare, M. and P. Rogaway, "Random Oracles are Practical: A Paradigm for Designing Efficient Protocols", Proceeding of the First ACM Conference on Computer and Communications Security, November 1993.
[RANDORCL]ベラー、M.とP. Rogawayは、「ランダムオラクルは、実用的である：効率的なプロトコルを設計するためのパラダイム」、コンピュータおよび通信セキュリティ、1993年11月に第一ACM会議の議事録。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104] Krawczyk、H.、ベラー、M.、およびR.カネッティ、 "HMAC：メッセージ認証のための鍵付きハッシュ化"、RFC 2104、1997年2月。
[RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC 2548, March 1999.
[RFC2548]ソーン、G.、 "マイクロソフトのベンダー固有のRADIUSアトリビュート"、RFC 2548、1999年3月。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865] Rigney、C.、ウィレンス、S.、ルーベン、A.、およびW.シンプソン、RFC 2865、2000年6月 "ユーザーサービス（RADIUS）でリモート認証ダイヤル"。
[RFC3217] Housley, R., "Triple-DES and RC2 Key Wrapping", RFC 3217, December 2001.
[RFC3217] Housley氏、R.、 "トリプルDESとRC2キーラッピング"、RFC 3217、2001年12月。
[RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard (AES) Key Wrap Algorithm", RFC 3394, September 2002.
[RFC3394] Schaad、J.とR. Housley氏、 "高度暗号化標準（AES）キーラップアルゴリズム"、RFC 3394、2002年9月。
[SP800-38D] Dworkin, M., "Recommendations for Block Cipher Modes of Operation: Galois Counter Mode (GCM) and GMAC", NIST Special Pulication 800-38D, June 2007.
[SP800-38D] Dworkin、M.、 "操作のブロック暗号モードへの提言：ガロアカウンタモード（GCM）とGMAC"、NIST特別Pulication 800-38D、2007年6月。
[VIRT] Garfinkel, T. and M. Rosenblum, "When Virtual is Harder than Real: Security Challenges in Virtual Machine Based Computing Environments" In 10th Workshop on Hot Topics in Operating Systems, May 2005.
[VIRT] Garfinkel、T.およびM.ローゼンブラム、「仮想が実際よりも硬い：セキュリティの課題仮想マシンベースのコンピューティング環境では、」第10回ワークショップではオペレーティングシステム、2005年5月のホットな話題に。
[WLAN] "Draft Standard for IEEE802.11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specification", 2007.
[WLAN] "IEEE802.11のための標準案：無線LAN媒体アクセス制御（MAC）および物理層（PHY）仕様"、2007年。
[X9F1] Dworkin, M., "Wrapping of Keys and Associated Data", Request for review of key wrap algorithms. Cryptology ePrint report 2004/340, 2004. Contents are excerpts from a draft standard of the Accredited Standards Committee, X9, entitled ANS X9.102.
[X9F1] Dworkin、M.、「キーと関連するデータのラッピング」、キーラップアルゴリズムの見直しを要求します。暗号学のePrintレポート340分の2004、2004内容は、ANSのX9.102題し認定基準委員会のドラフト規格からの抜粋、X9、です。
Appendix A. Test Vectors
付録A.テストベクトル
The following test vectors are for the mode defined in Section 6.1.
次のテストベクトルは、セクション6.1で定義されたモードのためのものです。
A.1. Deterministic Authenticated Encryption Example
A.1。決定論的な認証暗号の例
Input:
-----
Key:
fffefdfc fbfaf9f8 f7f6f5f4 f3f2f1f0
f0f1f2f3 f4f5f6f7 f8f9fafb fcfdfeff
AD: 10111213 14151617 18191a1b 1c1d1e1f 20212223 24252627
AD：10111213 14151617 18191a1b 1c1d1e1f 20212223 24252627
Plaintext: 11223344 55667788 99aabbcc ddee
平文：11223344 55667788 99aabbcc ddee
S2V-CMAC-AES
------------
CMAC(zero):
0e04dfaf c1efbf04 01405828 59bf073a
double(): 1c09bf5f 83df7e08 0280b050 b37e0e74
ダブル（）：1c09bf5f 83df7e08 0280b050 b37e0e74
CMAC(ad): f1f922b7 f5193ce6 4ff80cb4 7d93f23b
CMAC（広告）：f1f922b7 f5193ce6 4ff80cb4 7d93f23b
xor: edf09de8 76c642ee 4d78bce4 ceedfc4f
コーラス：edf09de8 76c642ee 4d78bce4 ceedfc4f
double(): dbe13bd0 ed8c85dc 9af179c9 9ddbf819
ダブル（）：dbe13bd0 ed8c85dc 9af179c9 9ddbf819
pad: 11223344 55667788 99aabbcc ddee8000
パス：11223344 55667788 99aabbcc ddee8000
xor: cac30894 b8eaf254 035bc205 40357819
コーラス：cac30894 b8eaf254 035bc205 40357819
CMAC(final): 85632d07 c6e8f37f 950acd32 0a2ecc93
CMAC（最終）：85632d07 c6e8f37f 950acd32 0a2ecc93
CTR-AES
-------
CTR:
85632d07 c6e8f37f 150acd32 0a2ecc93
E(K,CTR): 51e218d2 c5a2ab8c 4345c4a6 23b2f08f
E（K、CTR）：51e218d2 c5a2ab8c 4345c4a6 23b2f08f
ciphertext: 40c02b96 90c4dc04 daef7f6a fe5c
暗号文：40c02b96 90c4dc04 daef7f6a fe5c
output
------
IV || C:
85632d07 c6e8f37f 950acd32 0a2ecc93
40c02b96 90c4dc04 daef7f6a fe5c
A.2. Nonce-Based Authenticated Encryption Example
A.2。ノンスベースの認証暗号の例
Input:
-----
Key:
7f7e7d7c 7b7a7978 77767574 73727170
40414243 44454647 48494a4b 4c4d4e4f
AD1: 00112233 44556677 8899aabb ccddeeff deaddada deaddada ffeeddcc bbaa9988 77665544 33221100
AD1：8899aabb ccddeeff 00112233 44556677 77665544 33221100 deaddada deaddada ffeeddcc bbaa9988
AD2: 10203040 50607080 90a0
AD2：10203040 50607080 90a0
Nonce: 09f91102 9d74e35b d84156c5 635688c0
使節：09f91102 9d74e35b d84156c5 635688c0
Plaintext: 74686973 20697320 736f6d65 20706c61 696e7465 78742074 6f20656e 63727970 74207573 696e6720 5349562d 414553
平文：74686973 20697320 736f6d65 20706c61 696e7465 78742074 6f20656e 63727970 74207573 696e6720 5349562d 414553
S2V-CMAC-AES
------------
CMAC(zero):
c8b43b59 74960e7c e6a5dd85 231e591a
double(): 916876b2 e92c1cf9 cd4bbb0a 463cb2b3
ダブル（）：916876b2 e92c1cf9 cd4bbb0a 463cb2b3
CMAC(ad1) 3c9b689a b41102e4 80954714 1dd0d15a
80954714 1dd0d15a b41102e4 CMAC（AD1）3c9b689a
xor: adf31e28 5d3d1e1d 4ddefc1e 5bec63e9
コーラス：adf31e28 5d3d1e1d 4ddefc1e 5bec63e9
double(): 5be63c50 ba7a3c3a 9bbdf83c b7d8c755
ダブル（）：5be63c50 ba7a3c3a 9bbdf83c b7d8c755
CMAC(ad2) d98c9b0b e42cb2d7 aa98478e d11eda1b
CMAC（AD2）d98c9b0b e42cb2d7 aa98478e d11eda1b
xor: 826aa75b 5e568eed 3125bfb2 66c61d4e
コーラス：826aa75b 5e568eed 3125bfb2 66c61d4e
double(): 04d54eb6 bcad1dda 624b7f64 cd8c3a1b
（）ダブル：04d54eb6 bcad1dda 624b7f64 cd8c3a1b
CMAC(nonce) 128c62a1 ce3747a8 372c1c05 a538b96d
CMAC（ナンス）128c62a1 ce3747a8 372c1c05 a538b96d
xor: 16592c17 729a5a72 55676361 68b48376
ブレイク：16592c17 729a5a72 55676361 68b48376
xorend: 74686973 20697320 736f6d65 20706c61 696e7465 78742074 6f20656e 63727966 2d0c6201 f3341575 342a3745 f5c625
Ksrnd：74686973 20697320 736f6d65 20706c61 696e7465 78742074 6f20656e 63727966 2d0c6201 f3341575 342a3745 f5c625
CMAC(final) 7bdb6e3b 432667eb 06f4d14b ff2fbd0f
CMAC（最終）7bdb6e3b 432667eb 06f4d14b ff2fbd0f
CTR-AES
-------
CTR:
7bdb6e3b 432667eb 06f4d14b 7f2fbd0f
E(K,CTR): bff8665c fdd73363 550f7400 e8f9d376
E（K、CTR）：bff8665c fdd73363 550f7400 e8f9d376
CTR+1: 7bdb6e3b 432667eb 06f4d14b 7f2fbd10
CTR + 1：7bdb6e3b 432667eb 06f4d14b 7f2fbd10
E(K,CTR+1): b2c9088e 713b8617 d8839226 d9f88159
E（K、CTR + 1）：b2c9088e 713b8617 d8839226 d9f88159
CTR+2 7bdb6e3b 432667eb 06f4d14b 7f2fbd11
CTR + 2 7bdb6e3b 432667eb 06f4d14b 7f2fbd11
E(K,CTR+2): 9e44d827 234949bc 1b12348e bc195ec7
E（K、CTR + 2）：9e44d827 234949bc 1b12348e bc195ec7
ciphertext: cb900f2f ddbe4043 26601965 c889bf17 dba77ceb 094fa663 b7a3f748 ba8af829 ea64ad54 4a272e9c 485b62a3 fd5c0d
暗号文：cb900f2f ddbe4043 26601965 c889bf17 dba77ceb 094fa663 b7a3f748 ba8af829 ea64ad54 4a272e9c 485b62a3 fd5c0d
output
------
IV || C:
7bdb6e3b 432667eb 06f4d14b ff2fbd0f
cb900f2f ddbe4043 26601965 c889bf17
dba77ceb 094fa663 b7a3f748 ba8af829
ea64ad54 4a272e9c 485b62a3 fd5c0d
Author's Address
著者のアドレス
Dan Harkins Aruba Networks
ダンハーキンズアルバネットワークス
EMail: dharkins@arubanetworks.com
メールアドレス：dharkins@arubanetworks.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（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.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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は、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
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リポジトリから。
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に情報を記述してください。