[要約] RFC 5297は、AESを使用したSIV認証暗号化に関する標準仕様です。その目的は、セキュリティとプライバシーを向上させるために、効率的で安全な暗号化手法を提供することです。
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)
合成初期化ベクトル（SIV）高度な暗号化標準（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は、決定論的な認証された暗号化の目標または非CEベースの誤用耐性認証暗号化の目標のいずれかを達成します。
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]）。これらは、非CEで使用される場合に従来の認証された暗号化（「1回使用される数」）で使用され、通常は「関連データ」または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.
このメモでは、非CEMベースの認証された暗号化と、決定論的で非CEのないキーラッピングの両方を提供する新しいブロック暗号モードSIVについて説明しています。S2Vと呼ばれる擬似ランダム関数（PRF）構造とCTRと呼ばれる暗号化/復号化構造が含まれています。SIVは、[Dae]でPhillip RogawayとThomas Shrimptonによって指定されました。S2VとCTRの両方でここで使用される基礎となるブロック暗号は、128ビット、192ビット、または256ビットの主要な長さのAESです。S2Vは、Cipherベースのメッセージ認証コード（[CMAC]）モードでAESを使用します。CTRは、カウンター（[モード]）モードの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ポイントツーポイント暗号化（MPPE）[RFC2548]を使用して、サーバーからクライアントに送信する前にキーを暗号化します。暗号化されたキーの整合性チェックは提供されません。[radkey]は、[RFC3394]の使用を指定してRadius要求にキーをラップしますが、関連するデータを渡すことができないため、リクエスト全体の認証を提供するには、ハッシュされたメッセージ認証コード（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.
上記のNonCeベースの認証された暗号化スキームは、NonCeの再利用および/または誤用の影響を受けやすいです。特定のスキームに応じて、ノンセに微妙で重要な要件があります（[SP800-38D]を参照）。[GCM]は、NONCEが明確であることが保証されているが、そうでなければ「セキュリティなし」を提供する場合、「優れたセキュリティ」を提供すると述べています。[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]).
たとえば、多くのアプリケーションは、アプリケーションプログラムインターフェイスを介して暗号化ライブラリへの暗号化関数へのアクセスを取得します。これらのライブラリは通常、ステートフルではなく、暗号モードで必要なノンセ、初期化ベクトル、またはカウンターは、アプリケーションによって暗号化ライブラリに渡されます。暗号化エンジンの制御の外側にセキュリティクリティカルなデータを構築することは、必要な暗号衛生を提供しない可能性のあるアプリケーションライターに面倒な負担をかけます。おそらく、彼の乱数ジェネレーターはあまり良くないか、アプリケーション障害がカウンターをリセットする可能性があります。暗号モードの脆弱性は、その不注意な誤用をもたらす可能性があります。また、自分の環境が（故意に、または知らないうちに）仮想マシンである場合、仮想状態マシンをロールバックして、認証された暗号化スキームのセキュリティをgutりさせることができる場合があります（[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がランダムである場合、繰り返さないという要件は、1つのブロックから1つのキーで安全に保護できるデータの量を制限します。より賢明なことに、ランダムなノンセは「ほとんど常に」非反復的であるために必要ですが、安全に保護できるデータの量を大幅に制限します。
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は、NonCeの再利用と誤用に対するレベルの耐性を提供します。NonCEが再利用されない場合、認証された暗号化モードのNonCeベースのセキュリティの通常の概念が達成されます。ただし、NonCEが再利用されている場合、信頼性が保持され、機密性が攻撃者が同じノンセとキーで保護されていると判断できる範囲でのみ妥協されます。セキュリティ上の考慮事項（セクション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]など[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が通常定義される方法のために、単一の文字列にマッピングされます。つまり、キーとデータの2つの入力です。追加データを含める必要があるため、このような粗マッピングは非効率的です - 可変長入力の長さは個別にエンコードする必要があります - そして、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（ "String to Vector"）PRF構造は、入力のベクトルを受け入れ、追加の長さのエンコーディングを必要としない、入力のより自然なマッピングを提供し、入力とそのエンコードされた長さを1つの文字列に登場するメモリと処理のオーバーヘッドを削除します。PRFへの一定の入力は、1回だけ計算する必要があります。
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つのパスの要件のためにできるのと同じ高スループットレートで実行することはできませんが、パフォーマンスが制限要因ではない状況で、例えば、コントロールプレーンアプリケーション - 特に非CEの再利用に対する抵抗を考慮する場合、堅牢な代替品を提供できます。
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.
PAD（x）は、1つのビット1の連結により、必要な数の0ビットの連結により128ビットに出て、文字列X、LEN（X）<128のパディングを示します。
leftmost(A,n) the n most significant bits of A.
左端（a、n）Aの最も重要なビットn
rightmost(A,n) the n least significant bits of A.
A.
A || B means concatenation of string A with string B.
A ||Bは、文字列Bとの文字列Aの連結を意味します。
A xor B is the exclusive OR operation on two equal length strings, A and B.
XOR Bは、2つの等しい長さの文字列、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).
a xorend b len（a）> = len（b）は、文字列bを文字列aの端にxすることを意味します。つまり、左端（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.
BITEAND Bは、2つの等しい長さの文字列、AとBの論理的および操作です。
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を使用して表される有限フィールドのsと0 ... 010の乗算です。
a^b indicates a string that is "b" bits, each having the value "a".
a^bは、「b」ビットである文字列を示し、それぞれに値「a」があります。
<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.
<one> 1つのビットと連結された127ビットの文字列、つまり0^127 ||を示します。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は、256-、384-、または512ビットキー（2つの等サイズのキーに分割されます。1つはS2V用、もう1つはCTR用です）、可変長さのプレーンテキスト、および複数の可変長文字列のいずれかを取得します。関連するデータを表す。その出力は、暗号化されたプレーンテキストと連結された合成初期化ベクトルを含む暗号文です。
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ビットの入力文字列の2倍の操作は、入力の左シフトを使用して実行され、その後の条件付きXOR操作が順番に実行されます。
00000000 00000000 00000000 00000087
000000000000000000000000000087
The condition under which the xor operation is performed is when the bit being shifted off is one.
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.
S2V操作は、入力ベクトル内の個々の文字列を操作する擬似ランダム関数CMACの出力の倍増とXaringで構成されています：s1、s2、...、sn。128ビットのゼロでCMACを実行することでブートストラップされます。ベクトル内の最終文字列の長さが128ビット以上の場合、ダブル/XORチェーンの出力は最終入力文字列の端にXAREDされます。その結果は、出力Vを生成するための最終CMAC操作への入力です。最終文字列の長さが128ビット未満の場合、ダブル/XORチェーンの出力はもう一度2倍になり、最終文字列を使用してパッド付きでXAREDがXAREされます。パディング機能パッド（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、and len（sn）> = 128：n入力のベクトルにキーkを備えたS2V：
+----+ +----+ +------+ +----+
| 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、and len（sn）<128：n入力のベクトルにキー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)
}
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、長さ128、192、または256ビットのキーk、長さ128ビットのカウンターX、および合成初期化ベクターVの連結を表す出力ZとのカウンターXを入力として必要とします。ciphertext Cは、プレーンテキストと同じ長さです。
The ciphertext is produced by xoring the plaintext with the first len(P) bits of the following string:
暗号文は、次の文字列の最初のLEN（P）ビットでプレーンテキストをXaringすることによって生成されます。
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番目のビット）がクリアされます。これにより、ネイティブ32ビット（64ビット）追加をサポートする実装が可能になり、128ビットの増分から区別できない方法で、カウンターモジュロ2^32（2^64）を増分することができます。それぞれの事前にクリアされたビットからキャリーが発生することを安全に回避する上限によって制限されます。より正式には、32ビットの追加の場合、カウンターは次のように増加します。
SALT=leftmost(X,96)
塩=左端（x、96）
n=rightmost(X,32)
n =右端（x、32）
X+i = SALT || (n + i mod 2^32).
x i = salt ||（n i mod 2^32）。
For 64-bit addition, the counter is incremented as:
64ビットの追加の場合、カウンターは次のように増加します。
SALT=leftmost(X,64)
塩=左端（x、64）
n=rightmost(X,64)
n =右端（x、64）
X+i = SALT || (n + i mod 2^64).
x i = salt ||（n i mod 2^64）。
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.
カウンターで32ビットまたは64ビットの追加を実行すると、SIV-AESによって安全に保護できるプレーンテキストの量がそれぞれ2^39-128ビットまたは2^71-128ビットを制限します。
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-Encryptは、長さ256、384、または512ビットのキーkを入力し、任意の長さのプレーンテキスト、およびベクトル内のコンポーネントの数が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からADN、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
for i = 0 to m-1 do
Xi = AES(K2, Q+i)
done
X = leftmost(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が使用するキー長はLEN（K）/2であり、それぞれ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番目です）は、最適化のためにCTRが使用する直前にゼロになります。セクション5を参照してください。
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-DECRYPTは、長さ256、384、または512ビットのキーKを入力して、ciphertext Cと連結された合成初期化ベクターvを表し、関連データADのベクトル[]を表します。ベクトルは126以下です（セクション7を参照）。元のプレーンテキストまたは特別なシンボル障害のいずれかを生成します。
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の出力は、S2Vに渡される文字列のベクトルを表し、CTR出力はベクトルの最後の文字列です。S2Vの出力は、元の暗号文に伴う合成IVと比較されます。それらが一致する場合、CTRからの出力は、復号化され、認証された平文として返されます。それ以外の場合、特別なシンボル障害が返されます。
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-DeCryptは次のように説明できます。
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)
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)
if T = V then return P else return FAIL fi }
t = vの場合、return pを返します。
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が使用するキー長はLEN（K）/2であり、それぞれ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番目です）は、最適化のためにCTRモードで使用される直前にゼロになります。セクション5を参照してください。
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は、関連データのコンポーネントがNonCEの場合、NonCeベースの認証された暗号化を実行します。相互運用性のために、最終コンポーネント、つまり、S2Vへのベクトル入力のプレーンテキストの直前の文字列は、NonCEに使用されます。他の関連データはオプションです。関連するデータの残りの部分を入力する方法を指定するのは、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ビットのエントロピーを持つプールから収穫される必要があります。例えば、タイムスタンプ、またはカウンターなど、非ランダムソースも使用できます。非CEの定義は再利用を妨げますが、SIVは非CEの再利用に耐性があります。NonCe Reuseのセキュリティへの影響に関する議論については、セクション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にNONCEコンポーネントを追加する必要はありません。
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をサポートできない、または希望しない実装は、CTRが使用する前にカウンターの31番目と63番目のビット（右端が0番目のビット）がクリアされるという事実を利用できます。これにより、32ビットまたは64ビットの追加をネイティブにサポートして、カウンターを自然に増やすことができます。もちろん、この場合、SIVによって安全に保護できるプレーンテキストの量は、相応の量だけ削減されます - 追加モジュロ2^32はプレーンテキストを（2^39-128）ビットに制限します。to（2^71-128）ビット。
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出力は、一度計算してキャッシュできます。これを2倍にし、実行中の合計でXaurすることができ、出力を生成します。または、バリアントコンポーネントまでの複数のコンポーネントの2倍およびXored出力を表す中間値は、一度計算してキャッシュできます。
[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）を使用して非CEベースの認証された暗号化を提供する暗号モードへの均一なインターフェイスを定義します。これは、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].
インターネットに割り当てられた数字当局（IANA）は、AES-SIV-CMAC-256（15）、AES-SIV-CMAC-384（16）、およびAES-SIV-CMAC-512（17）に基づくAEADレジストリから3つのエントリを割り当てました。次の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が自然に対処するために提供する利点を制限します。したがって、[RFC5116]で定義されているインターフェイスを介してSIVにアクセスする必要がある場合、SIVを呼び出す前に複数のAD入力を単一の文字列（セクション1.1を参照）にマーシャリングする必要があります。この要件は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アルゴリズムが受け入れることができるプレーンテキストの量、関連データの量、および非CEのサイズを含むために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はカウンターモードでAEを使用し、カウンターが繰り返されることを許可された場合、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]は、同じキーを持つCMACに2^48を超えないように行うことを推奨しています。ただし、これはCMACに渡すことができるデータの量の制限ではありません。CMACの単一の呼び出しに対して行うことができるデータの量には実用的な制限はありません。また、同様に、SIVに渡すことができる関連データまたは非CE材料の量には実用的な制限はありません。
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への2^64以下の異なる呼び出しが行われないことを暗示しています。ただし、[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:
AES-SIV-CMAC-256 AEADアルゴリズムは、セクション2.6および2.7で指定されているように機能します。[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.
NonCeの再利用および/または誤用のセキュリティへの影響については、セクション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:
AES-SIV-CMAC-384 AEADアルゴリズムは、セクション2.6および2.7で指定されているとおりに機能します。[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.
NonCeの再利用および/または誤用のセキュリティへの影響については、セクション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:
AES-SIV-CMAC-512 AEADアルゴリズムは、セクション2.6および2.7で指定されているとおりに機能します。[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.
NonCeの再利用および/または誤用のセキュリティへの影響については、セクション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-Encryptの出力がランダムな一連のビットと区別できないという意味で、機密性を提供します。攻撃者は、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-Encryptの出力はランダムビットと区別できません。同様に、このキーが攻撃者が利用できるようになった場合でも、SIV-DeCryptへの入力が失敗以外のものを返す一連のビットを構築することができません。
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のNonCEベースの認証された暗号化モードで使用されているNonCEが、他の従来のNonCeベースの認証された暗号化スキームでNonCEまたはカウンターを提供するケアで処理される場合 - つまり、同じキーで使用されないことを保証します2つの異なる呼び出しについて、SIVは上記のセキュリティのレベルを達成します。ただし、非CEが再利用されている場合、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のコンポーネントとしてプレーンテキストが含まれているため、SIVに安全に渡すことができる関連データのコンポーネントの数を126に制限します。
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に関する多くの質問に辛抱強く答えてくれたPhil Rogawayと、このペーパーの以前のバージョンの有用な批評に感謝します。また、この論文を改善するための多くの役立つコメントと提案をしてくれたDavid McGrewにも感謝します。この論文をレビューし、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 Special 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.
[モード] Dworkin、M。、「操作のブロックモードの推奨：方法と技術の推奨」、NIST Special Pulication 800-38a、2001 Edition。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, January 2008.
[RFC5116] McGrew、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.
[Appcry] Menezes、A.、van Oorshot、P。、およびS. Vanstone、「Handbook of Applied Cryprography」、CRC Pressシリーズ別々の数学とその応用に関する1996年。
[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セキュリティプロトコルの問題領域」、第6回USENIX UNIXセキュリティシンポジウムの議事録、1996年7月22〜25日。
[RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with CBC-MAC (CCM)", RFC 3610, September 2003.
[RFC3610] Whiting、D.、Housley、R。、およびN. Ferguson、「CONTER COUNTER WITH 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。and T. Shrimpton、「決定論的な認証された暗号化、キーワラップ問題の証明可能なセキュリティ治療」、暗号化の進歩-Eurocrypt '06 St. Petersburg、Russia、2006。
[GCM] McGrew, D. and J. Viega, "The Galois/Counter Mode of Operation (GCM)".
[GCM] McGrew、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] Zorn、G.、Zhang、T.、Walker、J。、およびJ. Salowey、「キーイング素材の配信のための半径属性」、2007年4月、進行中の作業。
[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] Bellare、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.、Bellare、M。、およびR. CaNetti、「HMAC：メッセージ認証のためのキー付きハッシング」、RFC 2104、1997年2月。
[RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC 2548, March 1999.
[RFC2548] Zorn、G。、「Microsoft Vendor固有の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.、Willens、S.、Rubens、A。、およびW. Simpson、「リモート認証ダイヤルインユーザーサービス（RADIUS）」、RFC 2865、2000年6月。
[RFC3217] Housley, R., "Triple-DES and RC2 Key Wrapping", RFC 3217, December 2001.
[RFC3217] Housley、R。、「Triple-Des and RC2 Key Lapping」、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、「Advanced Encryption Standard（AES）Key Wrap Algorithm」、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。、「操作のブロックモードの推奨事項：Galois Counter Mode（GCM）およびGMAC」、Nist Special 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. Rosenblum、「仮想よりも難しい場合：仮想マシンベースのコンピューティング環境におけるセキュリティの課題」、2005年5月のオペレーティングシステムのホットトピックに関する第10回ワークショップ。
[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。、「キーと関連するデータのラッピング」、キーラップアルゴリズムのレビューのリクエスト。Cryptology Eprint Report 2004/340、2004。内容は、ANS X9.102と題された認定標準委員会X9の草案からの抜粋です。
The following test vectors are for the mode defined in Section 6.1.
次のテストベクトルは、セクション6.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
double（）：1C09BF5F 83DF7E08 0280B050 B37E0E74
CMAC(ad): f1f922b7 f5193ce6 4ff80cb4 7d93f23b
CMAC（AD）：F1F922B7 F5193CE6 4FF80CB4 7D93F23B
xor: edf09de8 76c642ee 4d78bce4 ceedfc4f
XOR：EDF09DE8 76C642EE 4D78BCE4 CEEDFC4F
double(): dbe13bd0 ed8c85dc 9af179c9 9ddbf819
double（）：DBE13BD0 ED8C85DC 9AF179C9 9DDBF819
pad: 11223344 55667788 99aabbcc ddee8000
PAD：11223344 55667788 99AABBCC DDEE8000
xor: cac30894 b8eaf254 035bc205 40357819
XOR：CAC30894 B8 FOAF254 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
Input:
-----
Key:
7f7e7d7c 7b7a7978 77767574 73727170
40414243 44454647 48494a4b 4c4d4e4f
AD1: 00112233 44556677 8899aabb ccddeeff deaddada deaddada ffeeddcc bbaa9988 77665544 33221100
AD1：00112233 44556677 8899AABB CCDDEEFF DEADDADA DEADDADA FFEEDDCC BBAA9988 77665544 33221100
AD2: 10203040 50607080 90a0
AD2：10203040 50607080 90A0
Nonce: 09f91102 9d74e35b d84156c5 635688c0
NONCE：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 4145555555555555555555555555555555555557573
S2V-CMAC-AES
------------
CMAC(zero):
c8b43b59 74960e7c e6a5dd85 231e591a
double(): 916876b2 e92c1cf9 cd4bbb0a 463cb2b3
double（）：916876B2 E92C1CF9 CD4BBB0A 463CB2B3
CMAC(ad1) 3c9b689a b41102e4 80954714 1dd0d15a
CMAC（AD1）3C9B689A B41102E4 80954714 1DD0D15A
xor: adf31e28 5d3d1e1d 4ddefc1e 5bec63e9
XOR：ADF31E28 5D3D1E1D 4DDEFC1E 5BEC63E9
double(): 5be63c50 ba7a3c3a 9bbdf83c b7d8c755
double（）：5BE63C50 BA7A3C3A 9BBDF83C B7D8C755
CMAC(ad2) d98c9b0b e42cb2d7 aa98478e d11eda1b
CMAC（AD2）D98C9B0B E42CB2D7 AA98478E D11EDA1B
xor: 826aa75b 5e568eed 3125bfb2 66c61d4e
XOR：826AA75B 5E568EED 3125BFB2 66C61D4E
double(): 04d54eb6 bcad1dda 624b7f64 cd8c3a1b
double（）：04D54EB6 BCAD1DDA 624B7F64 CD8C3A1B
CMAC(nonce) 128c62a1 ce3747a8 372c1c05 a538b96d
CMAC（NONCE）128C62A1 CE3747A8 372C1C05 A538B96D
xor: 16592c17 729a5a72 55676361 68b48376
XOR：16592C17 729A5A72 55676361 68B48376
xorend: 74686973 20697320 736f6d65 20706c61 696e7465 78742074 6f20656e 63727966 2d0c6201 f3341575 342a3745 f5c625
Xorend：74686973 20697320 736F6D65 20706C61 696E7465 78742074 6F20656E 63727966 2D0C6201 F3341575 342A3745 F5C62555555555555555555555555
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
CIPHERTEXT：CB900F2FF DDBE4043 26601965 C889BF17 DBA77CEB 094FA6663 B7A3F748 BA8AF829 EA64AD54 4A272E9C 485B62A3 FD5C0D5C0D
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
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、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は、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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への情報をお問い合わせください。