[要約] 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）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]でPhillip RogawayとThomas Shrimptonによって指定されました。S2VとCTRの両方でここで使用される基礎となるブロック暗号は、128ビット、192ビット、または256ビットのキー長を持つAESです。S2Vは、CMAC（Cipher-based Message Authentication Code）モードで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ポイントツーポイント暗号化（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]).
たとえば、多くのアプリケーションは、アプリケーションプログラムインターフェイスを介して暗号化ライブラリへの暗号化関数へのアクセスを取得します。これらのライブラリは通常、ステートフルではなく、暗号モードで必要なナンス、初期化ベクトル、またはカウンターは、アプリケーションによって暗号化ライブラリに渡されます。暗号化エンジンの制御外にセキュリティ上重要なデータの構築を置くことは、必要な暗号学的衛生管理を提供しない可能性のあるアプリケーション開発者に重い負担をかけます。おそらく、その乱数生成器はあまり良くないか、アプリケーション障害がカウンターをリセットする可能性があります。暗号モードの脆さは、その不注意な誤用をもたらす可能性があります。また、自分の環境が（故意に、または知らないうちに）仮想マシンである場合、仮想状態マシンをロールバックして、ナンスの再利用を引き起こし、それによって認証付き暗号スキームのセキュリティを台無しにする可能性があります（[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.
ナンスがランダムである場合、繰り返さないという要件は、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は、ナンスの再利用と誤用に対するある程度の耐性を提供します。ナンスが再利用されない場合、認証付き暗号モードのナンスベースのセキュリティの通常の概念が達成されます。ただし、ナンスが再利用されている場合、認証性は保持され、同じ平文（および同じ関連データ）が同じナンスとキーで保護されたことを攻撃者が特定できる範囲に留まり、機密性が損なわれます。セキュリティ上の考慮事項（セクション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は、キーと単一の文字列を渡すことにより、鍵導出関数（KDF）（例：[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は、データに対して2パスが必要なため、他の認証付き暗号スキーム（例：[GCM]または[OCB]）のような高いスループットレートで実行することはできませんが、パフォーマンスが制限要因ではない状況で、例えば、コントロールプレーンアプリケーション - 特にナンスの再利用に対する耐性を考慮する場合、堅牢な代替品を提供できます。
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.
本明細書で説明する暗号モードは、認証付き暗号、キーラッピング、鍵導出を行い、汎用メッセージ認証アルゴリズムとして機能することができます。したがって、各機能に個別のツールを用意するのではなく、単一のツールでこれらすべての機能を実装することができます。これは、メモリおよび/またはプロセッサが制約されており、これらの機能を達成するために複数の暗号化プリミティブを実装する余裕がないデバイスにとって非常に魅力的です。
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) は、文字列 X (len(X) < 128) のパディングを示し、単一のビット 1 とそれに続く必要な数の 0 ビットを連結して 128 ビットにします。
leftmost(A,n) the n most significant bits of A.
leftmost(A,n) A の最上位 n ビット。
rightmost(A,n) the n least significant bits of A.
rightmost(A,n) A の最下位 n ビット。
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.
A xor B は、2つの等しい長さの文字列、A と B の排他的論理和 (XOR) 操作です。
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 の末尾に XOR することを意味します。つまり、leftmost(A, len(A)-len(B)) || (rightmost(A, len(B)) xor B) です。
A bitand B is the logical AND operation on two equal length strings, A and B.
A bitand B は、2つの等しい長さの文字列、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 を使用して表される有限体における S と 0...010 の乗算です。ダブリング（セクション2.3）を参照してください。
a^b indicates a string that is "b" bits, each having the value "a".
a^bは、それぞれの値が「a」である「b」ビットの文字列を示します。
<zero> indicates a string that is 128 zero bits.
<zero> 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は、256、384、または512ビットのキー（S2V用とCTR用の2つの等しいサイズのキーに分割されます）、可変長の平文、および関連データを表す複数の可変長文字列を入力とします。その出力は、合成初期化ベクトルと、暗号化された平文を連結した暗号文です。
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
00000000000000000000000000000087
The condition under which the xor operation is performed is when the bit being shifted off is one.
XOR操作が実行される条件は、シフトアウトされるビットが1である場合です。
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操作は、入力ベクトル内の個々の文字列（S1, S2, ..., Sn）に対して動作する擬似ランダム関数CMACの出力のダブリングとXORで構成されています。これは、128ビットのゼロの文字列でCMACを実行することでブートストラップされます。ベクトル内の最終文字列の長さが128ビット以上の場合、ダブル/XORチェーンの出力は最終入力文字列の末尾にXORされます。その結果は、出力Vを生成するための最終CMAC操作への入力となります。最終文字列の長さが128ビット未満の場合、ダブル/XORチェーンの出力はもう一度ダブリングされ、パディング関数 pad(X) を使用してパディングされた最終文字列とXORされます。その結果は、出力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 のベクトルに対するキーKを用いたS2V（len(Sn) >= 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 のベクトルに対するキーKを用いたS2V（len(Sn) < 128）：
+----+ +----+ +------+ +---------+
| 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と暗号文C（平文と同じ長さ）の連結であるZを出力します。
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) || ...
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)
SALT=leftmost(X,96)
n=rightmost(X,32)
n=rightmost(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)
SALT=leftmost(X,64)
n=rightmost(X,64)
n=rightmost(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 = leftmost(K, len(K)/2) および K2 = rightmost(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
}
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、合成初期化ベクトルVと暗号文Cが連結されたZ、およびベクトル内のコンポーネント数が126以下である関連データAD[]のベクトルを入力とします（セクション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の出力は、S2Vに渡される文字列のベクトルを表し、CTR出力はベクトルの最後の文字列です。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-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
}
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.
相互運用性のために、最終コンポーネント、つまり、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.
ナンスがランダムである場合、少なくとも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を法とする加算をサポートできない、または希望しない実装は、CTRが使用する前にカウンターの31番目と63番目のビット（右端が0番目のビット）がクリアされるという事実を利用できます。これにより、32ビットまたは64ビットの加算をネイティブにサポートする実装が、カウンターを自然にインクリメントすることができます。もちろん、この場合、SIVによって安全に保護できる平文の量は、相応の量だけ削減されます - 2^32を法とする加算は平文を (2^39 - 128) ビットに制限し、2^64を法とする加算は平文を (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に渡されるデータに固定の文字列が含まれるためです。入力の可変コンポーネントの位置に応じて、異なる最適化が可能です。中間成分と不変成分のCMAC出力は、一度計算してキャッシュできます。これをダブリングし、累積和と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].
Internet Assigned Numbers Authority (IANA) は、次のAEADアルゴリズム定義に基づいて、AES-SIV-CMAC-256（15）、AES-SIV-CMAC-384（16）、およびAES-SIV-CMAC-512（17）のAEADレジストリから3つのエントリを割り当てました。[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入力を単一のコンポーネントに制限し、複数の異なるコンポーネントからなる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アルゴリズムの仕様に要求します。
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]は、同じキーでCMACを2^48回以上呼び出さないことを推奨しています。ただし、これは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への異なる呼び出しが2^64回を超えて行われないことを示唆しています。ただし、[CMAC]の例に従い、同じキーを使用したSIVの異なる呼び出し回数を2^48回にさらに制限することは賢明です。[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.
ナンスの再利用および/または誤用のセキュリティへの影響については、セクション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.
ナンスの再利用および/または誤用のセキュリティへの影響については、セクション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.
ナンスの再利用および/または誤用のセキュリティへの影響については、セクション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-Decryptに入力したときに FAIL 以外を返す一連のビットを構築できないという意味で認証性を提供します。認証付き暗号スキームの「オールインワン」セキュリティの概念を持つ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に入力したときに 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のナンスベースの認証付き暗号モードで使用されるナンスが、他の従来のナンスベースの認証付き暗号スキームにおけるナンスまたはカウンターと同様の注意をもって扱われる場合（つまり、同じキーで2つの異なる呼び出しに使用されないことが保証される場合）、SIVは上記のセキュリティレベルを達成します。ただし、ナンスが再利用されている場合、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 Publication 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 414553
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 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
ダン・ハーキンス 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への情報をお問い合わせください。