Network Working Group T. Krovetz, Ed.
Request for Comments: 4418 CSU Sacramento
Category: Informational March 2006
UMAC: Message Authentication Code using Universal Hashing
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.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
This specification describes how to generate an authentication tag using the UMAC message authentication algorithm. UMAC is designed to be very fast to compute in software on contemporary uniprocessors. Measured speeds are as low as one cycle per byte. UMAC relies on addition of 32-bit and 64-bit numbers and multiplication of 32-bit numbers, operations well-supported by contemporary machines.
この仕様は、UMACメッセージ認証アルゴリズムを使用して認証タグを生成する方法について説明します。 UMACは、現代のユニプロセッサ上のソフトウェアで計算するのは非常に速くなるように設計されています。測定速度はバイト当たり1サイクルと同じくらい低いです。 UMACは、32ビットおよび64ビットの数値と32ビットの数の乗算、現代のマシンでよくサポートされている操作のほかに依存しています。
To generate the authentication tag on a given message, a "universal" hash function is applied to the message and key to produce a short, fixed-length hash value, and this hash value is then xor'ed with a key-derived pseudorandom pad. UMAC enjoys a rigorous security analysis, and its only internal "cryptographic" component is a block cipher used to generate the pseudorandom pads and internal key material.
所与のメッセージの認証タグを生成するために、「ユニバーサル」ハッシュ関数は、短い、固定長のハッシュ値を生成するメッセージとキーに適用され、このハッシュ値は、キー由来の擬似ランダムパッドとXORされます。 UMACは、厳密なセキュリティ分析を楽しんで、その内部でのみ「暗号化」成分は、擬似ランダムパッドと内部鍵材料を生成するために使用されるブロック暗号です。
Table of Contents
目次
1. Introduction ....................................................3
2. Notation and Basic Operations ...................................4
2.1. Operations on strings ......................................4
2.2. Operations on Integers .....................................5
2.3. String-Integer Conversion Operations .......................6
2.4. Mathematical Operations on Strings .........................6
2.5. ENDIAN-SWAP: Adjusting Endian Orientation ..................6
2.5.1. ENDIAN-SWAP Algorithm ...............................6
3. Key- and Pad-Derivation Functions ...............................7
3.1. Block Cipher Choice ........................................7
3.2. KDF: Key-Derivation Function ...............................8
3.2.1. KDF Algorithm .......................................8
3.3. PDF: Pad-Derivation Function ...............................8
3.3.1. PDF Algorithm .......................................9
4. UMAC Tag Generation ............................................10
4.1. UMAC Algorithm ............................................10
4.2. UMAC-32, UMAC-64, UMAC-96, and UMAC-128 ...................10
5. UHASH: Universal Hash Function .................................10
5.1. UHASH Algorithm ...........................................11
5.2. L1-HASH: First-Layer Hash .................................12
5.2.1. L1-HASH Algorithm ..................................12
5.2.2. NH Algorithm .......................................13
5.3. L2-HASH: Second-Layer Hash ................................14
5.3.1. L2-HASH Algorithm ..................................14
5.3.2. POLY Algorithm .....................................15
5.4. L3-HASH: Third-Layer Hash .................................16
5.4.1. L3-HASH Algorithm ..................................16
6. Security Considerations ........................................17
6.1. Resistance to Cryptanalysis ...............................17
6.2. Tag Lengths and Forging Probability .......................17
6.3. Nonce Considerations ......................................19
6.4. Replay Attacks ............................................20
6.5. Tag-Prefix Verification ...................................21
6.6. Side-Channel Attacks ......................................21
7. Acknowledgements ...............................................21
Appendix. Test Vectors ............................................22
References ........................................................24
Normative References ...........................................24
Informative References .........................................24
UMAC is a message authentication code (MAC) algorithm designed for high performance. It is backed by a rigorous formal analysis, and there are no intellectual property claims made by any of the authors to any ideas used in its design.
UMACは、高性能のために設計されたメッセージ認証コード（MAC）アルゴリズムです。これは、厳格な形式的分析に裏打ちされた、およびその設計に使用される任意のアイデアへの著者のいずれかによって作られたいかなる知的財産請求は存在しません。
UMAC is a MAC in the style of Wegman and Carter [4, 7]. A fast "universal" hash function is used to hash an input message M into a short string. This short string is then masked by xor'ing with a pseudorandom pad, resulting in the UMAC tag. Security depends on the sender and receiver sharing a randomly-chosen secret hash function and pseudorandom pad. This is achieved by using keyed hash function H and pseudorandom function F. A tag is generated by performing the computation
UMACはウェッグマンとカーターのスタイルでMAC [4,7]です。速い「ユニバーサル」ハッシュ関数は、短い文字列に入力されたメッセージMをハッシュするために使用されます。この短い文字列は、その後、UMACタグを生じる、擬似ランダムパッドとXORしによりマスクされます。セキュリティは、ランダムに選ばれた秘密のハッシュ関数と擬似ランダムパッドを共有し、送信者と受信者に依存します。これは、タグは計算を実行することによって生成されたF.鍵付きハッシュ関数Hと擬似ランダム関数を使用することによって達成されます
Tag = H_K1(M) xor F_K2(Nonce)
タグ= H_K1（M）のXOR F_K2（ナンス）
where K1 and K2 are secret random keys shared by sender and receiver, and Nonce is a value that changes with each generated tag. The receiver needs to know which nonce was used by the sender, so some method of synchronizing nonces needs to be used. This can be done by explicitly sending the nonce along with the message and tag, or agreeing upon the use of some other non-repeating value such as a sequence number. The nonce need not be kept secret, but care needs to be taken to ensure that, over the lifetime of a UMAC key, a different nonce is used with each message.
ここで、K1およびK2は、送信側と受信側で共有秘密ランダム鍵であり、ノンスは、それぞれ生成されたタグと変化する値です。受信機は、送信者によって使用されたナンスを知る必要があり、そうナンスを同期させるいくつかの方法を使用する必要があります。これは、シーケンス番号として明示的メッセージとタグと一緒にナンスを送信し、またはいくつかの他の非反復値の使用に同意することによって行うことができます。ナンスは秘密にする必要はなく、ケアはUMACキーの寿命にわたって、異なるノンスは各メッセージに使用されている、ように注意する必要があります。
UMAC uses a keyed function, called UHASH (also specified in this document), as the keyed hash function H and uses a pseudorandom function F whose default implementation uses the Advanced Encryption Standard (AES) algorithm. UMAC is designed to produce 32-, 64-, 96-, or 128-bit tags, depending on the desired security level. The theory of Wegman-Carter MACs and the analysis of UMAC show that if one "instantiates" UMAC with truly random keys and pads then the probability that an attacker (even a computationally unbounded one) produces a correct tag for any message of its choosing is no more than 1/2^30, 1/2^60, 1/2^90, or 1/2^120 if the tags output by UMAC are of length 32, 64, 96, or 128 bits, respectively (here the symbol ^ represents exponentiation). When an attacker makes N forgery attempts, the probability of getting one or more tags right increases linearly to at most N/2^30, N/2^60, N/2^90, or N/2^120. In a real implementation of UMAC, using AES to produce keys and pads, the forgery probabilities listed above increase by a small amount related to the security of AES. As long as AES is secure, this small additive term is insignificant for any practical attack. See Section 6.2 for more details. Analysis relevant to UMAC security is in [3, 6].
UMACは、鍵付きハッシュ関数Hとして、UHASH（また、本書で指定）と呼ばれ、鍵付き関数を使用し、そのデフォルト実装のAdvanced Encryption Standard（AES）アルゴリズムを使用して擬似ランダム関数Fを使用しています。 UMACは、所望のセキュリティレベルに応じて、32、64、96、または128ビットのタグを生成するように設計されています。ウェッグマン-カーターMACの理論とUMACの分析は1つが真にランダムなキーとパッドとUMACを「インスタンス化」場合、攻撃者（でも、計算上無制限1）はその選択した任意のメッセージのための正しいタグを生成する確率があることを示していますこれ以上ここで（それぞれ、UMACによってタグ出力は、長さ32、64、96である、または128ビットの場合に120 ^ 90 ^ 1/2 60 ^ 1/2 30 ^ 1/2よりもない、又は/ 2シンボル^累乗を表しています）。攻撃者は、N個の偽造の試み、直線的に最大でN / 2 ^ 30に1つまたは複数のタグ右増加を得る確率を行うと/ 2 ^ 60 N、N / 2 ^ 90、又はN / 2 ^ 120。 UMACの実際の実装では、キーとパッドを生産するためにAESを使用して、偽造確率は、AESのセキュリティに関連する少量の増加上記の。限りAESが安全であるように、この小さな添加剤の用語は、任意の実用的な攻撃のために重要ではありません。詳細は、6.2節を参照してください。 UMACのセキュリティに関連する分析は[3,6]です。
UMAC performs best in environments where 32-bit quantities are efficiently multiplied into 64-bit results. In producing 64-bit tags on an Intel Pentium 4 using SSE2 instructions, which do two of these multiplications in parallel, UMAC processes messages at a peak rate of about one CPU cycle per byte, with the peak being achieved on messages of around four kilobytes and longer. On the Pentium III, without the use of SSE parallelism, UMAC achieves a peak of two cycles per byte. On shorter messages, UMAC still performs well: around four cycles per byte on 256-byte messages and under two cycles per byte on 1500-byte messages. The time to produce a 32-bit tag is a little more than half that needed to produce a 64-bit tag, while 96- and 128-bit tags take one-and-a-half and twice as long, respectively.
UMACは、32ビット量を効率的に64ビットの結果に乗算される環境で最もよく行います。並行して、これらの乗算のうちの2つを行うSSE2命令を使用して、インテルのPentium 4で64ビット・タグを製造する際に、UMACは、ピークを約4キロバイトのメッセージに達成されると、バイト当たり約1つのCPUサイクルのピーク速度でメッセージを処理しますそして長いです。 Pentium IIIで、SSEの並列処理を使用せずに、UMACは、バイトごとに2つのサイクルのピークを実現しています。短いメッセージでは、UMACはまだよく実行します。256バイトのメッセージのバイト当たり4サイクルの周りと1500バイトのメッセージのバイト当たり2サイクルの下で。 32ビットのタグを生成するための時間は、96と128ビットのタグはそれぞれ1半二回限りを取るしながら、64ビットのタグを生成するために必要なほとんど半分以上です。
Optimized source code, performance data, errata, and papers concerning UMAC can be found at http://www.cs.ucdavis.edu/~rogaway/umac/.
最適化されたソースコード、パフォーマンスデータ、正誤表、及びUMACに関する論文はhttp://www.cs.ucdavis.edu/~rogaway/umac/で見つけることができます。
The specification of UMAC involves the manipulation of both strings and numbers. String variables are denoted with an initial uppercase letter, whereas numeric variables are denoted in all lowercase. The algorithms of UMAC are denoted in all uppercase letters. Simple functions, like those for string-length and string-xor, are written in all lowercase.
UMACの仕様は、文字列と数字の両方の操作を含みます。数値変数はすべて小文字で表記されているのに対し、String型の変数は、最初の大文字で表記されています。 UMACのアルゴリズムはすべて大文字で表記されています。単純な関数は、文字列の長さと文字列のXORのもののように、すべて小文字で書かれています。
Whenever a variable is followed by an underscore ("_"), the underscore is intended to denote a subscript, with the subscripted expression evaluated to resolve the meaning of the variable. For example, if i=2, then M_{2 * i} refers to the variable M_4.
変数はアンダースコア（「_」）が続いているときはいつでも、アンダースコアは、変数の意味を解決するために評価添字式で、添字を意味することが意図されます。 I = 2の場合、例えば、次にM_は{2 * I}変数M_4を指します。
Messages to be hashed are viewed as strings of bits that get zero-padded to an appropriate byte length. Once the message is padded, all strings are viewed as strings of bytes. A "byte" is an 8-bit string. The following notation is used to manipulate these strings.
メッセージは、適切なバイト長までゼロパディング得るビット列とみなされるハッシュします。メッセージが水増しされたら、すべての文字列はバイトの文字列として表示されます。 「バイト」は8ビットの文字列です。以下の表記は、これらの文字列を操作するために使用されます。
bytelength(S): The length of string S in bytes.
バイト長（S）：バイトの文字列Sの長さ。
bitlength(S): The length of string S in bits.
ビット長（S）：ビットの文字列Sの長さ。
zeroes(n): The string made of n zero-bytes.
ゼロ（N）：Nゼロバイトからなる文字列。
S xor T: The string that is the bitwise exclusive-or of S and T. Strings S and T always have the same length.
S XOR T：排他的論理和SとT.文字列SとTのビット単位が常に同じ長さを持つ文字列。
S and T: The string that is the bitwise conjunction of S and T. Strings S and T always have the same length.
SとT：SとT.文字列SとTのビット単位の組み合わせである文字列は、常に同じ長さを有しています。
S[i]: The i-th byte of the string S (indices begin at 1).
S [i]は：文字列Sのi番目のバイトを（インデックスは1から始まります）。
S[i...j]: The substring of S consisting of bytes i through j.
S [I ... J]：私はjを経由バイトからなるSのサブストリング。
S || T: The string S concatenated with string T.
S || T：文字列は、文字列Tに連結S
zeropad(S,n): The string S, padded with zero-bits to the nearest positive multiple of n bytes. Formally, zeropad(S,n) = S || T, where T is the shortest string of zero-bits (possibly empty) so that S || T is non-empty and 8n divides bitlength(S || T).
ZEROPAD（S、N）：文字列Sは、nバイトの最も近い正倍数にゼロビットでパディング。正式に、ZEROPAD（S、N）= S || Tは、ゼロビット（空）の最短の文字列であるように、S T、|| Tが空でないと8Nは、ビット長（S || T）を分割します。
Standard notation is used for most mathematical operations, such as "*" for multiplication, "+" for addition and "mod" for modular reduction. Some less standard notations are defined here.
標準的な表記法は、そのような添加のために乗算するための「*」、「+」とモジュラー削減のための「MOD」として、ほとんどの数学的操作に使用されます。いくつかの少ない標準表記法はここで定義されています。
a^i: The integer a raised to the i-th power.
^私：整数のi乗。
ceil(x): The smallest integer greater than or equal to x.
CEIL（X）：x以上の最小の整数。
prime(n): The largest prime number less than 2^n.
プライム（N）：2 ^ nよりも小さい最大の素数。
The prime numbers used in UMAC are:
UMACで使用される素数は以下のとおりです。
+-----+--------------------+---------------------------------------+
| n | prime(n) [Decimal] | prime(n) [Hexadecimal] |
+-----+--------------------+---------------------------------------+
| 36 | 2^36 - 5 | 0x0000000F FFFFFFFB |
| 64 | 2^64 - 59 | 0xFFFFFFFF FFFFFFC5 |
| 128 | 2^128 - 159 | 0xFFFFFFFF FFFFFFFF FFFFFFFF FFFFFF61 |
+-----+--------------------+---------------------------------------+
Conversion between strings and integers is done using the following functions. Each function treats initial bits as more significant than later ones.
文字列と整数間の変換は、以下の機能を使用して行われます。各機能は、後のものよりも重要として、最初のビットを扱います。
bit(S,n): Returns the integer 1 if the n-th bit of the string S is 1, otherwise returns the integer 0 (indices begin at 1).
ビット（S、N）：文字列Sのn番目のビットが1であれば、整数1を返し、そうでない場合は整数0（インデックスが1から始まる）を返し。
str2uint(S): The non-negative integer whose binary representation is the string S. More formally, if S is t bits long then str2uint(S) = 2^{t-1} * bit(S,1) + 2^{t-2} * bit(S,2) + ... + 2^{1} * bit(S,t-1) + bit(S,t).
str2uint（S）：そのバイナリ表現より正式に、ストリングSである非負の整数Sは長いその後str2uint（S）= 2 ^ {T-1} *ビットtビットである場合（S 1）+ 2 ^ {T-2} *ビット（S、2）+ ... + 2 ^ {1} *ビット（S、T-1）+ビット（S、T）。
uint2str(n,i): The i-byte string S such that str2uint(S) = n.
uint2str（N、I）：I-バイトストリングSようstr2uint（S）= N。
One of the primary operations in UMAC is repeated application of addition and multiplication on strings. The operations "+_32", "+_64", and "*_64" are defined
UMACにおける主要事業の一つは、文字列の加算と乗算の適用を繰り返しています。操作 "+ _32"、 "+ _64"、および "* _64" に定義されています
"S +_32 T" as uint2str(str2uint(S) + str2uint(T) mod 2^32, 4), "S +_64 T" as uint2str(str2uint(S) + str2uint(T) mod 2^64, 8), and "S *_64 T" as uint2str(str2uint(S) * str2uint(T) mod 2^64, 8).
"S + _32 T" uint2strとして（str2uint（S）+ str2uint（T）MOD 2 ^ 32、4）、 "S + _64 T" uint2str（str2uint（S）+ str2uint（T）MODとして2 ^ 64、8 ）、および "S * _64 T" uint2str（str2uint（S）* str2uint（T）2 ^ 64 MODとして、8）。
These operations correspond well with the addition and multiplication operations that are performed efficiently by modern computers.
これらの操作は、現代のコンピュータで効率的に実行されているほか、乗算演算とよく対応しています。
Message data is read little-endian to speed tag generation on little-endian computers.
メッセージデータは、リトルエンディアンのコンピュータ上でのタグの生成を高速化するためにリトルエンディアンを読まれます。
Input: S, string with length divisible by 4 bytes. Output: T, string S with each 4-byte word endian-reversed.
入力：S、4バイトで割り切れる長さのストリング。出力：T、各4バイトワードで文字列Sは、エンディアン反転します。
Compute T using the following algorithm.
次のアルゴリズムを使用してTを計算します。
// // Break S into 4-byte chunks // n = bytelength(S) / 4 Let S_1, S_2, ..., S_n be strings of length 4 bytes so that S_1 || S_2 || ... || S_n = S.
S_1よう//ブレークS 4バイトのチャンクに// N =バイト長（S）/ 4レッツS_1、S_2、...、S_Nは、4バイト長の文字列である|| S_2 || ... || S_N = S.
// // Byte-reverse each chunk, and build-up T // T = <empty string> for i = 1 to n do Let W_1, W_2, W_3, W_4 be bytes so that W_1 || W_2 || W_3 || W_4 = S_i SReversed_i = W_4 || W_3 || W_2 || W_1 T = T || SReversed_i end for
// //バイト逆各チャンクを、そしてビルドアップI = 1のためのT // T = <空の文字列を> nにW_1ようにW_1、W_2、W_3、W_4はバイトとするん|| W_2 || W_3 || W_4 = S_I SReversed_i = W_4 || W_3 || W_2 || W_1 T = T ||以下のためのSReversed_i終了
Return T
戻り値T
Pseudorandom bits are needed internally by UHASH and at the time of tag generation. The functions listed in this section use a block cipher to generate these bits.
擬似ランダムビットはUHASHにより、タグの生成時に内部的に必要とされています。このセクションに記載されている機能は、これらのビットを生成するために、ブロック暗号を使用します。
UMAC uses the services of a block cipher. The selection of a block cipher defines the following constants and functions.
UMACは、ブロック暗号のサービスを使用しています。ブロック暗号の選択は、以下の定数と関数を定義しています。
BLOCKLEN The length, in bytes, of the plaintext block on which the block cipher operates.
BLOCKLENブロック暗号が動作する平文ブロックのバイト単位の長さ、、。
KEYLEN The block cipher's key length, in bytes.
KEYLENバイト単位のブロック暗号の鍵の長さ、。
ENCIPHER(K,P) The application of the block cipher on P (a string of BLOCKLEN bytes) using key K (a string of KEYLEN bytes).
キーK（KEYLENバイトの文字列）を使用してENCIPHER（K、P）P上のブロック暗号のアプリケーション（BLOCKLENバイトの文字列）。
As an example, if AES is used with 16-byte keys, then BLOCKLEN would equal 16 (because AES employs 16-byte blocks), KEYLEN would equal 16, and ENCIPHER would refer to the AES function.
AESは、16バイトのキーで使用される場合（AESは、16バイトのブロックを採用しているため）、一例として、次にBLOCKLENは16に等しくなる、KEYLENは16に等しくなり、そしてENCIPHERはAES機能を指すであろう。
Unless specified otherwise, AES with 128-bit keys shall be assumed to be the chosen block cipher for UMAC. Only if explicitly specified otherwise, and agreed to by communicating parties, shall some other block cipher be used. In any case, BLOCKLEN must be at least 16 and a power of two.
特に断りのない限り、128ビットキーでAESは、UMACのために選択されたブロック暗号であると仮定しなければなりません。明示的に指定し、通信相手によって同意する場合にのみ、他のいくつかのブロック暗号を使用しなければなりません。いずれの場合においても、BLOCKLENは、少なくとも16と2の累乗でなければなりません。
AES is defined in another document [1].
AESは、別のドキュメントで定義されている[1]。
The key-derivation function generates pseudorandom bits used to key the hash functions.
鍵導出関数は、ハッシュ関数をキー入力するために使用される擬似ランダムビットを生成します。
Input: K, string of length KEYLEN bytes. index, a non-negative integer less than 2^64. numbytes, a non-negative integer less than 2^64. Output: Y, string of length numbytes bytes.
入力：K、長さKEYLENバイトの文字列。指数、2 ^ 64未満の非負の整数。 NUMBYTES、2 ^ 64未満の非負の整数。出力：Y、長さNUMBYTESバイトの文字列。
Compute Y using the following algorithm.
次のアルゴリズムを使用してYを計算します。
// // Calculate number of block cipher iterations // n = ceil(numbytes / BLOCKLEN) Y = <empty string>
//ブロック暗号反復//の数を計算し、N = CEIL（NUMBYTES / BLOCKLEN）Y = <空の文字列>
// // Build Y using block cipher in a counter mode // for i = 1 to n do T = uint2str(index, BLOCKLEN-8) || uint2str(i, 8) T = ENCIPHER(K, T) Y = Y || T end for
//カウンタモード//でブロック暗号を使用してYを構築するためのi = 1からnまで行うT = uint2str（インデックス、BLOCKLEN-8）|| uint2str（I、8）T = ENCIPHER（K、T）Y = Y ||以下のためのT側
Y = Y[1...numbytes]
Y = Y [1 ... NUMBYTES]
Return Y
リターンY
This function takes a key and a nonce and returns a pseudorandom pad for use in tag generation. A pad of length 4, 8, 12, or 16 bytes can be generated. Notice that pads generated using nonces that differ only in their last bit (when generating 8-byte pads) or last two bits (when generating 4-byte pads) are derived from the same block cipher encryption. This allows caching and sharing a single block cipher invocation for sequential nonces.
この関数は、キー及びノンスを取り、タグ生成に使用するための擬似ランダムパッドを返します。長さ4、8、12、または16バイトのパッドを生成することができます。パッド又は最後の2ビット（4バイトパッドを生成する）（8バイトのパッドを生成する場合）、それらの最後のビットのみが異なるノンスを用いて生成された同じブロック暗号の暗号化に由来することに注意してください。これは、キャッシュとシーケンシャルナンスのための単一のブロック暗号の呼び出しを共有することができます。
Input: K, string of length KEYLEN bytes. Nonce, string of length 1 to BLOCKLEN bytes. taglen, the integer 4, 8, 12 or 16. Output: Y, string of length taglen bytes.
入力：K、長さKEYLENバイトの文字列。ナンス、BLOCKLENバイトの長さ1のストリング。 taglen、整数4、8、12又は16の出力：Y、長さtaglenバイトのストリング。
Compute Y using the following algorithm.
次のアルゴリズムを使用してYを計算します。
// // Extract and zero low bit(s) of Nonce if needed // if (taglen = 4 or taglen = 8) index = str2uint(Nonce) mod (BLOCKLEN/taglen) Nonce = Nonce xor uint2str(index, bytelength(Nonce)) end if
//必要に応じて、ノンスの低いビット（単数または複数）を抽出し、ゼロ// IF（taglen = 4またはtaglen = 8）指数= str2uint（ノンス）MOD（BLOCKLEN / taglen）ノンス=ノンスXOR uint2str（インデックス、バイト長（ノンス））END IF
// // Make Nonce BLOCKLEN bytes by appending zeroes if needed // Nonce = Nonce || zeroes(BLOCKLEN - bytelength(Nonce))
必要に応じて// //ゼロを付加することによって、ノンスBLOCKLENバイトを作る//ノンス=ナンス||ゼロ（BLOCKLEN - バイト長（ナンス））
// // Generate subkey, encipher and extract indexed substring // K' = KDF(K, 0, KEYLEN) T = ENCIPHER(K', Nonce) if (taglen = 4 or taglen = 8) Y = T[1 + (index*taglen) ... taglen + (index*taglen)] else Y = T[1...taglen] end if
// //、サブキーを生成ENCIPHER及び（taglen = 4またはtaglen = 8）Y = T場合、インデックス付きサブ// K '= KDF（K、0、KEYLEN）T = ENCIPHER（K'、ノンス）を抽出[1 + （指数* taglen）... taglen +（インデックス* taglen）]他Y = T [1 ... taglen] END IF
Return Y
リターンY
Tag generation for UMAC proceeds by using UHASH (defined in the next section) to hash the message, applying the PDF to the nonce, and computing the xor of the resulting strings. The length of the pad and hash can be either 4, 8, 12, or 16 bytes.
、メッセージをハッシュするUHASH（次のセクションで定義された）を用いてノンスにPDFを適用し、得られた文字列の排他的論理和を計算することによってUMAC進行の生成にタグを付けます。パッドとハッシュの長さは、いずれか4、8、12、又は16バイトとすることができます。
Input: K, string of length KEYLEN bytes. M, string of length less than 2^67 bits. Nonce, string of length 1 to BLOCKLEN bytes. taglen, the integer 4, 8, 12 or 16. Output: Tag, string of length taglen bytes.
入力：K、長さKEYLENバイトの文字列。 M、2 ^ 67ビット未満の長さの文字列。ナンス、BLOCKLENバイトの長さ1のストリング。 taglen、整数4、8、12または16出力：タグ、長さtaglenバイトのストリング。
Compute Tag using the following algorithm.
次のアルゴリズムを使用してタグを計算します。
HashedMessage = UHASH(K, M, taglen) Pad = PDF(K, Nonce, taglen) Tag = Pad xor HashedMessage
HashedMessage = UHASH（K、M、taglen）パッド= PDF（K、ノンス、taglen）タグ=パッドのXOR HashedMessage
Return Tag
リターンタグ
The preceding UMAC definition has a parameter "taglen", which specifies the length of tag generated by the algorithm. The following aliases define names that make tag length explicit in the name.
先行UMAC定義は、アルゴリズムによって生成されたタグの長さを指定するパラメータ「taglen」を有します。次の別名は、名前のタグの長さを明示的に名前を定義します。
UMAC-32(K, M, Nonce) = UMAC(K, M, Nonce, 4) UMAC-64(K, M, Nonce) = UMAC(K, M, Nonce, 8) UMAC-96(K, M, Nonce) = UMAC(K, M, Nonce, 12) UMAC-128(K, M, Nonce) = UMAC(K, M, Nonce, 16)
MAC-32（K、M、ノンス）= MAC（K、M、ノンス、4）MAC-64（K、M、ノンス）= MAC（K、M、ノンス、8）MAC-96（K、M、ノンス）= MAC（K、M、ナンス、12）MAC-128（K、M、ノンス）= MAC（K、M、ナンス、16）
UHASH is a keyed hash function, which takes as input a string of arbitrary length, and produces a 4-, 8-, 12-, or 16-byte output. UHASH does its work in three stages, or layers. A message is first hashed by L1-HASH, its output is then hashed by L2-HASH, whose output is then hashed by L3-HASH. If the message being hashed is no longer than 1024 bytes, then L2-HASH is skipped as an optimization. Because L3-HASH outputs a string whose length is only four bytes long, multiple iterations of this three-layer hash are used if a total hash-output longer than four bytes is requested. To reduce memory use, L1-HASH reuses most of its key material between iterations. A significant amount of internal key is required for UHASH, but it remains constant so long as UMAC's key is unchanged. It is the implementer's choice whether to generate the internal keys each time a message is hashed, or to cache them between messages.
UHASHは、入力として任意の長さの文字列を受け取り、および4-、8-、12-、または16バイトの出力を生成する鍵付きハッシュ関数です。 UHASHは3つの段階、または層でその作業を行います。メッセージが最初L1-HASHによってハッシュされ、その出力は、その後、その出力は、次いでL3-HASHによってハッシュさL2-HASHによってハッシュされます。ハッシュされたメッセージは、もはや1024バイト以下である場合には、L2-HASHは、最適化としてスキップされません。 L3-HASHは、その長さがわずか4バイトの長さの文字列を出力するので、より長い、4バイトより総ハッシュ出力が要求された場合、この三層ハッシュの複数の反復が使用されます。メモリ使用量を削減するために、L1-HASHは反復間の主要材料のほとんどを再利用します。内部キー、かなりの量がUHASHに必要ですが、それはあまりにも長い間UMACのキーが変更されないよう一定のまま。これは、内部のキーにメッセージがハッシュされるたびに発生する、またはメッセージの間でそれらをキャッシュするかどうかを実装の選択です。
Please note that UHASH has certain combinatoric properties making it suitable for Wegman-Carter message authentication. UHASH is not a cryptographic hash function and is not a suitable general replacement for functions like SHA-1.
UHASHがウェッグマン・カーターのメッセージ認証に適して一定のcombinatoric性質を持っていることに注意してください。 UHASHは暗号ハッシュ関数ではなく、SHA-1のように機能するのに適した一般的な置換ではありません。
UHASH is presented here in a top-down manner. First, UHASH is described, then each of its component hashes is presented.
UHASHは、トップダウン方式でここに示されています。まず、UHASHが記載され、そのコンポーネントのハッシュの各々が提示されます。
Input: K, string of length KEYLEN bytes. M, string of length less than 2^67 bits. taglen, the integer 4, 8, 12 or 16. Output: Y, string of length taglen bytes.
入力：K、長さKEYLENバイトの文字列。 M、2 ^ 67ビット未満の長さの文字列。 taglen、整数4、8、12又は16の出力：Y、長さtaglenバイトのストリング。
Compute Y using the following algorithm.
次のアルゴリズムを使用してYを計算します。
// // One internal iteration per 4 bytes of output // iters = taglen / 4
// //出力の4バイトごとに1回の内部反復// iters = taglen / 4
// // Define total key needed for all iterations using KDF. // L1Key reuses most key material between iterations. // L1Key = KDF(K, 1, 1024 + (iters - 1) * 16) L2Key = KDF(K, 2, iters * 24) L3Key1 = KDF(K, 3, iters * 64) L3Key2 = KDF(K, 4, iters * 4)
// // KDFを使用して、すべての反復のために必要な合計キーを定義します。 // L1Keyは反復間の最も重要な材料を再利用します。 // L1Key = KDF（K、1、1024 +（iters - 1）* 16）L2Key = KDF（K、2、iters * 24）L3Key1 = KDF（K、3、iters * 64）L3Key2 = KDF（K、 4、iters * 4）
// // For each iteration, extract key and do three-layer hash. // If bytelength(M) <= 1024, then skip L2-HASH. // Y = <empty string> for i = 1 to iters do L1Key_i = L1Key [(i-1) * 16 + 1 ... (i-1) * 16 + 1024] L2Key_i = L2Key [(i-1) * 24 + 1 ... i * 24] L3Key1_i = L3Key1[(i-1) * 64 + 1 ... i * 64]
// //各反復について、キー抽出し、三層ハッシュを行います。 //バイト長（M）<= 1024は、その後、L2-HASHをスキップした場合。 // Y = <空の文字列> I = 1のためのiters DO L1Key_i = L1Key [（I-1）* 16 + 1 ...（I-1）* 16 + 1024] L2Key_i = L2Key [（I-1）〜 * 24 + 1 ... iが* 24] L3Key1_i = L3Key1 [（I-1）* 64 + 1 ... iは×64】
L3Key2_i = L3Key2[(i-1) * 4 + 1 ... i * 4]
L3Key2_i = L3Key2 [（I-1）* 4 + 1 ...私は4 *]
A = L1-HASH(L1Key_i, M) if (bitlength(M) <= bitlength(L1Key_i)) then B = zeroes(8) || A else B = L2-HASH(L2Key_i, A) end if C = L3-HASH(L3Key1_i, L3Key2_i, B) Y = Y || C end for
= L1-HASH（L1Key_i、M）であれば（ビット長（M）<=ビット長（L1Key_i））、次いでB =ゼロ（8）||他のB = L2-HASH（L2Key_i、A）END IF C = L3-HASH（L3Key1_i、L3Key2_i、B）Y = Y ||以下のためのCの終了
Return Y
リターンY
The first-layer hash breaks the message into 1024-byte chunks and hashes each with a function called NH. Concatenating the results forms a string, which is up to 128 times shorter than the original.
第1層ハッシュは、1024バイトのチャンクにメッセージを分解し、NHと呼ばれる機能を、それぞれをハッシュ。結果を連結すると、元のより短い128倍までの文字列を形成します。
Input: K, string of length 1024 bytes. M, string of length less than 2^67 bits. Output: Y, string of length (8 * ceil(bitlength(M)/8192)) bytes.
入力：K、長さ1024バイトの文字列。 M、2 ^ 67ビット未満の長さの文字列。出力：Y、長さの文字列（8 * CEIL（ビット長（M）/ 8192））バイト。
Compute Y using the following algorithm.
次のアルゴリズムを使用してYを計算します。
// // Break M into 1024 byte chunks (final chunk may be shorter) // t = max(ceil(bitlength(M)/8192), 1) Let M_1, M_2, ..., M_t be strings so that M = M_1 || M_2 || ... || M_t, and bytelength(M_i) = 1024 for all 0 < i < t.
// //ブレークM 1024のバイトのチャンク（最終チャンクが短くなることがあり）//トン=最大に（はceil（ビット長（M）/ 8192）、1）MとなるようM_1、M_2は、...、文字列でM_tてみよう= M_1 || M_2 || ... || M_t、およびバイト長（M_I）= 1024全て0 <私は、Tを<
// // For each chunk, except the last: endian-adjust, NH hash // and add bit-length. Use results to build Y. // Len = uint2str(1024 * 8, 8) Y = <empty string> for i = 1 to t-1 do ENDIAN-SWAP(M_i) Y = Y || (NH(K, M_i) +_64 Len) end for
// //それぞれの最後を除くチャンクについて：エンディアン調整し、NHハッシュ//とビット長を追加します。 Y. //レンを構築するために、結果を使用します= T-1にuint2str（1024×8、8）は、i = 1 Y = <空の文字列>エンディアンSWAP（M_I）Y = Yを行う|| （NH（K、M_I）+ _64 LEN）終了の
// // For the last chunk: pad to 32-byte boundary, endian-adjust, // NH hash and add bit-length. Concatenate the result to Y. // Len = uint2str(bitlength(M_t), 8) M_t = zeropad(M_t, 32) ENDIAN-SWAP(M_t) Y = Y || (NH(K, M_t) +_64 Len)
// //最後のチャンクの場合：32バイト境界にパッド、エンディアンに調整し、// NHハッシュとビット長を追加します。 Yに結果を連結//レン= uint2str（ビット長（M_t）、8）M_t = ZEROPAD（M_t、32）エンディアンSWAP（M_t）Y = Y || （NH（K、M_t）+ _64 LEN）
return Y
そしてリターン
Because this routine is applied directly to every bit of input data, optimized implementation of it yields great benefit.
このルーチンは、入力データのすべてのビットに直接適用されているので、それの最適化された実装は、大きなメリットが得られます。
Input: K, string of length 1024 bytes. M, string with length divisible by 32 bytes. Output: Y, string of length 8 bytes.
入力：K、長さ1024バイトの文字列。 M、32バイトで割り切れる長さのストリング。出力：Y、長さ8バイトの文字列。
Compute Y using the following algorithm.
次のアルゴリズムを使用してYを計算します。
// // Break M and K into 4-byte chunks // t = bytelength(M) / 4 Let M_1, M_2, ..., M_t be 4-byte strings so that M = M_1 || M_2 || ... || M_t. Let K_1, K_2, ..., K_t be 4-byte strings so that K_1 || K_2 || ... || K_t is a prefix of K.
M = M_1ように//ブレークMとK 4バイトのチャンクに//トン=バイト長（M）/ 4レッツM_1、M_2、...、4バイトの文字列でM_t || M_2 || ... || M_t。 K_1ようK_1、K_2は、...、K_Tは4バイトの文字列とする|| K_2 || ... || K_Tは、Kの接頭辞であります
// // Perform NH hash on the chunks, pairing words for multiplication // which are 4 apart to accommodate vector-parallelism. // Y = zeroes(8) i = 1 while (i < t) do Y = Y +_64 ((M_{i+0} +_32 K_{i+0}) *_64 (M_{i+4} +_32 K_{i+4})) Y = Y +_64 ((M_{i+1} +_32 K_{i+1}) *_64 (M_{i+5} +_32 K_{i+5})) Y = Y +_64 ((M_{i+2} +_32 K_{i+2}) *_64 (M_{i+6} +_32 K_{i+6})) Y = Y +_64 ((M_{i+3} +_32 K_{i+3}) *_64 (M_{i+7} +_32 K_{i+7})) i = i + 8 end while
// //はベクトル並列に対応するために離れ4は乗算//した単語をペア、チャンクにNHハッシュを実行します。 // Y =ゼロ（8）は、i = 1つの一方（iはTを<）行うY = Y + _64（（M_ {I + 0} + _32 K_ {I + 0}）* _64（M_ {I + 4} + _32 K_ {I + 4}））Y = Y + _64（（M_ {I + 1} + _32 K_ {I + 1}）* _64（M_ {I + 5} + _32 K_ {I + 5}）） Y = Y + _64（（M_ {I + 2} + _32 K_ {I + 2}）* _64（M_ {I + 6} + _32 K_ {I + 6}））Y = Y + _64（（M_ { I + 3} + _32 K_ {I + 3}）* _64（M_ {I + 7} + _32 K_ {I + 7}））I = I + 8端一方
Return Y
リターンY
The second-layer rehashes the L1-HASH output using a polynomial hash called POLY. If the L1-HASH output is long, then POLY is called once on a prefix of the L1-HASH output and called using different settings on the remainder. (This two-step hashing of the L1-HASH output is needed only if the message length is greater than 16 megabytes.) Careful implementation of POLY is necessary to avoid a possible timing attack (see Section 6.6 for more information).
第二層は、ポリ呼ばれる多項式ハッシュを使用してL1-HASH出力をリハッシュ。 L1-HASH出力が長い場合は、POLYは、L1-HASH出力のプレフィックスに一度呼び出され、残りの部分に異なる設定を使用して呼び出されます。 （L1-HASH出力のこの2段階のハッシュは、メッセージの長さが16メガバイトよりも大きい場合にのみ必要とされている。）POLYの注意深い実装が可能なタイミング攻撃を回避する必要がある（詳細はセクション6.6を参照）。
Input: K, string of length 24 bytes. M, string of length less than 2^64 bytes. Output: Y, string of length 16 bytes.
入力：K、長さ24バイトのストリング。 M、2 ^ 64バイト未満の長さのストリング。出力：Y、長さ16バイトの文字列。
Compute y using the following algorithm.
次のアルゴリズムを使用してYを計算します。
// // Extract keys and restrict to special key-sets // Mask64 = uint2str(0x01ffffff01ffffff, 8) Mask128 = uint2str(0x01ffffff01ffffff01ffffff01ffffff, 16) k64 = str2uint(K[1...8] and Mask64) k128 = str2uint(K[9...24] and Mask128)
//キーを抽出し、特殊キーセットに制限// Mask64 = uint2str（0x01ffffff01ffffff、8）Mask128 = uint2str（0x01ffffff01ffffff01ffffff01ffffff、16）K64 = str2uint（K [1 ... 8]とMask64）k128 = str2uint（ K [9 ... 24]とMask128）
// // If M is no more than 2^17 bytes, hash under 64-bit prime, // otherwise, hash first 2^17 bytes under 64-bit prime and // remainder under 128-bit prime. // if (bytelength(M) <= 2^17) then // 2^14 64-bit words
// // Mはもはや17 ^ 2よりバイト、64ビットの素数下ハッシュである場合、//そうでない場合は、128ビットの素数の下で64ビットの素数と//残りの下の最初の2 ^ 17バイトをハッシュ。 //（バイト長（M）<= 2 ^ 17）場合、// 2 ^ 14の64ビット・ワード
// // View M as an array of 64-bit words, and use POLY modulo // prime(64) (and with bound 2^64 - 2^32) to hash it. // y = POLY(64, 2^64 - 2^32, k64, M) else M_1 = M[1...2^17] M_2 = M[2^17 + 1 ... bytelength(M)] M_2 = zeropad(M_2 || uint2str(0x80,1), 16) y = POLY(64, 2^64 - 2^32, k64, M_1) y = POLY(128, 2^128 - 2^96, k128, uint2str(y, 16) || M_2) end if
//ビューM 64ビットワードのアレイとして、および（2 ^ 64バウンドと - 2 ^ 32）プライムPOLYモジュロ//（64）を使用し、それをハッシュします。 // Y = POLY（64、2 ^ 64から2 ^ 32、K64、M）他M_1 = M [1 ... 2 ^ 17] M_2 = M [2 ^ 17 + 1 ...バイト長（M）] M_2 = ZEROPAD（M_2 || uint2str（0x80,1）、16）Y = POLY（64、2 ^ 64から2 ^ 32、K64、M_1）Y = POLY（128、2 ^ 128から2 ^ 96、k128、 uint2str（Y、16）|| M_2）END IF
Y = uint2str(y, 16)
Y = uint2str（16）
Return Y
リターンY
Input: wordbits, the integer 64 or 128. maxwordrange, positive integer less than 2^wordbits. k, integer in the range 0 ... prime(wordbits) - 1. M, string with length divisible by (wordbits / 8) bytes. Output: y, integer in the range 0 ... prime(wordbits) - 1.
入力：wordbits、整数64または128 maxwordrange、2 ^ wordbits未満の正の整数。 K、範囲0の整数...プライム（wordbits） - 1 M、（wordbits / 8）で割り切れる長さの文字列はバイト。出力：Y、範囲0の整数...プライム（wordbits） - 1。
Compute y using the following algorithm.
次のアルゴリズムを使用してYを計算します。
// // Define constants used for fixing out-of-range words // wordbytes = wordbits / 8 p = prime(wordbits) offset = 2^wordbits - p marker = p - 1
// //範囲外の単語// wordbytes = wordbitsオフセット/ 8、P =プライム（wordbits）= 2 ^ wordbits固定するために使用される定数の定義 - Pマーカー= Pを - 1
// // Break M into chunks of length wordbytes bytes // n = bytelength(M) / wordbytes Let M_1, M_2, ..., M_n be strings of length wordbytes bytes so that M = M_1 || M_2 || ... || M_n
長さのチャンクに//ブレイクM wordbytesバイト// N =バイト長（M）/ wordbytesはM_1、M_2、...、M_nは長さの文字列では、M = M_1ようバイトをwordbytesう|| M_2 || ... || M_n
// // Each input word m is compared with maxwordrange. If not smaller // then 'marker' and (m - offset), both in range, are hashed. // y = 1 for i = 1 to n do m = str2uint(M_i) if (m >= maxwordrange) then y = (k * y + marker) mod p y = (k * y + (m - offset)) mod p else y = (k * y + m) mod p end if end for
// //各入力ワードmはmaxwordrangeと比較されます。 //次に、「マーカー」と（M - オフセット）されない場合より小さく、範囲の両方で、ハッシュされます。 I = 1 // y = 1でN DO M = str2uint（M_I）であれば（M> = maxwordrange）をY =（K *のY +マーカー）MOD PY =（k個*のY軸+（M - オフセット））にMOD他P Y =（k個*のY + M）MOD p個の端END IF用
Return y
戻ると、
The output from L2-HASH is 16 bytes long. This final hash function hashes the 16-byte string to a fixed length of 4 bytes.
L2-HASHからの出力は、16バイト長です。この最終的なハッシュ関数は、4バイトの固定長に16バイトの文字列をハッシュ。
Input: K1, string of length 64 bytes. K2, string of length 4 bytes. M, string of length 16 bytes. Output: Y, string of length 4 bytes.
入力：K1、長さ64バイトの文字列。 K2、長さが4バイトのストリング。 M、長さ16バイトのストリング。出力：Y、長さが4バイトの文字列。
Compute Y using the following algorithm.
次のアルゴリズムを使用してYを計算します。
y = 0
Y = 0
// // Break M and K1 into 8 chunks and convert to integers // for i = 1 to 8 do M_i = M [(i - 1) * 2 + 1 ... i * 2] K_i = K1[(i - 1) * 8 + 1 ... i * 8] m_i = str2uint(M_i) k_i = str2uint(K_i) mod prime(36) end for
// //ブレークMとK1 8つの塊にし、I = 1 M_I = M [（I - 1）* 2 + 1 ... i *が2〕やる〜8のための整数//に変換K_I = K1 [（I - 1）* 8 + 1 ... i *が8] M_I = str2uint（M_I）K_I = str2uint（K_I）MODプライム（36）の端部のための
// // Inner-product hash, extract last 32 bits and affine-translate // y = (m_1 * k_1 + ... + m_8 * k_8) mod prime(36) y = y mod 2^32 Y = uint2str(y, 4) Y = Y xor K2
// //内積ハッシュ、最後の32ビットとアフィン変換// Y =（M_1 * K_1 + ... + m_8 * k_8）MODプライム（36）Y = Y MOD 2 ^ 32 = Y uint2strを（抽出Y 4）Y = Yの排他的論理和K2
Return Y
リターンY
As a message authentication code specification, this entire document is about security. Here we describe some security considerations important for the proper understanding and use of UMAC.
メッセージ認証コードの仕様としては、この文書全体では、セキュリティに関するものです。ここでは、UMACの正しい理解と使用のための重要ないくつかのセキュリティ上の考慮事項について説明します。
The strength of UMAC depends on the strength of its underlying cryptographic functions: the key-derivation function (KDF) and the pad-derivation function (PDF). In this specification, both operations are implemented using a block cipher, by default the Advanced Encryption Standard (AES). However, the design of UMAC allows for the replacement of these components. Indeed, it is possible to use other block ciphers or other cryptographic objects, such as (properly keyed) SHA-1 or HMAC for the realization of the KDF or PDF.
キー派生関数（KDF）とパッド派生関数（PDF）：UMACの強さは、その基礎となる暗号機能の強さに依存します。本明細書では、両方の操作は、デフォルトで、ブロック暗号を使用して実装されている高度暗号化標準（AES）。しかし、UMACのデザインは、これらの部品の交換が可能になります。実際、KDF又はPDFの実現のために、このような（適切にキー止め）などの他のブロック暗号または他の暗号化オブジェクト、SHA-1またはHMACを使用することが可能です。
The core of the UMAC design, the UHASH function, does not depend on cryptographic assumptions: its strength is specified by a purely mathematical property stated in terms of collision probability, and this property is proven unconditionally [3, 6]. This means the strength of UHASH is guaranteed regardless of advances in cryptanalysis.
UMAC設計、UHASH関数のコアは、暗号化の仮定に依存しない：その強度は、衝突確率の観点で述べ純粋に数学的なプロパティで指定され、このプロパティは無条件に証明されている[3,6]。これはUHASHの強さに関係なく、暗号解読の進歩の保証されていることを意味します。
The analysis of UMAC [3, 6] shows this scheme to have provable security, in the sense of modern cryptography, by way of tight reductions. What this means is that an adversarial attack on UMAC that forges with probability that significantly exceeds the established collision probability of UHASH will give rise to an attack of comparable complexity. This attack will break the block cipher, in the sense of distinguishing the block cipher from a family of random permutations. This design approach essentially obviates the need for cryptanalysis on UMAC: cryptanalytic efforts might as well focus on the block cipher, the results imply.
UMAC [3、6]の分析は、タイトな削減の方法により、現代暗号の意味で、証明可能安全性を持っているために、このスキームを示します。これが意味することはかなりUHASHの確立衝突確率を超える確率で偽造UMACに敵対攻撃は同等の複雑さの攻撃に上昇を与えることです。この攻撃は、ランダムな順列の家族からブロック暗号を区別する意味で、ブロック暗号を破るます。この設計アプローチは、本質的にUMAC上の暗号解読のための必要性を取り除く：暗号解読の努力は、同様の結果が意味するものでは、ブロック暗号に焦点を当てることがあります。
A MAC algorithm is used to authenticate messages between two parties that share a secret MAC key K. An authentication tag is computed for a message using K and, in some MAC algorithms such as UMAC, a nonce. Messages transmitted between parties are accompanied by their tag and, possibly, nonce. Breaking the MAC means that the attacker is able to generate, on its own, with no knowledge of the key K, a new message M (i.e., one not previously transmitted between the legitimate parties) and to compute on M a correct authentication tag under the key K. This is called a forgery. Note that if the authentication tag is specified to be of length t, then the attacker can trivially break the MAC with probability 1/2^t. For this, the attacker can just generate any message of its choice and try a random tag; obviously, the tag is correct with probability 1/2^t. By repeated guesses, the attacker can increase linearly its probability of success.
MACアルゴリズムは、認証タグがKを使用してメッセージを計算し、そのようなUMAC、ノンスなどのいくつかのMACアルゴリズムであり、秘密MAC鍵Kを共有する2つの当事者の間でメッセージを認証するために使用されます。当事者間で送信されたメッセージは、そのタグと、おそらく、ナンスを伴っています。 MACを破ることは、攻撃者は鍵Kの知識と、それ自体で、生成することができることを意味する新たなメッセージM（すなわち、1つ先に正当な当事者間で伝送されていない）と下Mに正しい認証タグを計算しますキーK.これは偽造と呼ばれています。認証タグが長さTであると指定されている場合、攻撃者は自明確率/ 2 ^ TでMACを破ることができることに留意されたいです。このため、攻撃者は、ちょうどその選択した任意のメッセージを生成し、ランダムなタグを試すことができます。明らかに、タグは、確率/ 2 ^ Tで正確です。繰り返し推測することにより、攻撃者は、直線的な成功のその確率を高めることができます。
In the case of UMAC-64, for example, the above guessing-attack strategy is close to optimal. An adversary can correctly guess an 8-byte UMAC tag with probability 1/2^64 by simply guessing a random value. The results of [3, 6] show that no attack strategy can produce a correct tag with probability better than 1/2^60 if UMAC were to use a random function in its work rather than AES. Another result [2], when combined with [3, 6], shows that so long as AES is secure as a pseudorandom permutation, it can be used instead of a random function without significantly increasing the 1/2^60 forging probability, assuming that no more than 2^64 messages are authenticated. Likewise, 32-, 96-, and 128-bit tags cannot be forged with more than 1/2^30, 1/2^90, and 1/2^120 probability plus the probability of a successful attack against AES as a pseudorandom permutation.
UMAC-64の場合には、例えば、上記推測攻撃戦略は、最適に近いです。敵は正しく、単にランダムな値を推測することにより、確率は1月2日^ 64で8バイトUMACタグを推測することができます。 [3]、[6]の結果は、UMACはなくAESよりもその作業にランダム関数を使用した場合全く攻撃戦略は60 ^ 1/2よりもより良い確率で正しいタグを生成することができないことを示しています。組み合わせた場合に別の結果は、[2]、[3]、[6]、と仮定すると、限りAESは、擬似ランダム順列として安全であるように、それは有意/ 2 ^ 60鍛造確率を増加させることなく、ランダム関数の代わりに使用することができることを示していますこれ以上の64 ^ 2以上のメッセージが認証されていること。 120確率プラス擬似乱数としてAESに対する攻撃が成功する確率も同様に、32、96、および128ビットのタグが複数の1/2を偽造することはできない^ 30 1/2 ^ 90、1/2 ^順列。
AES has undergone extensive study and is assumed to be very secure as a pseudorandom permutation. If we assume that no attacker with feasible computational power can distinguish randomly-keyed AES from a randomly-chosen permutation with probability delta (more precisely, delta is a function of the computational resources of the attacker and of its ability to sample the function), then we obtain that no such attacker can forge UMAC with probability greater than 1/2^30, 1/^60, 1/2^90, or 1/2^120, plus 3*delta. Over N forgery attempts, forgery occurs with probability no more than N/2^30, N/^60, N/2^90, or N/2^120, plus 3*delta. The value delta may exceed 1/2^30, 1/2^60, 1/2^90, or 1/2^120, in which case the probability of UMAC forging is dominated by a term representing the security of AES.
AESは、広範囲な研究が行われたと擬似ランダム置換として非常に安全であると仮定されます。我々は可能な計算能力とは、攻撃者が確率デルタでランダムに選ばれた順列からランダムにキー付きAESを区別することはできないと仮定した場合（より正確には、デルタは、攻撃者の機能をサンプリングする能力の計算リソースの関数です）、我々はそのような攻撃者は90 ^ 1/2、30 ^ 1/2よりも1 / ^ 60より大きい確率、又は1/2 ^ 120、プラス3 *デルタとUMACを偽造できないことを得ます。 N偽造の試み上、偽造は、N / 2 ^ 30、N / ^ 60、N / 2 ^ 90、又はN / 2 ^ 120、プラス3 *デルタを超えない確率で起こります。値デルタは、UMAC鍛造の確率は、AESのセキュリティを表す用語によって支配されている場合には/ 2 ^ 30 1/2 ^ 60 1/2 ^ 90、1/2 ^ 120を超えてもよいです。
With UMAC, off-line computation aimed at exceeding the forging probability is hopeless as long as the underlying cipher is not broken. An attacker attempting to forge UMAC tags will need to interact with the entity that verifies message tags and try a large number of forgeries before one is likely to succeed. The system architecture will determine the extent to which this is possible. In a well-architected system, there should not be any high-bandwidth capability for presenting forged MACs and determining if they are valid. In particular, the number of authentication failures at the verifying party should be limited. If a large number of such attempts are detected, the session key in use should be dropped and the event be recorded in an audit log.
鍛造確率を超えを目指しUMAC、オフラインの計算である限り基本となる暗号が破られていないと絶望的です。 UMACタグを偽造しようとする攻撃者は、メッセージタグを検証するエンティティと対話し、1が成功する可能性がある前に、偽造の多数を試みる必要があります。システムアーキテクチャは、これが可能である程度を決定します。よく設計さシステムでは、偽造MACを提示し、それらが有効であるかどうかを決定するための任意の高帯域幅能力があってはなりません。特に、検証パーティでの認証失敗回数を制限する必要があります。そのような試みが多数検出された場合、使用中のセッション鍵は廃棄されるべきであり、イベントは、監査ログに記録されます。
Let us reemphasize: a forging probability of 1/2^60 does not mean that there is an attack that runs in 2^60 time; to the contrary, as long as the block cipher in use is not broken there is no such attack for UMAC. Instead, a 1/2^60 forging probability means that if an attacker could have N forgery attempts, then the attacker would have no more than N/2^60 probability of getting one or more of them right.
私たちは再び強調してみましょう：1月2日^ 60の鍛造確率は2 ^ 60時間で実行される攻撃が存在することを意味するものではありません。逆に、限り、使用中のブロック暗号が破られていないようUMACには、このような攻撃はありません。その代わり、1月2日^ 60鍛造確率は、攻撃者がN偽造の試みを持っていることができれば、その後、攻撃者はそれらの1つ以上の権利を得るためのN / 2 ^ 60確率よりも多くを持っていないことを意味します。
It should be pointed out that once an attempted forgery is successful, it is possible, in principle, that subsequent messages under this key may be easily forged. This is important to understand in gauging the severity of a successful forgery, even though no such attack on UMAC is known to date.
未遂偽造が成功したら、それはこのキーの下に、後続のメッセージを簡単に偽造できることを、原則的に、可能であることを指摘しなければなりません。これは、UMACにそのような攻撃は、これまでに知られていないにも関わらず、成功した偽造の重症度を測るに理解することが重要です。
In conclusion, 64-bit tags seem appropriate for many security architectures and commercial applications. If one wants a more conservative option, at a cost of about 50% or 100% more computation, UMAC can produce 96- or 128-bit tags that have basic collision probabilities of at most 1/2^90 and 1/2^120. If one needs less security, with the benefit of about 50% less computation, UMAC can produce 32-bit tags. In this case, under the same assumptions as before, one cannot forge a message with probability better than 1/2^30. Special care must be taken when using 32-bit tags because 1/2^30 forgery probability is considered fairly high. Still, high-speed low-security authentication can be applied usefully on low-value data or rapidly-changing key environments.
結論として、64ビットのタグは、多くのセキュリティアーキテクチャや商用アプリケーションに適しているようです。一つは約50％または100％以上の計算コストで、より保守的なオプションを望む場合、UMACは、最も/ 2 ^ 90と1/2 ^ 120の基本的な衝突確率を有する96または128ビットのタグを生成することができます。一つは約50％以下の計算の利点と、より少ないセキュリティを必要とする場合、UMACは、32ビットのタグを生成することができます。この場合には、前と同じ仮定の下で、1は、1/2 ^ 30よりも良好な確率でメッセージを偽造することができません。 1月2日^ 30偽造確率はかなり高いと考えられるので、32ビットのタグを使用した場合には、特別な注意が必要。依然として、高速低セキュリティ認証は、低値データまたはキーの環境を急速に変化させることに有用に適用することができます。
UMAC requires a nonce with length in the range 1 to BLOCKLEN bytes. All nonces in an authentication session must be equal in length. For secure operation, no nonce value should be repeated within the life of a single UMAC session key. There is no guarantee of message authenticity when a nonce is repeated, and so messages accompanied by a repeated nonce should be considered inauthentic.
UMACはBLOCKLENバイトの範囲1の長さを持つnonceを必要とします。認証セッションのすべてのナンスの長さは同じでなければなりません。安全な運転のために、何のナンス値は、単一のUMACセッションキーのライフ内で繰り返されてはなりません。 nonceが繰り返され、その繰り返しナンスを伴うメッセージが本物でないと考えるべきであると、メッセージの真正性の保証はありません。
To authenticate messages over a duplex channel (where two parties send messages to each other), a different key could be used for each direction. If the same key is used in both directions, then it is crucial that all nonces be distinct. For example, one party can use even nonces while the other party uses odd ones. The receiving party must verify that the sender is using a nonce of the correct form.
（両当事者が相互にメッセージを送信する）二重チャネルを介してメッセージを認証するために、異なる鍵が各方向に使用することができます。同じキーが両方向で使用されている場合、すべてのナンスが明瞭であることが重要です。相手が奇数のものを使用しながら、例えば、一方の当事者でもナンスを使用することができます。受信側は送信者が正しい形式のナンスを使用していることを確認する必要があります。
This specification does not indicate how nonce values are created, updated, or communicated between the entity producing a tag and the entity verifying a tag. The following are possibilities:
この仕様は、作成、更新、またはタグを検証し、タグや実体を生成するエンティティ間で通信する方法を一回だけの値を示すものではありません。可能性は以下のとおりです。
1. The nonce is an 8-byte unsigned number, Counter, which is initialized to zero, which is incremented by one following the generation of each authentication tag, and which is always communicated along with the message and the authentication tag. An error occurs at the sender if there is an attempt to authenticate more than 2^64 messages within a session.
1. nonceが8バイトの符号なし数であり、各認証タグの生成以下の1つインクリメントし、かつ常にメッセージと認証タグと共に通信されるゼロに初期化されるカウンタ、、。セッション内でより2 ^ 64メッセージを認証しようとする試みがある場合は、エラーは、送信側で発生します。
2. The nonce is a BLOCKLEN-byte unsigned number, Counter, which is initialized to zero and which is incremented by one following the generation of each authentication tag. The Counter is not explicitly communicated between the sender and receiver. Instead, the two are assumed to communicate over a reliable transport, and each maintains its own counter so as to keep track of what the current nonce value is.
2.ナンスがゼロに初期化され、各認証タグの生成以下インクリメントされBLOCKLENバイトの符号なし数カウンタです。カウンタは、明示的に送信者と受信者との間で通信されていません。その代わりに、両者は信頼性の高いトランスポートを介して通信すると仮定し、現在のノンス値が何であるかを追跡するように、それぞれが独自のカウンタを維持しています。
3. The nonce is a BLOCKLEN-byte random value. (Because repetitions in a random n-bit value are expected at around 2^(n/2) trials, the number of messages to be communicated in a session using n-bit nonces should not be allowed to approach 2^(n/2).)
3.ナンスはBLOCKLENバイトのランダムな値です。ランダムなnビット値の繰り返しが約2 ^（N / 2）試験で期待されているので（nビットのノンスを用いて、セッション中に通信されるメッセージの数は、2 ^（N / 2に接近させるべきではありません）。）
We emphasize that the value of the nonce need not be kept secret.
私たちは、ナンスの値は秘密にされる必要がないことを強調します。
When UMAC is used within a higher-level protocol, there may already be a field, such as a sequence number, which can be co-opted so as to specify the nonce needed by UMAC [5]. The application will then specify how to construct the nonce from this already-existing field.
UMACは、より高いレベルのプロトコル内で使用される場合、既にそのようなUMACによって必要とされるnonceを指定するように共オプトインすることができるシーケンス番号などのフィールドが存在することができる[5]。次に、アプリケーションは、この既存のフィールドからナンスを構築する方法を指定します。
A replay attack entails the attacker repeating a message, nonce, and authentication tag. In many applications, replay attacks may be quite damaging and must be prevented. In UMAC, this would normally be done at the receiver by having the receiver check that no nonce value is used twice. On a reliable connection, when the nonce is a counter, this is trivial. On an unreliable connection, when the nonce is a counter, one would normally cache some window of recent nonces. Out-of-order message delivery in excess of what the window allows will result in rejecting otherwise valid authentication tags. We emphasize that it is up to the receiver when a given (message, nonce, tag) triple will be deemed authentic. Certainly, the tag should be valid for the message and nonce, as determined by UMAC, but the message may still be deemed inauthentic because the nonce is detected to be a replay.
リプレイ攻撃は、メッセージ、ナンス、および認証タグを繰り返し攻撃を伴います。多くのアプリケーションでは、リプレイ攻撃は非常に有害であってよく、防止しなければなりません。 UMACでは、これは通常何のノンス値が2回使用されていないことを受信チェックを有することによって、受信機で行われるであろう。ナンスはカウンターがあるときに信頼性の高い接続では、これは簡単です。ナンスはカウンターがあるときに信頼できない接続では、1は通常、最近の一回だけのいくつかのウィンドウをキャッシュします。アウトオブオーダーウィンドウができます何を超えたメッセージの配信は、そうでない場合は、有効な認証タグを拒否になります。我々は、与えられた（メッセージ、ノンス、タグ）が三重真正とみなされる場合、それは受信機までであることを強調する。確かに、タグは、UMACによって決定されるが、一回だけを再生することが検出されるので、メッセージが本物でないとみなされてもよいように、メッセージおよびノンスのために有効であるべきです。
UMAC's definition makes it possible to implement tag-prefix verification; for example, a receiver might verify only the 32-bit prefix of a 64-bit tag if its computational load is high. Or a receiver might reject out-of-hand a 64-bit tag whose 32-bit prefix is incorrect. Such practices are potentially dangerous and can lead to attacks that reduce the security of the session to the length of the verified prefix. A UMAC key (or session) must have an associated and immutable tag length and the implementation should not leak information that would reveal if a given proper prefix of a tag is valid or invalid.
UMACの定義は、タグプレフィックスの検証を実施することが可能となります。その計算負荷が高い場合、例えば、受信機は、64ビットのタグの唯一の32ビットのプレフィックスを検証するかもしれません。あるいは、受信機は外の手を持つ32ビットのプレフィックス間違っている64ビットのタグを拒否することがあります。このような慣行は、潜在的に危険であると確認され、プレフィックスの長さにセッションのセキュリティを減らす攻撃につながることができます。 UMACキー（またはセッション）を関連付けて不変タグの長さを有する必要があり、実装は、タグの与えられた適切なプレフィックスが有効であるか無効である場合に明らかであろう情報を漏洩しないはずです。
Side-channel attacks have the goal of subverting the security of a cryptographic system by exploiting its implementation characteristics. One common side-channel attack is to measure system response time and derive information regarding conditions met by the data being processed. Such attacks are known as "timing attacks". Discussion of timing and other side-channel attacks is outside of this document's scope. However, we warn that there are places in the UMAC algorithm where timing information could be unintentionally leaked. In particular, the POLY algorithm (Section 5.3.2) tests whether a value m is out of a particular range, and the behavior of the algorithm differs depending on the result. If timing attacks are to be avoided, care should be taken to equalize the computation time in both cases. Timing attacks can also occur for more subtle reasons, including caching effects.
サイドチャネル攻撃は、その実装の特性を利用して暗号システムのセキュリティを破壊するという目標を持っています。一つの一般的なサイドチャネル攻撃、システムの応答時間を測定し、処理中のデータが満たす条件についての情報を得ることです。このような攻撃は「タイミング攻撃」として知られています。タイミングやその他のサイドチャネル攻撃の議論は、この文書の範囲外です。しかし、我々はタイミング情報が意図せずに漏洩する可能性がUMACアルゴリズムで場所があることを警告しています。具体的には、値mは、特定の範囲外POLYアルゴリズム（セクション5.3.2）のテストであるかどうか、およびアルゴリズムの動作は、結果に応じて異なります。タイミング攻撃は避けなければならない場合は、注意がどちらの場合も、計算時間を等しくするために取られるべきです。タイミング攻撃も、キャッシングの効果を含むより微妙な理由で発生する可能性があります。
David McGrew and Scott Fluhrer, of Cisco Systems, played a significant role in improving UMAC by encouraging us to pay more attention to the performance of short messages. Thanks go to Jim Schaad and to those who made helpful suggestions to the CFRG mailing list for improving this document during RFC consideration. Black, Krovetz, and Rogaway have received support for this work under NSF awards 0208842, 0240000, and 9624560, and a gift from Cisco Systems.
シスコシステムズのデビッド・マグリューとスコットFluhrerは、ショートメッセージのパフォーマンスにもっと注意を払うために私たちを奨励することによってUMACの改善に重要な役割を果たしました。おかげでジムSchaadにし、RFCの検討の際に、このドキュメントを改善するためのCFRGメーリングリストに役立つ提案をした人に行きます。ブラック、Krovetz、とRogawayは、NSF賞0208842、024万、および9624560、およびシスコシステムズからの贈り物の下で、この作品のためのサポートを受けています。
Appendix. Test Vectors
付録。テストベクトル
Following are some sample UMAC outputs over a collection of input values, using AES with 16-byte keys. Let
以下の16バイトの鍵とAESを使用して、入力値の集合の上にいくつかのサンプルUMAC出力です。してみましょう
K = "abcdefghijklmnop" // A 16-byte UMAC key N = "bcdefghi" // An 8-byte nonce
K = "abcdefghijklmnop" // 16バイトUMACキーN = "bcdefghi" // 8バイトノンス
The tags generated by UMAC using key K and nonce N are:
キーKとナンスNを使用してUMACによって生成されたタグは以下のとおりです。
Message 32-bit Tag 64-bit Tag 96-bit Tag
------- ---------- ---------- ----------
<empty> 113145FB 6E155FAD26900BE1 32FEDB100C79AD58F07FF764
'a' * 3 3B91D102 44B5CB542F220104 185E4FE905CBA7BD85E4C2DC
'a' * 2^10 599B350B 26BF2F5D60118BD9 7A54ABE04AF82D60FB298C3C
'a' * 2^15 58DCF532 27F8EF643B0D118D 7B136BD911E4B734286EF2BE
'a' * 2^20 DB6364D1 A4477E87E9F55853 F8ACFA3AC31CFEEA047F7B11
'a' * 2^25 5109A660 2E2DBC36860A0A5F 72C6388BACE3ACE6FBF062D9
'abc' * 1 ABF3A3A0 D4D7B9F6BD4FBFCF 883C3D4B97A61976FFCF2323
'abc' * 500 ABEB3C8B D4CF26DDEFD5C01A 8824A260C53C66A36C9260A6
The first column lists a small sample of messages that are strings of repeated ASCII 'a' bytes or 'abc' strings. The remaining columns give in hexadecimal the tags generated when UMAC is called with the corresponding message, nonce N and key K.
最初の列を繰り返しASCIIの文字列「」バイトまたは「ABC」文字列であるメッセージの小さなサンプルを示しています。 UMACは、対応するメッセージ、ノンスN及び鍵Kを用いて呼び出されたときに残りの列は、タグが生成された進数で与えます
When using key K and producing a 64-bit tag, the following relevant keys are generated:
鍵Kを使用し、64ビットのタグを製造する場合、次の関連するキーが生成されます。
Iteration 1 Iteration 2
----------- -----------
NH (Section 5.2.2)
K_1 ACD79B4F C6DFECA2 K_2 6EDA0D0E 964A710D K_3 1625B603 AD7EDE4D K_4 84F9FC93 A1D3935E K_5 C6DFECA2 62EC8672 ... K_256 0BF0F56C 744C294F
K_1 ACD79B4F C6DFECA2 K_2 6EDA0D0E 964A710D K_3 1625B603 AD7EDE4D K_4 84F9FC93 A1D3935E K_5 C6DFECA2 62EC8672 ... K_256 0BF0F56C 744C294F
L2-HASH (Section 5.3.1)
L2-HASH（5.3.1項）
k64 0094B8DD0137BEF8 01036F4D000E7E72
K64 0094B8DD0137BEF8 01036F4D000E7E72
L3-HASH (Section 5.4.1)
L3-HASH（セクション5.4.1）
k_5 056533C3A8 0504BF4D4E k_6 07591E062E 0126E922FF k_7 0C2D30F89D 030C0399E2 k_8 046786437C 04C1CB8FED K2 2E79F461 A74C03AA
K_5 056533C3A8 0504BF4D4E k_6 07591E062E 0126E922FF k_7 0C2D30F89D 030C0399E2 k_8 046786437C 04C1CB8FED K2 2E79F461 A74C03AA
(Note that k_1 ... k_4 are not listed in this example because they are multiplied by zero in L3-HASH.)
（それらはL3-HASHゼロで乗算されるので、K_1 ... k_4この例に記載されていないことに注意してください。）
When generating a 64-bit tag on input "'abc' * 500", the following intermediate results are produced:
「『ABC』 * 500」入力に64ビットのタグを生成する際に、以下の中間結果が生成されます。
Iteration 1
-----------
L1-HASH E6096F94EDC45CAC1BEDCD0E7FDAA906
L2-HASH 0000000000000000A6C537D7986FA4AA
L3-HASH 05F86309
Iteration 2
-----------
L1-HASH 2665EAD321CFAE79C82F3B90261641E5
L2-HASH 00000000000000001D79EAF247B394BF
L3-HASH DF9AD858
Concatenating the two L3-HASH results produces a final UHASH result of 05F86309DF9AD858. The pad generated for nonce N is D13745D4304F1842, which when xor'ed with the L3-HASH result yields a tag of D4CF26DDEFD5C01A.
2 L3-HASH結果を連結すること05F86309DF9AD858の最終UHASH結果を生成します。ノンスNに対して生成パッドはL3-ハッシュ結果とXOR D13745D4304F1842は、D4CF26DDEFD5C01Aのタグを生成します。
References
リファレンス
Normative References
引用規格
[1] FIPS-197, "Advanced Encryption Standard (AES)", National Institute of Standards and Technology, 2001.
[1] FIPS-197 "のAdvanced Encryption Standard（AES）"、米国国立標準技術研究所、2001年。
Informative References
参考文献
[2] D. Bernstein, "Stronger security bounds for permutations", unpublished manuscript, 2005. This work refines "Stronger security bounds for Wegman-Carter-Shoup authenticators", Advances in Cryptology - EUROCRYPT 2005, LNCS vol. 3494, pp. 164-180, Springer-Verlag, 2005.
[2] D.バーンスタイン、「順列のための強力なセキュリティ境界」、未発表原稿は、2005年この作品は、「ウェッグマン・カーター - シャウプオーセンティケータのための強力なセキュリティ境界を」洗練、暗号理論における進歩 - EUROCRYPT 2005、LNCS体積。 3494、頁164から180、シュプリンガー・フェアラーク、2005。
[3] J. Black, S. Halevi, H. Krawczyk, T. Krovetz, and P. Rogaway, "UMAC: Fast and provably secure message authentication", Advances in Cryptology - CRYPTO '99, LNCS vol. 1666, pp. 216- 233, Springer-Verlag, 1999.
[3] J.ブラック、S. Halevi、H. Krawczyk、T. Krovetz、及びP. Rogaway、 - CRYPTO '99、LNCS体積 "UMAC高速かつ証明可能安全なメッセージ認証" は、暗号理論の進歩します。 1666年、頁。216- 233、シュプリンガー・フェアラーク、1999。
[4] L. Carter and M. Wegman, "Universal classes of hash functions", Journal of Computer and System Sciences, 18 (1979), pp. 143- 154.
[4] L.カーター及びM.ウェッグマン、 "ハッシュ関数のユニバーサルクラス"、コンピュータとシステム科学誌、18（1979）、頁。143- 154。
[5] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[5]ケント、S.、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 4303、2005年12月。
[6] T. Krovetz, "Software-optimized universal hashing and message authentication", UMI Dissertation Services, 2000.
[6] T. Krovetz、 "ソフトウェアに最適化されたユニバーサルハッシュメッセージ認証"、UMI論文サービス、2000年。
[7] M. Wegman and L. Carter, "New hash functions and their use in authentication and set equality", Journal of Computer and System Sciences, 22 (1981), pp. 265-279.
[7] M.ウェッグマンとL.カーター、「新しいハッシュ関数と認証での使用と設定平等」、コンピュータとシステム科学、22（1981）、頁265から279のジャーナル。
Authors' Addresses
著者のアドレス
John Black Department of Computer Science University of Colorado Boulder, CO 80309 USA
コロラド州ボルダーのコンピュータサイエンス大学、CO 80309 USAのジョン・ブラック部門
EMail: jrblack@cs.colorado.edu
メールアドレス：jrblack@cs.colorado.edu
Shai Halevi IBM T.J. Watson Research Center P.O. Box 704 Yorktown Heights, NY 10598 USA
シャイ・ハレビIBM T.J。ワトソン研究所の私書箱704ヨークタウンハイツ、NY 10598 USA箱
EMail: shaih@alum.mit.edu
メールアドレス：shaih@alum.mit.edu
Alejandro Hevia Department of Computer Science University of Chile Santiago 837-0459 CHILE
チリのサンティアゴ837-0459チリのコンピュータサイエンス大学のアレハンドロヘビア部門
EMail: ahevia@dcc.uchile.cl
メールアドレス：ahevia@dcc.uchile.cl
Hugo Krawczyk IBM Research 19 Skyline Dr Hawthorne, NY 10533 USA
ヒューゴKrawczyk IBMリサーチ19スカイラインドライブホーソーン、NY 10533 USA
EMail: hugo@ee.technion.ac.il
メールアドレス：hugo@ee.technion.ac.il
Ted Krovetz (Editor) Department of Computer Science California State University Sacramento, CA 95819 USA
テッドKrovetz（編集）コンピュータサイエンスカリフォルニア州立大学の学部サクラメント、CA 95819 USA
EMail: tdk@acm.org
メールアドレス：tdk@acm.org
Phillip Rogaway Department of Computer Science University of California Davis, CA 95616 USA and Department of Computer Science Faculty of Science Chiang Mai University Chiang Mai 50200 THAILAND
カリフォルニア州デービス、CA 95616 USAと科学チェンマイ大学チェンマイ50200 THAILANDのコンピュータサイエンス学部の学科のコンピュータサイエンス大学のフィリップ・ロガウェイ部門
EMail: rogaway@cs.ucdavis.edu
メールアドレス：rogaway@cs.ucdavis.edu
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
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 AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。