RFC5297 日本語訳
5297 Synthetic Initialization Vector (SIV) Authenticated EncryptionUsing the Advanced Encryption Standard (AES). D. Harkins. October 2008. (Format: TXT=50374 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group D. Harkins Request for Comments: 5297 Aruba Networks Category: Informational October 2008
ハーキンがコメントのために要求するワーキンググループD.をネットワークでつないでください: 5297 アルーバはカテゴリをネットワークでつなぎます: 情報の2008年10月
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(合成の初期設定Vector)、ブロック暗号運転モードを説明します。 SIVは認証されますが、コード化されないキー、平文、および複数の可変長の八重奏ストリングを取ります。 それは平文と合成の初期化ベクトルとして同じ長さを持っている暗号文を生産します。 それがどう使用されているかによって、SIVは決定論的な認証された暗号化の目標か一回だけベースと、耐誤用の認証された暗号化の目標のどちらかを達成します。
Hawkins Informational [Page 1] RFC 5297 SIV-AES October 2008
[1ページ]RFC5297SIV-AES2008年10月の情報のホーキンズ
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
1. 序論…3 1.1. バックグラウンド…3 1.2. 定義…4 1.3. 動機…4 1.3.1. 主要なラッピング…4 1.3.2. 一回だけの誤用/再利用への抵抗…4 1.3.3. キー派生…5 1.3.4. 丈夫さ対パフォーマンス…6 1.3.5. 暗号の基関数の保護…6 2. SIVの仕様…6 2.1. 記法…6 2.2. 概観…7 2.3. 倍増します…7 2.4. S2V…8 2.5. CTR…10 2.6. SIV、コード化します。10 2.7. SIV、解読します。12 3. SIVとの一回だけベースの認証された暗号化…14 4. SIVとの決定論的な認証された暗号化…15 5. 最適化…15 6. IANA問題…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. セキュリティ問題…18 8. 承認…19 9. 参照…19 9.1. 標準の参照…19 9.2. 有益な参照…19付録A.はベクトルをテストします… 22 A.1。 決定論的な認証された暗号化の例… 22 A.2。 一回だけベースの認証された暗号化の例… 23
Hawkins Informational [Page 2] RFC 5297 SIV-AES October 2008
[2ページ]RFC5297SIV-AES2008年10月の情報のホーキンズ
1. Introduction
1. 序論
1.1. Background
1.1. バックグラウンド
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について説明します。 CTRは、それがS2Vと呼ばれるPseudo無作為のFunction(PRF)工事と暗号化/復号化工事を含むと呼びました。 SIVは[DAE]でフィリップRogawayとトーマスShrimptonによって指定されました。 S2VとCTRの両方にここに使用される基本的なブロック暗号は128ビット、192ビット、または256ビットのキー長があるAESです。 S2VはCipherベースのメッセージ立証コード([CMAC])モードでAESを使用して、CTRはカウンタ([MODES])モードでAESを使用します。
Associated data is data input to an authenticated-encryption mode that will be authenticated but not encrypted. [RFC5116] says that associated data can include "addresses, ports, sequence numbers, protocol version numbers, and other fields that indicate how the plaintext or ciphertext should be handled, forwarded, or processed". These are multiple, distinct inputs and may not be contiguous. Other authenticated-encryption cipher modes allow only a single associated data input. Such a limitation may require implementation of a scatter/gather form of data marshalling to combine the multiple components of the associated data into a single input or may require a pre-processing step where the associated data inputs are concatenated together. SIV accepts multiple variable-length octet strings (hereinafter referred to as a "vector of strings") as associated data inputs. This obviates the need for data marshalling or pre-processing of associated data to package it into a single input.
関連データは認証されますが、コード化されない認証された暗号化モードへのデータの入力です。 [RFC5116]は、関連データが「平文か暗号文を扱うべきであるか、進めるべきであるか、またはどう処理するべきであるかを示すアドレス、ポート、一連番号、プロトコルバージョン番号、および他の分野」を含むことができると言います。 これらは、複数の、そして、異なった入力であり、隣接でないかもしれません。 他の認証された暗号化暗号モードはただ一つの関連データ入力だけを許します。 そのような制限は、関連データの複数の成分をただ一つの入力に結合するためにデータ整理の散布/ギャザー形式の実現を必要とするか、または関連データ入力が連結される前処理ステップを一緒に、必要とするかもしれません。 SIVは関連データ入力として複数の可変長の八重奏ストリング(以下に、「ストリングのベクトル」と呼ばれる)を認めます。 これは関連データのデータ整理か前処理がただ一つの入力にそれをパッケージする必要性を取り除きます。
By allowing associated data to consist of a vector of strings SIV also obviates the requirement to encode the length of component fields of the associated data when those fields have variable length.
また、関連データがストリングのベクトルから成るのを許容することによって、SIVはそれらの分野に可変長があるとき関連データのコンポーネント分野の長さをコード化するという要件を取り除きます。
Hawkins Informational [Page 3] RFC 5297 SIV-AES October 2008
[3ページ]RFC5297SIV-AES2008年10月の情報のホーキンズ
1.2. Definitions
1.2. 定義
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか?
1.3. Motivation
1.3. 動機
1.3.1. Key Wrapping
1.3.1. キーラッピング
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]は、サーバからクライアントまでのトランスミッションの前にキーをコード化するのに、マイクロソフトPointからポイントへのEncryption(MPPE)[RFC2548]を使用します。 それはコード化されたキーをチェックする保全を全く提供しません。 [RADKEY]はRADIUS要求でキーを包装するために[RFC3394]の使用を指定しますが、関連データを通過できないことのために、Hashedメッセージ立証コード(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.
前述の使用を含む[RFC3394]か[RFC3217]を使用するどんな仕様にも中に低下する交換としてSIVを使用できます。 関連データが指定されるのを許容するようにそれは、より汎用の解決策です。
1.3.2. Resistance to Nonce Misuse/Reuse
1.3.2. 一回だけの誤用/再利用への抵抗
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
例えば、多くのアプリケーションが暗号のライブラリへの適用業務プログラム・インタフェースを通して暗号の機能へのアクセスを得ます。 これらのライブラリは通常statefulではありません、そして、暗号モードによって必要とされたどんな一回だけ、初期化ベクトル、またはカウンタもアプリケーションで暗号のライブラリに通り過ぎられます。 暗号化エンジンのコントロールの外にセキュリティ批判的なデータの工事を置くと、煩わしい負担は必要な暗号の衛生を提供しないかもしれないアプリケーション作家にかけられます。 多分、恐らく、彼の乱数発生器がそれほど良くないか、またはアプリケーション欠点でカウンタをリセットします。 暗号モードのもろさは不注意な誤用をもたらすかもしれません。 また、人のものであるなら、環境はそうです。
Hawkins Informational [Page 4] RFC 5297 SIV-AES October 2008
[4ページ]RFC5297SIV-AES2008年10月の情報のホーキンズ
(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ブロックの単一のキーで安全に保護できるデータ量を制限するでしょう。 より分別よく、無作為の一回だけが「ほとんどいつも」非反復になるのに必要ですが、それは安全に保護できるデータ量を抜本的に制限するでしょう。
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)を見てください。
1.3.3. Key Derivation
1.3.3. 主要な派生
A PRF is frequently used as a key derivation function (e.g., [WLAN]) by passing it a key and a single string. Typically, this single string is the concatenation of a series of smaller strings -- for example, a label and some context to bind into the derived string.
PRFは、主要な派生機能(例えば、[WLAN])として主要なストリングとただ一つのストリングをそれに渡すことによって、頻繁に使用されます。 この一連は通常、一連のより小さいストリングの連結です--例えば、ラベルと誘導ストリングに縛る何らかの文脈。
These are usually multiple strings but are mapped to a single string because of the way PRFs are typically defined -- two inputs: a key and data. Such a crude mapping is inefficient because additional data must be included -- the length of variable-length inputs must be encoded separately -- and, depending on the PRF, memory allocation and copying may be needed. Also, if only one or two of the inputs changed when deriving a new key, it may still be necessary to process all of the other constants that preceded it every time the PRF is invoked.
これらは、通常複数のストリングですが、PRFsは通常定義されます--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(「ベクトルに結ぶ」)PRF工事は、入力のベクトルを受け入れて、追加長さのencodingsを必要としない入力の、より当然のマッピングを提供して、入力とそれらのコード化された長さを一連に整理するためにメモリと処理オーバヘッドを取り除きます。 PRFへの一定の入力は一度計算されるだけでよいです。
Hawkins Informational [Page 5] RFC 5297 SIV-AES October 2008
[5ページ]RFC5297SIV-AES2008年10月の情報のホーキンズ
1.3.4. Robustness versus Performance
1.3.4. 丈夫さ対パフォーマンス
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])で働くことができるのではなく、状況のために性能が限定因子でないところで働きます--例えば、飛行機アプリケーションを制御してください--特に一回だけの再利用への抵抗を考えるとき、それは強健な代替手段を提供できます。
1.3.5. Conservation of Cryptographic Primitives
1.3.5. 暗号の基関数の保護
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個のツールの代わりに可能です。 メモリ、そして/または、抑制されたプロセッサであり、これらの機能を達成するために複数の暗号の基関数を実行する余裕がない装置に、これは非常に魅力的です。
2. Specification of SIV
2. SIVの仕様
2.1. Notation
2.1. 記法
SIV and S2V use the following notation:
SIVとS2Vは以下の記法を使用します:
len(A)
returns the number of bits in A.
len(A)はAのビットの数を返します。
pad(X)
indicates padding of string X, len(X) < 128, out to 128 bits by
the concatenation of a single bit of 1 followed by as many 0 bits
as are necessary.
パッド(X)はストリングXの詰め物を示します、len(X)<128、必要なだけの0ビットが支えた1の1ビットの連結による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、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.
xor Bは2の等しい長さストリング、A、およびBにおける排他的論理和操作です。
Hawkins Informational [Page 6] RFC 5297 SIV-AES October 2008
[6ページ]RFC5297SIV-AES2008年10月の情報のホーキンズ
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).
len(A)>がlen(B)と等しいxorend B、一番左ですなわち、ストリングAの端にストリングBをxoringする手段、(A、len(A)-len(B))|| (一番右です(A、len(B)) xor B)。
A bitand B
is the logical AND operation on two equal length strings, A and B.
bitand Bは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)はSと0の乗法です…010 原始多項式x^128+x^7+x^2+x+1を使用することで表された有限分野で。 物が二つに見えてください(セクション2.3)。
a^b
indicates a string that is "b" bits, each having the value "a".
^bはそれぞれ値の“a"を持っていて、「b」ビットであるストリングを示します。
<zero>
indicates a string that is 128 zero bits.
<ゼロ>は128ゼロ・ビットであるストリングを示します。
<one>
indicates a string that is 127 zero bits concatenated with a
single one bit, that is 0^127 || 1^1.
aが結ぶある>が、示すシングルで、あるビット連結された127ゼロ・ビット、すなわち0^127である<。|| 1^1.
A/B
indicates the greatest integer less than or equal to the real-
valued quotient of A and B.
/Bは最大級の整数Aの本当の評価されたより商とBを示します。
E(K,X)
indicates AES encryption of string X using key K.
E(K、X)は、キーKを使用することでストリングXのAES暗号化を示します。
2.2. Overview
2.2. 概観
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.
CMACモード(S2V)とカウンタモード(CTR)でSIV-AESはAESを使用します。 SIV- AESは256か、384か、512ビットのキー(どれが2個の等しいサイズのキーに壊れるか、そして、S2Vのための1つとCTRのためのもう片方)と、可変長平文と、関連データを表す複数の可変長文字列を取ります。 出力はコード化された平文で連結された合成の初期化ベクトルを包括する暗号文です。
2.3. Doubling
2.3. 倍増します。
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
00000000 00000000 00000000 00000087
Hawkins Informational [Page 7] RFC 5297 SIV-AES October 2008
[7ページ]RFC5297SIV-AES2008年10月の情報のホーキンズ
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のためにサブキーを発生させるのに使用される同じ操作であることに注意してください。
2.4. S2V
2.4. S2V
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操作は擬似ランダム機能の出力の倍増とxoringから成ります、CMAC、個々のストリングの上に入力ベクトルで作動して: S1、S2… , Sn。 それは、ゼロの128ビット列にCMACを実行することによって、独力で進まれます。 ベクトルにおける、最終的なストリングの長さが128ビット以上であるなら、二重/xorチェーンの出力は最終投入量ストリングの端にxoredされます。 結果が最終的なストリングの長さの出力V.Ifを生産するために最終的なCMAC操作に入力されるのは、128ビット未満です、そして、二重/xorチェーンの出力はもう一度倍にされます、そして、最終的なストリングが水増しされている状態で、それは、詰め物機能パッド(X)を使用することでxoredされます。 その結果は、出力Vを起こすために最終的なCMAC操作に入力されます。
S2V with key K on a vector of n inputs S1, S2, ..., Sn-1, Sn, and len(Sn) >= 128:
キーKがnのベクトルにあるS2VはS1、S2を入力します…, Sn-1、Sn、および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 |
+---+
+----+ +----+ +------+ +----+ | S1| | S2| . . . | Sn-1| | Sn| +----+ +----+ +------+ +----+ <ゼロ>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| +---+
Figure 2
図2
Hawkins Informational [Page 8] RFC 5297 SIV-AES October 2008
[8ページ]RFC5297SIV-AES2008年10月の情報のホーキンズ
S2V with key K on a vector of n inputs S1, S2, ..., Sn-1, Sn, and len(Sn) < 128:
キーKがnのベクトルにあるS2VはS1、S2を入力します…, Sn-1、Sn、および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 |
+---+
+----+ +----+ +------+ +---------+ | S1| | S2| . . . | Sn-1| | パッド(Sn)| +----+ +----+ +------+ +---------+ <ゼロ>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| +---+
Figure 3
図3
Algorithmically S2V can be described as:
Algorithmically S2Vを以下と説明できます。
S2V(K, S1, ..., Sn) {
if n = 0 then
return V = AES-CMAC(K, <one>)
fi
D = AES-CMAC(K, <zero>)
for i = 1 to n-1 do
D = dbl(D) xor AES-CMAC(K, Si)
done
if len(Sn) >= 128 then
T = Sn xorend D
else
T = dbl(D) xor pad(Sn)
fi
return V = AES-CMAC(K, T)
}
S2V(K、S1、…、Sn)次に、n=0がV=AES-CMACを返す、(K、n-1へのi=1のための1>) fi D=AES-CMAC(K、<ゼロ>)がDをする<は128当時のT=Sn xorend Dのほかのlen(Sn)>=Tがdbl(D) xorパッド(Sn)fiリターンV=AES-CMAC(K、T)と等しいなら行われたdbl(D) xor AES-CMAC(K、Si)と等しいです。
Hawkins Informational [Page 9] RFC 5297 SIV-AES October 2008
[9ページ]RFC5297SIV-AES2008年10月の情報のホーキンズ
2.5. CTR
2.5. CTR
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、および長さ、および出力Zにおける合成の初期化ベクトルVの連結を表す128ビットと平文と同じ長さである暗号文CであるカウンタXを入力するとき、それは取ります。
The ciphertext is produced by xoring the plaintext with the first len(P) bits of the following string:
暗号文は以下のストリングの最初のlen(P)ビットで平文をxoringすることによって、生産されます:
E(K, X) || E(K, X+1) || E(K, X+2) || ...
E(K、X)|| E(K、X+1)|| E(K、X+2)|| ...
Before beginning counter mode, the 31st and 63rd bits (where the rightmost bit is the 0th bit) of the counter are cleared. This enables implementations that support native 32-bit (64-bit) addition to increment the counter modulo 2^32 (2^64) in a manner that cannot be distinguished from 128-bit increments, as long as the number of increment operations is limited by an upper bound that safely avoids carry to occur out of the respective pre-cleared bit. More formally, for 32-bit addition, the counter is incremented as:
カウンタモードを始める前に、カウンタの31番目と63番目のビット(一番右のビットはそこの0番目のビットである)はきれいにされます。 これは、ネイティブの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は塩と等しいです。|| (n+iモッズ風の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は塩と等しいです。|| (n+iモッズ風の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が安全に128ビットに、それぞれ2^39--128ビットか71 2^ビットに保護できる平文の量は制限されるでしょう。
2.6. SIV Encrypt
2.6. SIVはコード化します。
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.
[ ] ベクトルにおける、コンポーネントの数が126(セクション7を見る)以上でないところで256ビットか384ビットか512ビットの長さの入力aキーK、任意の長さの平文、および関連データADのベクトルとしての撮影をSIVコード化してください。 それは出力、Zを生産します。(それは、長さが平文の長さと等しい128ビットの合成の初期化ベクトルと暗号文の連結です)。
Hawkins Informational [Page 10] RFC 5297 SIV-AES October 2008
[10ページ]RFC5297SIV-AES2008年10月の情報のホーキンズ
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)で一番左(K、len(K)/2)とケーツー=と等しいです。 K1はS2Vに使用されます、そして、ケーツーは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 |
+-----+
+------+ +------+ +------+ +---+ | 西暦1年| | 西暦2年|...| 西暦n年| | P| +------+ +------+ +------+ +---+ | | | | | | ... | ------------------| \ | / / | \ | / / +------------+ | \ | / / | K=K1||ケーツー| | \ | / / +------------+ V\| / / | | +-----+ \ | //K1| | ケーツー| | \ | / / ------/ \------>| CTR| \ | / / / ------->|、|、|、|、|、|、|、| +-----+ V V V V V| | +------------+ +--------+ V| S2V|、-、-、-、-、--、>| V| +----+ +------------+ +--------+ | C| | +----+ | | -----\ | \ | \ | +に対する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
エイト環
Hawkins Informational [Page 11] RFC 5297 SIV-AES October 2008
[11ページ]RFC5297SIV-AES2008年10月の情報のホーキンズ
Algorithmically, SIV Encrypt can be described as:
Algorithmicallyに、SIV Encryptを以下と説明できます。
SIV-ENCRYPT(K, P, AD1, ..., ADn) {
K1 = leftmost(K, len(K)/2)
K2 = rightmost(K, len(K)/2)
V = S2V(K1, AD1, ..., ADn, P)
Q = V bitand (1^64 || 0^1 || 1^31 || 0^1 || 1^31)
m = (len(P) + 127)/128
SIV-ENCRYPT(K、P、AD1、…、ADn)、K1が一番左で等しい、(K、len(K)/2) ケーツーが一番右で等しい、(K、len(K)/2) VがS2Vと等しい、(K1、AD1、…、ADn、V bitand(1^64| | 0^1| | 1^31| | 0^1| | 1^31)m P)Q==(len(P)+127)/128
for i = 0 to m-1 do
Xi = AES(K2, Q+i)
done
X = leftmost(X0 || ... || Xm-1, len(P))
C = P xor X
m-1へのi=0がXが= 一番左で行われたXi=AES(ケーツー、Q+i)をする、(| | 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は見ます。
2.7. SIV Decrypt
2.7. SIVは解読します。
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.
[ ] ベクトルにおける、コンポーネントの数が126(セクション7を見る)以上でないところで256ビットか384ビットか512ビットの長さの入力aキーK、暗号文Cで連結された合成の初期化ベクトルVを表すZ、および関連データADのベクトルとしての撮影をSIV解読してください。 それはオリジナルの平文か特別なシンボルのどちらか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を返します。
Hawkins Informational [Page 12] RFC 5297 SIV-AES October 2008
[12ページ]RFC5297SIV-AES2008年10月の情報のホーキンズ
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
+------+ +------+ +------+ +---+ | 西暦1年| | 西暦2年|...| 西暦n年| | P| +------+ +------+ +------+ +---+ | | | ^ | | ... / | | | / /----------------| | | / / | \ | / / +------------+ | \ | / / | K=K1||k2| | \ | / / +------------+ | \ | / / | | +-----+ \ | //K1| | ケーツー| | \ | | | /-----/ \----->| CTR| \ | | | | ------->|、|、|、|、|、|、|、| +-----+ V V V V V| ^ +-------------+ +--------+ | | S2V| | V| +---+ +-------------+ +--------+ | C| | | ^ +---+ | | | ^ | | \ | | | \___ | V V\| +-------+ +---------+ +---+ | T|、-、-、-、--、>| =です。| | Z| +-------+ +---------+ +---+ | | Vは失敗します。
Figure 10
図10
Hawkins Informational [Page 13] RFC 5297 SIV-AES October 2008
[13ページ]RFC5297SIV-AES2008年10月の情報のホーキンズ
Algorithmically, SIV-Decrypt can be described as:
Algorithmicallyに、缶をSIV解読してください、以下と説明されてください。
SIV-DECRYPT(K, Z, AD1, ..., ADn) {
V = leftmost(Z, 128)
C = rightmost(Z, len(Z)-128)
K1 = leftmost(K, len(K)/2)
K2 = rightmost(K, len(K)/2)
Q = V bitand (1^64 || 0^1 || 1^31 || 0^1 || 1^31)
SIV-DECRYPT(K、Z、AD1、…、ADn)、一番右(K、len(K)/2)の一番左(K、len(K)/2)の一番右(Z、len(Z)-128)の一番左(Z、128)のV=C=K1=ケーツー=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)
m-1へのi=0のための(len(C)+127)/128がXiをするm=がXが= 一番左で行われたAES(ケーツー、Q+i)と等しい、(| | 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と等しいなら、PほかのリターンFAIL fiを返してください。
where the key length used by AES in CTR and S2V is len(K)/2 and will each be either 128 bits, 192 bits, or 256 bits.
CTRとS2VでAESによって使用されたキー長が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は見ます。
3. Nonce-Based Authenticated Encryption with SIV
3. SIVとの一回だけベースの認証された暗号化
SIV performs nonce-based authenticated encryption when a component of the associated data is a nonce. For purposes of interoperability the final component -- i.e., the string immediately preceding the plaintext in the vector input to S2V -- is used for the nonce. Other associated data are optional. It is up to the specific application of SIV to specify how the rest of the associated data are input.
関連データの成分が一回だけであるときに、SIVは一回だけベースの認証された暗号化を実行します。 相互運用性の目的において、最終的なコンポーネント(すなわち、すぐにベクトル入力における平文にS2Vに先行するストリング)は一回だけに使用されます。 他の関連データは任意です。 関連データの残りがどう入力されるかを指定するのはSIVの特定のアプリケーションまで達しています。
If the nonce is random, it SHOULD be at least 128 bits in length and be harvested from a pool having at least 128 bits of entropy. A non- random source MAY also be used, for instance, a time stamp, or a counter. The definition of a nonce precludes reuse, but SIV is resistant to nonce reuse. See Section 1.3.2 for a discussion on the security implications of nonce reuse.
一回だけは無作為であり、それはSHOULDです。長さ少なくとも128ビットになってください、そして、少なくとも128ビットのエントロピーを持っているプールから取り入れられてください。 また、例えば、非無作為のソースは、使用されていてタイムスタンプか、カウンタであるかもしれません。 一回だけの定義は再利用を排除しますが、SIVは一回だけの再利用に抵抗力があります。 一回だけの再利用のセキュリティ含意についての議論に関してセクション1.3.2を見てください。
Hawkins Informational [Page 14] RFC 5297 SIV-AES October 2008
[14ページ]RFC5297SIV-AES2008年10月の情報のホーキンズ
It MAY be necessary to transport this nonce with the output generated by S2V.
出力がS2Vによって発生している状態でこの一回だけを輸送するのが必要であるかもしれません。
4. Deterministic Authenticated Encryption with SIV
4. SIVとの決定論的な認証された暗号化
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]より役に立って汎用の解決策です。 決定論的な認証された暗号化(すなわち、まさしくキーのラッピング以上のための)5月にSIVを使用するプロトコルが関連データ入力をSIVと定義します。 この場合一回だけのコンポーネントをADに加えるのは必要ではありません。
5. Optimizations
5. 最適化
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.
それが主要な派生機能(KDF)として使用されているとき、S2Vの実現を最適化するのは可能です、例えば、[WLAN]で。 これがS2Vが異なったストリングのベクトルを作動させるからである通常、KDFに通過されたデータは一定のストリングを含んでいます。 入力の異形コンポーネントの位置決めによって、異なった最適化は可能です。 中間的で不変なコンポーネントのCMACed出力を一度計算して、キャッシュできます。 次に、これは走行合計で倍にされて、xoredされて、出力を起こすことができます。 または、複数のコンポーネントの倍増してxoredされた出力を異形コンポーネントまで表す中間的値は、一度計算して、キャッシュできます。
6. IANA Considerations
6. IANA問題
[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]はAssociated Data(AEAD)を一回だけベースのAuthenticated Encryptionに提供する暗号モードと一定のインタフェースを定義します。 それは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
3つのエントリーが以下のAEADに基づくAES-SIV-CMAC-256(15)、AES-SIV-CMAC-384(16)、およびAES-SIV-CMAC-512(17)のためにAEAD Registryから割り当てられたインターネットAssigned民数記Authority(IANA)
Hawkins Informational [Page 15] RFC 5297 SIV-AES October 2008
[15ページ]RFC5297SIV-AES2008年10月の情報のホーキンズ
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].
アルゴリズム定義。 [RFC5116]はビットではなく、八重奏における操作を定義します。 したがって、このセクションの限界は八重奏で指定されるでしょう。 それぞれのこれらのアルゴリズムのための証券分析が[DAE]にあります。
Unfortunately, [RFC5116] restricts AD input to a single component and limits the benefit SIV offers for dealing in a natural fashion with AD consisting of multiple distinct components. Therefore, when it is required to access SIV through the interface defined in [RFC5116], it is necessary to marshal multiple AD inputs into a single string (see Section 1.1) prior to invoking SIV. Note that this requirement is not unique to SIV. All cipher modes using [RFC5116] MUST similarly marshal multiple AD inputs into a single string, and any technique used for any other AEAD mode (e.g., a scatter/gather technique) can be used with SIV.
残念ながら、[RFC5116]はただ一つのコンポーネントに入力されたADと利益SIVがADが複数の異なったコンポーネントから成っていて自然なファッションを扱うために提供する限界を制限します。 したがって、それが[RFC5116]で定義されたインタフェースを通してSIVにアクセスするのに必要であるときに、SIVを呼び出す前に一連(セクション1.1を見る)に複数のAD入力を整理するのが必要です。 この要件がSIVにユニークでないことに注意してください。 [RFC5116]を使用するすべての暗号モードが同様に複数のAD入力を一連に整理しなければなりません、そして、SIVと共にいかなる他のAEADモード(例えば、散布/はテクニックを集める)にも使用されるどんなテクニックも使用できます。
[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のただ一つの実施で安全に保護できる平文の量への限界は128ブロック2^です。
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]は、同じキーで2つ未満の^48実施をCMACにすることを勧めます。 これはもっともCMACに通過できるデータ量における限界ではありません。 CMACのただ一つの実施にすることができるデータ量へのどんな実用的な限界もありません、そして、同様に、SIVに渡すことができる関連データか一回だけの材料の量へのどんな実用的な限界もありません。
A collision in the output of S2V would mean the same counter would be used with different plaintext in counter mode. This would void the security guarantees of SIV. The "Birthday Paradox" (see [APPCRY]) would imply that no more than 2^64 distinct invocations to SIV be made with the same key. It is prudent to follow the example of [CMAC] though, and further limit the number of distinct invocations of SIV using the same key to 2^48. Note that [RFC5116] does not provide a variable to describe this limit.
S2Vの出力における衝突は、同じカウンタが異なった平文と共にカウンタモードで使用されることを意味するでしょう。 これはSIVのセキュリティ保証を欠如させるでしょう。 「誕生日のパラドックス」([APPCRY]を見る)は、SIVへの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
SIVのためのカウンタスペースは2^128です。 SIVの各実施はそのカウンタスペースの部分を消費します、そして、消費された量はそのただ一つの実施に通過される平文の量に依存します。 同じキーがあるSIVの複数の実施が異なった実施がカウンタスペースを重ね合わせる可能性を増加させることができます。 aで安全に保護できる平文の総量
Hawkins Informational [Page 16] RFC 5297 SIV-AES October 2008
[16ページ]RFC5297SIV-AES2008年10月の情報のホーキンズ
single key is, therefore, a function of the number of distinct invocations and the amount of plaintext protected with each invocation.
したがって、単一のキーは異なった実施の数と各実施で保護された平文の量の関数です。
6.1. AEAD_AES_SIV_CMAC_256
6.1. AEAD_AES_SIV_CMAC_256
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.
_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で説明されます。
6.2. AEAD_AES_SIV_CMAC_384
6.2. AEAD_AES_SIV_CMAC_384
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.
_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で説明されます。
Hawkins Informational [Page 17] RFC 5297 SIV-AES October 2008
[17ページ]RFC5297SIV-AES2008年10月の情報のホーキンズ
6.3. AEAD_AES_SIV_CMAC_512
6.3. AEAD_AES_SIV_CMAC_512
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.
_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で説明されます。
7. Security Considerations
7. セキュリティ問題
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の出力がコード化する意味における秘密性はビットの無作為のストリングから区別がつきません。 それは攻撃者がFAILを除いて、それがSIV解読するために入力されたいつを返す一連のビットを構成できないという意味における信憑性を提供します。 SIVのセキュリティの証拠、「オール、1、」 認証された暗号化計画のためのセキュリティの概念を[DAE]に提供します。
SIV provides deterministic "key wrapping" when the plaintext contains data that is unpredictable to an adversary (for instance, a cryptographic key). Even when this key is made available to an attacker the output of SIV-Encrypt is indistinguishable from random bits. Similarly, even when this key is made available to an attacker, she is unable to construct a string of bits that when input to SIV-Decrypt will return anything other than FAIL.
平文が敵(例えば、暗号化キー)にとって、予測できないデータを含んでいると、SIVは決定論的な「主要なラッピング」を提供します。 このキーを攻撃者にとって利用可能にしさえする、出力、SIVコード化、無作為のビットから、区別がつきません。 このキーを攻撃者にとって利用可能にするときさえ、SIV解読する入力がFAIL以外の何も返すとき、同様に、彼女はそれを一連のビット組み立てることができません。
When the nonce used in the nonce-based authenticated encryption mode of SIV-AES is treated with the care afforded a nonce or counter in other conventional nonce-based authenticated encryption schemes -- i.e., guarantee that it will never be used with the same key for two distinct invocations -- then SIV achieves the level of security described above. If, however, the nonce is reused SIV continues to provide the level of authenticity described above but with a slightly reduced amount of privacy (see Section 1.3.2).
SIV-AESの一回だけベースの認証された暗号化モードで使用される一回だけが他の従来の一回だけベースの認証された暗号化計画で一回だけかカウンタを都合する注意で扱われると(すなわち、それが2つの異なった実施に同じキーと共に決して使用されないのを保証してください)、SIVは上で説明されたセキュリティのレベルを達成します。 しかしながら、一回だけが再利用されるなら、SIVは、プライバシーにもかかわらず、わずかに減少している量のプライバシーで説明された信憑性のレベルを提供し続けています(セクション1.3.2を見てください)。
Hawkins Informational [Page 18] RFC 5297 SIV-AES October 2008
[18ページ]RFC5297SIV-AES2008年10月の情報のホーキンズ
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に制限されるときだけ、セキュリティが立証される、blocksizeする、基本的な疑似確率関数について。そこでは、nがそうです。 ここで使用された基本的な擬似ランダム機能がAESに基づいている、だれのもの、blocksizeする、128ビットはそうです。 したがって、127以上のコンポーネントをS2Vに渡してはいけません。 SIVがコンポーネントとしてS2Vに平文を含めるので、それは安全にSIVに通過できる関連データの成分の数を126に制限します。
8. Acknowledgments
8. 承認
Thanks to Phil Rogaway for patiently answering numerous questions on SIV and S2V and for useful critiques of earlier versions of this paper. Thanks also to David McGrew for numerous helpful comments and suggestions for improving this paper. Thanks to Jouni Malinen for reviewing this paper and producing another independent implementation of SIV, thereby confirming the correctness of the test vectors.
SIVとS2Vの我慢強く答えている多数の質問とこの紙の以前のバージョンの役に立つ批評をフィルRogawayをありがとうございます。 また、頻繁な役に立つコメントのためのデヴィッド・マグリューとこの紙を改良するための提案をありがとうございます。 この紙を批評して、SIVの別の独立している実現をJouni Malinenに起こしてくださってありがとうございます、その結果、テストベクトルの正当性を確認します。
9. References
9. 参照
9.1. Normative References
9.1. 引用規格
[CMAC] Dworkin, M., "Recommendation for Block Cipher Modes of
Operation: The CMAC Mode for Authentication", NIST
Special Pulication 800-38B, May 2005.
[CMAC]ドーキン、M.、「ブロックのための推薦は運転モードを解きます」。 「認証のためのCMACモード」(NISTの特別なPulication800-38B)は2005がそうするかもしれません。
[MODES] Dworkin, M., "Recommendation for Block Cipher Modes of
Operation: Methods and Techniques", NIST Special
Pulication 800-38A, 2001 edition.
[モード]ドーキン、M.、「ブロックのための推薦は運転モードを解きます」。 「方法とTechniques」、NIST Special Pulication800-38A、2001年の版。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC5116] McGrew, D., "An Interface and Algorithms for
Authenticated Encryption", RFC 5116, January 2008.
[RFC5116] マグリューと、D.と、「認証された暗号化のためのインタフェースとアルゴリズム」、RFC5116、1月2008日
9.2. Informative References
9.2. 有益な参照
[APPCRY] Menezes, A., van Oorshot, P., and S. Vanstone, "Handbook
of Applied Cryptography", CRC Press Series on Discrete
Mathematics and Its Applications, 1996.
Discrete MathematicsとIts Applications、1996の[APPCRY]メネゼスとA.とバンOorshot、P.とS.Vanstone、「適用された暗号のハンドブック」CRC Press Series。
Hawkins Informational [Page 19] RFC 5297 SIV-AES October 2008
[19ページ]RFC5297SIV-AES2008年10月の情報のホーキンズ
[BADESP] Bellovin, S., "Problem Areas for the IP Security
Protocols", Proceedings from the 6th Usenix UNIX Security
Symposium, July 22-25 1996.
[BADESP] 第6Usenix UNIXセキュリティシンポジウム(1996 7月22日〜25日)からのBellovin、S.、「IPセキュリティー・プロトコルのための問題領域」、議事。
[RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with
CBC-MAC (CCM)", RFC 3610, September 2003.
2003年9月の[RFC3610]ホワイティングとD.とHousley、R.とN.ファーガソン、「CBC-MAC(立方センチメートル)があるカウンタ」RFC3610。
[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.
P.とT.Shrimpton、「決定論的な認証された暗号化、主要な包装問題の証明可能なセキュリティ処理」という[DAE]Rogawayは暗号理論で進みます--EUROCRYPT'06サンクトペテルブルグ(ロシア)2006'。
[GCM] McGrew, D. and J. Viega, "The Galois/Counter Mode of
Operation (GCM)".
[GCM] マグリューとD.とJ.Viega、「ガロア/カウンタ運転モード(GCM)。」
[JUTLA] Jutla, C., "Encryption Modes With Almost Free Message
Integrity", Proceedings of the International Conference
on the Theory and Application of Cryptographic
Techniques: Advances in Cryptography.
[JUTLA] Jutla、C.、「ほとんど自由なメッセージの保全がある暗号化モード」、暗号のテクニックの理論と応用の国際会議の議事: 暗号における進歩。
[OCB] Krovetz, T. and P. Rogaway, "The OCB Authenticated
Encryption Algorithm", Work in Progress, March 2005.
[OCB] 「OCBは暗号化アルゴリズムを認証した」というKrovetz、T.、およびP.Rogawayは進歩、2005年3月に働いています。
[RADKEY] Zorn, G., Zhang, T., Walker, J., and J. Salowey, "RADIUS
Attributes for the Delivery of Keying Material", Work in
Progress, April 2007.
[RADKEY] ゾルン、G.、チャン、T.、ウォーカー、J.、およびJ.Salowey、「合わせることの材料の配送のための半径属性」が進行中(2007年4月)で働いています。
[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、「無作為のオラクルはPracticalです」。 「効率的なプロトコルを設計するためのパラダイム」とコンピュータの上の最初のACMコンファレンスの進行と通信秘密保全、1993年11月。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, February
1997.
[RFC2104] Krawczyk、H.、Bellare、M.、およびR.カネッティ、「HMAC:」 「通報認証のための合わせられた論じ尽くす」RFC2104、1997年2月。
[RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes",
RFC 2548, March 1999.
[RFC2548] ゾルン、G.、「マイクロソフトの業者特有の半径属性」、RFC2548、1999年3月。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.
[RFC2865] Rigney、C.、ウィレンス、S.、ルーベン、A.、およびW.シンプソン、「ユーザサービス(半径)におけるリモート認証ダイヤル」、RFC2865(2000年6月)。
[RFC3217] Housley, R., "Triple-DES and RC2 Key Wrapping", RFC 3217,
December 2001.
[RFC3217]Housley、R.、「三重のDESとRC2の主要なラッピング」、RFC3217、2001年12月。
Hawkins Informational [Page 20] RFC 5297 SIV-AES October 2008
[20ページ]RFC5297SIV-AES2008年10月の情報のホーキンズ
[RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard
(AES) Key Wrap Algorithm", RFC 3394, September 2002.
[RFC3394] SchaadとJ.とR.Housley、「エー・イー・エス(AES)の主要な包装アルゴリズム」、RFC3394、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]ドーキン、M.、「ブロックのための推薦は運転モードを解きます」。 「ガロアはモード(GCM)とGMACを打ち返す」NISTの特別なPulication800-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] ガーフィンケル、T.、およびM.ローゼンブラム、「いつVirtualはレアルよりハーダーです」。 オペレーティングシステムによる最新の話題に関する第10ワークショップで「セキュリティは仮想計算機のベースのコンピューティング環境で挑戦すること」は2005がそうするかもしれません。
[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]ドーキン、M.、「キーと関連データのラッピング」(主要な包装アルゴリズムのレビューのためのRequest)暗号理論ePrintは2004/340、2004を報告します。 内容はAccredited Standards Committee、ANS X9.102の権利を与えられたX9の草稿規格からの抜粋です。
Hawkins Informational [Page 21] RFC 5297 SIV-AES October 2008
[21ページ]RFC5297SIV-AES2008年10月の情報のホーキンズ
Appendix A. Test Vectors
付録A.テストベクトル
The following test vectors are for the mode defined in Section 6.1.
以下のテストベクトルはセクション6.1で定義されたモードのためのものです。
A.1. Deterministic Authenticated Encryption Example
A.1。 決定論的な認証された暗号化の例
Input:
-----
Key:
fffefdfc fbfaf9f8 f7f6f5f4 f3f2f1f0
f0f1f2f3 f4f5f6f7 f8f9fafb fcfdfeff
以下を入力してください。 ----- キー: fffefdfc fbfaf9f8 f7f6f5f4 f3f2f1f0 f0f1f2f3 f4f5f6f7 f8f9fafb fcfdfeff
AD:
10111213 14151617 18191a1b 1c1d1e1f
20212223 24252627
AD: 10111213 14151617 18191a1b 1c1d1e1f20212223 24252627
Plaintext:
11223344 55667788 99aabbcc ddee
平文: 11223344 55667788 99aabbcc ddee
S2V-CMAC-AES
------------
CMAC(zero):
0e04dfaf c1efbf04 01405828 59bf073a
S2V-CMAC-AES------------ CMAC(ゼロ): 0e04dfaf c1efbf04 01405828 59bf073a
double():
1c09bf5f 83df7e08 0280b050 b37e0e74
()を倍にしてください: 1c09bf5f 83df7e08 0280b050 b37e0e74
CMAC(ad):
f1f922b7 f5193ce6 4ff80cb4 7d93f23b
CMAC(広告): f1f922b7 f5193ce6 4ff80cb4 7d93f23b
xor:
edf09de8 76c642ee 4d78bce4 ceedfc4f
xor: edf09de8 76c642ee 4d78bce4 ceedfc4f
double():
dbe13bd0 ed8c85dc 9af179c9 9ddbf819
()を倍にしてください: dbe13bd0 ed8c85dc 9af179c9 9ddbf819
pad:
11223344 55667788 99aabbcc ddee8000
以下を水増ししてください。 11223344 55667788 99aabbcc ddee8000
xor:
cac30894 b8eaf254 035bc205 40357819
xor: cac30894 b8eaf254 035bc205 40357819
CMAC(final):
85632d07 c6e8f37f 950acd32 0a2ecc93
CMAC(決勝): 85632d07 c6e8f37f 950acd32 0a2ecc93
Hawkins Informational [Page 22] RFC 5297 SIV-AES October 2008
[22ページ]RFC5297SIV-AES2008年10月の情報のホーキンズ
CTR-AES
-------
CTR:
85632d07 c6e8f37f 150acd32 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
出力------ IV|| C: 85632d07 c6e8f37f 950acd32 0a2ecc93 40c02b96 90c4dc04 daef7f6a fe5c
A.2. Nonce-Based Authenticated Encryption Example
A.2。 一回だけベースの認証された暗号化の例
Input:
-----
Key:
7f7e7d7c 7b7a7978 77767574 73727170
40414243 44454647 48494a4b 4c4d4e4f
以下を入力してください。 ----- キー: 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
一回だけ: 09f91102 9d74e35b d84156c5 635688c0
Plaintext:
74686973 20697320 736f6d65 20706c61
696e7465 78742074 6f20656e 63727970
74207573 696e6720 5349562d 414553
平文: 74686973 20697320 736f6d65 20706c61 696e7465 78742074 6f20656e63727970 74207573 696e6720 5349562d414553
Hawkins Informational [Page 23] RFC 5297 SIV-AES October 2008
[23ページ]RFC5297SIV-AES2008年10月の情報のホーキンズ
S2V-CMAC-AES
------------
CMAC(zero):
c8b43b59 74960e7c e6a5dd85 231e591a
S2V-CMAC-AES------------ CMAC(ゼロ): c8b43b59 74960e7c e6a5dd85 231e591a
double():
916876b2 e92c1cf9 cd4bbb0a 463cb2b3
()を倍にしてください: 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
()を倍にしてください: 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
()を倍にしてください: 04d54eb6 bcad1dda 624b7f64 cd8c3a1b
CMAC(nonce)
128c62a1 ce3747a8 372c1c05 a538b96d
CMACの(一回だけ)の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 6f20656e63727966 2d0c6201 f3341575 342a3745 f5c625
CMAC(final)
7bdb6e3b 432667eb 06f4d14b ff2fbd0f
CMACの(最終的)の7bdb6e3b 432667eb 06f4d14b ff2fbd0f
Hawkins Informational [Page 24] RFC 5297 SIV-AES October 2008
[24ページ]RFC5297SIV-AES2008年10月の情報のホーキンズ
CTR-AES
-------
CTR:
7bdb6e3b 432667eb 06f4d14b 7f2fbd0f
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 ba8af829ea64ad54 4a272e9c 485b62a3 fd5c0d
output
------
IV || C:
7bdb6e3b 432667eb 06f4d14b ff2fbd0f
cb900f2f ddbe4043 26601965 c889bf17
dba77ceb 094fa663 b7a3f748 ba8af829
ea64ad54 4a272e9c 485b62a3 fd5c0d
出力------ IV|| C: 7bdb6e3b 432667eb 06f4d14b ff2fbd0f cb900f2f ddbe4043 26601965 c889bf17 dba77ceb 094fa663b7a3f748 ba8af829 ea64ad54 4a272e9c 485b62a3 fd5c0d
Author's Address
作者のアドレス
Dan Harkins Aruba Networks
ダンハーキンアルーバネットワーク
EMail: dharkins@arubanetworks.com
メール: dharkins@arubanetworks.com
Hawkins Informational [Page 25] RFC 5297 SIV-AES October 2008
[25ページ]RFC5297SIV-AES2008年10月の情報のホーキンズ
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(2008)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Hawkins Informational [Page 26]
ホーキンズInformationalです。[26ページ]
一覧
スポンサーリンク
