[要約] RFC 4418は、UMAC（Universal Hashingを使用したメッセージ認証コード）に関する規格です。UMACは、効率的でセキュアなメッセージ認証を提供するために設計されています。
Network Working Group T. Krovetz, Ed.
Request for Comments: 4418 CSU Sacramento
Category: Informational March 2006
UMAC: Message Authentication Code using Universal Hashing
UMAC：ユニバーサルハッシュを使用したメッセージ認証コード
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).
Copyright（c）The Internet Society（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'に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は、WegmanとCarterのスタイルのMacです[4、7]。高速な「ユニバーサル」ハッシュ関数を使用して、入力メッセージmを短い文字列にハッシュします。この短い文字列は、擬似ランダムパッドでXorをマスクし、UMACタグになります。セキュリティは、ランダムに選択された秘密のハッシュ関数と擬似ランダムパッドを共有する送信者と受信機に依存します。これは、キー付きハッシュ関数Hと擬似ランダム関数Fを使用することで実現されます。タグは、計算を実行することで生成されます。
Tag = H_K1(M) xor F_K2(Nonce)
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は送信者と受信機が共有する秘密のランダムキーであり、NonCEは各生成されたタグで変化する値です。受信者は、送信者がどの非CEを使用しているかを知る必要があるため、Nonceを同期する方法を使用する必要があります。これは、メッセージとタグとともにNonceを明示的に送信すること、またはシーケンス番号などの他の非反復値の使用に同意することで実行できます。ノンセは秘密にする必要はありませんが、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は、UHASH（このドキュメントでも指定されている）と呼ばれるキー付き関数を使用して、キー付きハッシュ関数Hとして使用し、デフォルトの実装が高度な暗号化標準（AES）アルゴリズムを使用する擬似ランダム関数Fを使用します。UMACは、目的のセキュリティレベルに応じて、32、64-、96-、または128ビットタグを生成するように設計されています。Wegman-Carter Macの理論とUMACの分析は、真にランダムなキーとパッドを使用してUMACを「インスタンス化」すると、攻撃者（計算上未結合のものでも）が選択のメッセージの正しいタグを生成する確率があることを示しています。UMACによるタグ出力がそれぞれ長さ32、64、96、または128ビットの場合、1/2^30、1/2^60、1/2^90、または1/2^120以下（ここでシンボル ^は指数を表します）。攻撃者がN Forgeryの試みを行うと、1つ以上のタグを正しく取得する確率は、最大のn/2^30、n/2^60、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ビットの結果に増加している環境で最高のパフォーマンスを発揮します。SSE2命令を使用してIntel Pentium 4で64ビットタグを生成する際に、これらの乗算のうち2つを並行してUMACを処理すると、BYTEあたり約1 CPUサイクルのピークレートでメッセージを処理します。そして長い。Pentium IIIでは、SSE並列性を使用せずに、UMACはバイトあたり2サイクルのピークを達成します。短いメッセージでは、UMACは引き続きうまく機能します。256バイトのメッセージでバイトあたり約4サイクル、1500バイトメッセージでバイトごとに2サイクル以下です。32ビットタグを作成する時間は、64ビットタグを作成するために必要な半分を少し超えていますが、96ビットと128ビットのタグはそれぞれ1.5倍、2倍の長さです。
Optimized source code, performance data, errata, and papers concerning UMAC can be found at http://www.cs.ucdavis.edu/~rogaway/umac/.
UMACに関する最適化されたソースコード、パフォーマンスデータ、ERRATA、および論文は、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の仕様には、文字列と数字の両方の操作が含まれます。文字列変数は初期大文字で示されますが、数値変数はすべての小文字で示されます。UMACのアルゴリズムは、すべての大文字で示されています。String-LengthやString-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.
bytelength（s）：バイト内の文字列sの長さ。
bitlength(S): The length of string S in bits.
BitLength（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. strings 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からjからバイトIで構成されるSのサブストリング。
S || T: The string S concatenated with string T.
S ||T：文字列Tと連結された文字列。
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）：nバイトの最も近い正の倍数にゼロビットでパディングされた文字列s。正式には、Zeropad（s、n）= s ||t、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.
a^i：整数aは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).
BIT（s、n）：string sのn番目のビットが1の場合、整数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.より正式に、sが長い場合、str2uint（s）= 2^{t-1} * bit（s、1）2^{t-2} * bit（s、2）... 2^{1} * bit（s、t-1）bit（s、t）。
uint2str(n,i): The i-byte string S such that str2uint(S) = n.
uint2str（n、i）：str2uint（s）= nのi-byte string s。
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の主要な操作の1つは、文字列への加算と乗算の繰り返しの適用です。操作「_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).
uint2str（str2uint（s）str2uint（t）mod 2^32、4）、 "s _64 t" as uint2str（str2uint（s）str2uint（t）mod 2^64、8）、および "s _64 t" as uint2str（str2uint（t）mod 2^32、4）などs * _64 t "as uint2str（str2uint（s） * str2uint（t）mod 2^64、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、string sを使用して、4バイト単語の末尾に反転します。
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.
//
// 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
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 block cipherのキー長、バイト。
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、P）キーK（キーレンバイトの文字列）を使用して、P（ブロックレンバイトの文字列）にブロック暗号を適用します。
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バイトキーで使用されている場合、Blocklenは16に等しくなり（AESは16バイトブロックを使用しているため）、Keylenは16に等しく、エンシファーは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ビットキーを持つAEは、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、長さのキーレンバイトの文字列。インデックス、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>
//
// 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 = 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バイトのパッドを生成できます。最後のビット（8バイトパッドを生成するとき）または最後の2ビット（4バイトパッドを生成するとき）でのみ異なる非セースを使用して生成されたパッドは、同じブロック暗号化から派生していることに注意してください。これにより、シーケンシャルノンセのための単一のブロック暗号の呼び出しをキャッシュして共有できます。
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、長さのキーレンバイトの文字列。ノンセ、ブロックレンバイトの長さ1の文字列。タグレン、整数4、8、12、または16。出力：Y、長さのタグレンバイトの文字列。
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
//
// Make Nonce BLOCKLEN bytes by appending zeroes if needed
//
Nonce = Nonce || zeroes(BLOCKLEN - bytelength(Nonce))
//
// 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
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.
UMACのタグ生成は、UHASH（次のセクションで定義されている）を使用してメッセージをハッシュし、PDFを非CEに適用し、結果の文字列のXORを計算します。パッドとハッシュの長さは、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、長さのキーレンバイトの文字列。M、2^67ビット未満の長さの文字列。ノンセ、ブロックレンバイトの長さ1の文字列。タグレン、整数4、8、12、または16。出力：タグ、長さのタグレンバイトの文字列。
Compute Tag using the following algorithm.
次のアルゴリズムを使用してタグを計算します。
HashedMessage = UHASH(K, M, taglen)
Pad = PDF(K, Nonce, taglen)
Tag = Pad 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定義には、アルゴリズムによって生成されたタグの長さを指定するパラメーター「タグレン」があります。次のエイリアスは、名前にタグの長さを明示的にする名前を定義します。
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)
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によってハッシュされ、その出力はL2-HASHによってハッシュされ、その出力はL3-HASHによってハッシュされます。ハッシュされているメッセージが1024バイト以下の場合、L2-HASHは最適化としてスキップされます。L3-hashは長さが4バイトしか長さである文字列を出力するため、この3層ハッシュの複数の反復が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には特定の組み合わせ特性があり、Wegman-Carterメッセージ認証に適していることに注意してください。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、長さのキーレンバイトの文字列。M、2^67ビット未満の長さの文字列。タグレン、整数4、8、12、または16。出力：Y、長さのタグレンバイトの文字列。
Compute Y using the following algorithm.
次のアルゴリズムを使用してyを計算します。
//
// One internal iteration per 4 bytes of output
//
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)
//
// 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]
L3Key2_i = L3Key2[(i-1) * 4 + 1 ... i * 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
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.
ファーストレイヤーのハッシュは、メッセージを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（bitlength（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.
//
// 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
//
// 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)
return Y
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.
//
// 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
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).
2層は、ポリと呼ばれる多項式ハッシュを使用してL1-Hash出力を再ハッシュします。L1-HASH出力が長い場合、ポリはL1-HASH出力のプレフィックスで1回呼び出され、残りの異なる設定を使用して呼び出されます。（メッセージの長さが16メガバイトを超える場合にのみ、L1-HASH出力のこの2段階のハッシュが必要です。）タイミング攻撃を避けるために、ポリの慎重な実装が必要です（詳細についてはセクション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)
//
// 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
//
// 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
Y = uint2str(y, 16)
y = uint2str（y、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^未満のワードビット未満の正の整数。K、範囲0 ... Prime（Wordbits）-1。m、（Wordbits / 8）バイトで長さの分割可能な文字列。出力：y、範囲0 ... prime（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
//
// 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
//
// 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
Return y
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バイトです。この最後のハッシュ関数は、16バイトの文字列を固定長の4バイトにハッシュします。
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
//
// 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
//
// 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
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.
UMACの強度は、基礎となる暗号化関数の強度、つまりキーダリベーション関数（KDF）とパッド剥離関数（PDF）に依存します。この仕様では、両方の操作がブロック暗号を使用して実装されています。デフォルトでは、Advanced暗号化標準（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アルゴリズムは、Secret MacキーKを共有する2つのパーティ間でメッセージを認証するために使用されます。Kと、UMACなどの一部のMACアルゴリズムでは、認証タグがメッセージを使用して計算されます。当事者間に送信されるメッセージには、タグと、おそらくnonceが添付されます。MACを破るということは、攻撃者がキーK、新しいメッセージM（つまり、以前は合法的な関係者間で送信されていなかったもの）の知識なしで生成できることを意味します。キーK。これは偽造と呼ばれます。認証タグが長さtであるように指定されている場合、攻撃者は確率1/2^tでMACを簡単に破ることができることに注意してください。このため、攻撃者はその選択のメッセージを生成し、ランダムなタグを試すことができます。明らかに、タグは確率1/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ではなく作業でランダム関数を使用する場合、1/2^60よりも良い確率で正しいタグを生成できないことを示しています。別の結果[2]は、[3、6]と組み合わせると、AESが擬似ランダム順列として安全である限り、1/2^60の鍛造確率を大幅に増加させることなく、ランダム関数の代わりに使用できることを示しています。2^64以下のメッセージが認証されていないこと。同様に、32-、96、および128ビットタグは、1/2^30、1/2^90、および1/2^120を超える確率と、擬似ランダムとしてのAESに対する攻撃を成功させる確率で偽造できません順列。
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は広範な研究を受けており、疑似ランダム順列として非常に安全であると想定されています。実行可能な計算能力を持つ攻撃者が、ランダムにキーのあるAEをランダムに選択した順位を確率デルタと区別できると仮定した場合（より正確には、デルタは攻撃者の計算リソースの関数であり、機能をサンプリングする能力の関数です）、次に、そのような攻撃者は、1/2^30、1/^60、1/2^90、または1/2^120を超える確率でUMACを偽造できないことを取得します。N Forgeryの試みで、Forgeryはn/2^30、n/^60、n/2^90、またはn/2^120、さらに3*deltaを超えて確率で発生します。値デルタは、1/2^30、1/2^60、1/2^90、または1/2^120を超える場合があります。この場合、UMAC鍛造の確率は、AESのセキュリティを表す用語によって支配されます。
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タグを偽造しようとする攻撃者は、メッセージタグを検証するエンティティと対話し、成功する前に多数の偽造を試す必要があります。システムアーキテクチャは、これが可能な範囲を決定します。よく編成されたシステムでは、偽造された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は、最大1/2^90および1/2^120の基本的な衝突確率を持つ96または128ビットタグを生成できます。。セキュリティが少なく、計算が約50％少ない場合、UMACは32ビットタグを作成できます。この場合、以前と同じ仮定の下で、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は、範囲1からブロックレンバイトの長さを持つ非CEを必要とします。認証セッション内のすべての非性能は、長さが等しくなければなりません。安全な操作のために、単一のUMACセッションキーの寿命の範囲内で非CE値を繰り返すべきではありません。ノンセが繰り返された場合、メッセージの信頼性の保証はないため、繰り返されるノンセを伴うメッセージは不正であると見なされるべきです。
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.
デュプレックスチャネル（2つのパーティが相互にメッセージを送信する）でメッセージを認証するには、各方向に異なるキーを使用できます。同じキーが両方方向に使用されている場合、すべての非能力を明確にすることが重要です。たとえば、一方の当事者はノンセスを使用することもできますが、他の当事者は奇数の当事者を使用します。受信当事者は、送信者が正しいフォームの非CEを使用していることを確認する必要があります。
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.
この仕様では、タグを作成するエンティティとタグを検証するエンティティ間で、NonCE値がどのように作成、更新、または通信されるかを示していません。以下は可能性があります。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. NonCEは、ゼロに初期化され、各認証タグの生成後に1つずつ増加するブロックレンバイの符号なしの数字であるカウンターです。カウンターは、送信者と受信機の間で明示的に通信されません。代わりに、2つは信頼できる輸送を通信すると想定されており、それぞれが現在のNonCE値が何であるかを追跡するために独自のカウンターを維持しています。
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. NonCeはブロックバイバイトのランダム値です。（ランダムなn-bit値の繰り返しは約2^（n/2）試行で予想されるため、n-bit noncesを使用したセッションで伝達されるメッセージの数は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が高レベルのプロトコル内で使用される場合、Sequence番号などのフィールドが既にある可能性があります。これは、UMACが必要とする非CEを指定するために採用できます[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.
リプレイ攻撃には、攻撃者がメッセージ、NonCE、および認証タグを繰り返していることを伴います。多くのアプリケーションでは、リプレイ攻撃は非常に損害を与える可能性があり、防止する必要があります。UMACでは、これは通常、受信機に2回使用されていないことを受信機にチェックさせることにより、受信機で行われます。信頼できる接続では、ノンセがカウンターである場合、これは些細なことです。信頼できない接続では、ノンセがカウンターである場合、通常、最近のノンセのウィンドウをキャッシュします。ウィンドウが許可するものを超えるオーダーアウトメッセージ配信により、他の方法では有効な認証タグが拒否されます。特定の（メッセージ、ノンセ、タグ）トリプルが本物と見なされる場合、レシーバー次第であることを強調します。確かに、UMACによって決定されるように、タグはメッセージとNonCEに対して有効である必要がありますが、ノンセがリプレイであると検出されるため、メッセージは依然として不正であるとみなされる場合があります。
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の定義により、Tag-Prefix検証を実装できます。たとえば、レシーバーは、計算負荷が高い場合、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.
サイドチャネル攻撃には、実装特性を活用することにより、暗号化システムのセキュリティを破壊するという目標があります。一般的なサイドチャネル攻撃の1つは、システムの応答時間を測定し、処理されるデータによって満たされた条件に関する情報を導き出すことです。このような攻撃は「タイミング攻撃」として知られています。タイミングおよびその他のサイドチャネル攻撃の議論は、このドキュメントの範囲外です。ただし、タイミング情報が意図せずにリークされる可能性があるUMACアルゴリズムには場所があることを警告します。特に、ポリアルゴリズム（セクション5.3.2）は、値mが特定の範囲から外れているかどうかをテストし、アルゴリズムの動作は結果によって異なります。タイミング攻撃を回避する場合、どちらの場合も計算時間を均等にするように注意する必要があります。また、キャッシュ効果など、より微妙な理由でタイミング攻撃が発生する可能性があります。
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.
Cisco SystemsのDavid McGrewとScott Fluhrerは、短いメッセージのパフォーマンスにもっと注意を払うことを奨励することで、UMACを改善する上で重要な役割を果たしました。Jim Schaadと、RFCの検討中にこのドキュメントを改善してくれたCFRGメーリングリストに有益な提案をした人に感謝します。Black、Krovetz、およびRogawayは、NSF Awards 0208842、0240000、および9624560の下でこの作業を支持しており、Cisco Systemsからの贈り物を受けています。
Appendix. Test Vectors
付録。テストベクトル
Following are some sample UMAC outputs over a collection of input values, using AES with 16-byte keys. Let
16バイトキーを持つAEを使用して、入力値のコレクションにわたってサンプルUMAC出力を以下に示します。させて
K = "abcdefghijklmnop" // A 16-byte UMAC key
N = "bcdefghi" // An 8-byte nonce
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 'a' 'バイトまたは「ABC」文字列の文字列であるメッセージの小さなサンプルがリストされています。残りの列は、UMACが対応するメッセージ、Nonce NおよびKey Kで呼び出されたときに生成されたタグを16進数で示します。
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
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
(Note that k_1 ... k_4 are not listed in this example because they are multiplied by zero in L3-HASH.)
（K_1 ... K_4は、L3-HASHでゼロを掛けているため、この例にはリストされていません。）
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結果が生成されます。NonCe N用に生成されたパッドはD13745D4304F1842であり、L3-HASH結果でXOR'edが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年。この作業は、「Wegman-Carter-Shoup Authenticatorsのより強いセキュリティ境界線」を洗練し、暗号化の進歩-EuroCrypt 2005、LNCS Vol。3494、pp。164-180、Springer-Verlag、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. Black、S。Halevi、H。Krawczyk、T。Krovetz、およびP. Rogaway、「UMAC：高速かつ証明されたメッセージ認証」、暗号学の進歩-Crypto '99、LNCS Vol。1666、pp。216-233、Springer-Verlag、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.ウェグマン、「ハッシュ機能のユニバーサルクラス」、Journal of Computer and System Sciences、18（1979）、pp。143-154。
[5] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[5] Kent、S。、「セキュリティペイロード（ESP）のカプセル化IP」、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.カーター、「新しいハッシュ機能と認証とセットの平等におけるそれらの使用」、Journal of Computer and System Sciences、22（1981）、pp。265-279。
Authors' Addresses
著者のアドレス
John Black Department of Computer Science University of Colorado Boulder, CO 80309 USA
ジョンブラックコンピュータサイエンス大学コロラド大学ボルダー、コロラド州80309米国
EMail: jrblack@cs.colorado.edu
Shai Halevi IBM T.J. Watson Research Center P.O. Box 704 Yorktown Heights, NY 10598 USA
Shai Halevi Ibm T.J.ワトソン研究センターP.O.ボックス704ヨークタウンハイツ、ニューヨーク10598 USA
EMail: shaih@alum.mit.edu
Alejandro Hevia Department of Computer Science University of Chile Santiago 837-0459 CHILE
アレハンドロヘビアコンピュータサイエンス学科チリサンティアゴ837-0459チリ
EMail: ahevia@dcc.uchile.cl
Hugo Krawczyk IBM Research 19 Skyline Dr Hawthorne, NY 10533 USA
Hugo Krawczyk IBM Research 19 Skyline Dr Hawthorne、NY 10533 USA
EMail: hugo@ee.technion.ac.il
Ted Krovetz (Editor) Department of Computer Science California State University Sacramento, CA 95819 USA
テッドクロベッツ（編集者）コンピュータサイエンス学科カリフォルニア州立大学サクラメント、カリフォルニア州95819米国
EMail: 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
EMail: rogaway@cs.ucdavis.edu
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。