RFC4418 日本語訳
4418 UMAC: Message Authentication Code using Universal Hashing. T.Krovetz, Ed.. March 2006. (Format: TXT=51304 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group T. Krovetz, Ed. Request for Comments: 4418 CSU Sacramento Category: Informational March 2006
ワーキンググループT.Krovetz、エドをネットワークでつないでください。コメントのために以下を要求してください。 4418年のCSUサクラメントカテゴリ: 情報の2006年3月
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)インターネット協会(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は、現代のuniprocessorsでソフトウェアで計算するのにおいて非常に速くなるように設計されています。 測定速度は1バイトあたり1サイクルと同じくらい低いです。 UMACは数と32ビットの数の乗法、操作が現代のマシンでよく支えた32ビットと64ビットの添加に依存します。
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'edです。 UMACは厳密な証券分析を楽しみます、そして、唯一の内部の「暗号」のコンポーネントが擬似ランダムパッドと内部の主要な材料を発生させるのに使用されるブロック暗号です。
Krovetz Informational [Page 1] RFC 4418 UMAC March 2006
2006年の[1ページ]RFC4418UMAC行進の情報のKrovetz
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
1. 序論…3 2. 記法と基本的な操作…4 2.1. ストリングにおける操作…4 2.2. 整数における操作…5 2.3. ストリング整数変換操作…6 2.4. ストリングにおける数学の操作…6 2.5. エンディアンスワッピング: 調整しているエンディアンオリエンテーション…6 2.5.1. アルゴリズムをエンディアンで交換してください…6 3. キーとパッド派生機能…7 3.1. 暗号選択を妨げてください…7 3.2. KDF: 主要な派生機能…8 3.2.1. KDFアルゴリズム…8 3.3. PDF: パッド派生機能…8 3.3.1. PDFアルゴリズム…9 4. UMACは世代にタグ付けをします…10 4.1. UMACアルゴリズム…10 4.2. UMAC-32、UMAC-64、UMAC-96、およびUMAC-128…10 5. UHASH: 普遍的なハッシュ関数…10 5.1. UHASHアルゴリズム…11 5.2. L1-細切れ肉料理: 最初に、細切れ肉料理を層にしてください…12 5.2.1. L1-細切れ肉料理アルゴリズム…12 5.2.2. ニューハンプシャーアルゴリズム…13 5.3. L2-細切れ肉料理: 2番目に、細切れ肉料理を層にしてください…14 5.3.1. L2-細切れ肉料理アルゴリズム…14 5.3.2. ポリーアルゴリズム…15 5.4. L3-細切れ肉料理: 3番目に細切れ肉料理を層にしてください…16 5.4.1. L3-細切れ肉料理アルゴリズム…16 6. セキュリティ問題…17 6.1. 暗号文解読術への抵抗…17 6.2. 長さと鍛造物確率にタグ付けをしてください…17 6.3. 一回だけの問題…19 6.4. 反射攻撃…20 6.5. タグ接頭語検証…21 6.6. サイドチャンネルは攻撃します…21 7. 承認…21付録。 ベクトルをテストしてください…22の参照箇所…24 標準の参照…24 有益な参照…24
Krovetz Informational [Page 2] RFC 4418 UMAC March 2006
2006年の[2ページ]RFC4418UMAC行進の情報のKrovetz
1. Introduction
1. 序論
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はウェッグマンとカーター[4、7]のスタイルのMACです。 速い「普遍的な」ハッシュ関数は、入力メッセージMを脆いストリングに論じ尽くすのに使用されます。 そして、UMACタグをもたらして、この脆いストリングは擬似ランダムパッドでxor'ingによってマスクをかけられます。 セキュリティは手当たりしだいに選ばれた秘密のハッシュ関数と擬似ランダムパッドを共有する送付者と受信機に頼っています。 これは合わせられたハッシュ関数Hを使用することによって、達成されます、そして、擬似ランダム機能F.Aタグは計算を実行することによって、発生します。
Tag = H_K1(M) xor F_K2(Nonce)
タグはH_K1(M) xor F_ケーツーと等しいです。(一回だけ)
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とケーツーが送付者と受信機によって共有された秘密のランダムキーであり、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は合わせられたハッシュ関数HとしてUHASH(また、本書では指定される)と呼ばれる合わせられた機能を使用して、デフォルト実現がエー・イー・エス(AES)アルゴリズムを使用する擬似ランダム機能Fを使用します。 必要なセキュリティー・レベルによって、UMACは生産物32、64、96、または128ビットのタグに設計されています。 ウェッグマン-カーターMACsの理論とUMACの分析は、1つが本当に無作為のキーとパッドでUMACを「例示する」場合にだけ攻撃者(計算上限りないものさえ)が選ぶどんなメッセージのためにも正しいタグを作り出すという確率がUMACによって出力されたタグが32ビットか64ビットか96ビットか128ビットと、それぞれ長さのもの(ここに、シンボル^は羃法を表す)であるなら1/2^30、1/2^60、1/2^90、または1/2^120であることを示します。 攻撃者がN偽造試みをすると、1つか以上を得るという確率は直線的に高々2^30、N/N/2^60、2^90、またはN/N/2^120に正しい増加にタグ付けをします。 UMACの本当の実現では、キーとパッドを生産するのにAESを使用して、AESのセキュリティに関連する少量に従って、偽造確率は増加より上で記載しました。 AESが安全である限り、どんな実用的な攻撃にも、この小さい付加的な用語は意味をなしません。 その他の詳細に関してセクション6.2を見てください。 [3、6]にはUMACセキュリティに関連している分析があります。
Krovetz Informational [Page 3] RFC 4418 UMAC March 2006
2006年の[3ページ]RFC4418UMAC行進の情報のKrovetz
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ビットの結果に掛けられる環境でよく振る舞います。 インテルPentium4の上の平行なこれらの2つの掛け算をするSSE2指示を使用する64ビットのタグを作り出す際に、UMACは1バイトあたりおよそ1CPUサイクルのピーク速度でメッセージを処理します、ピークがおよそ4キロバイトに関するメッセージで達成されている状態で。 Pentium IIIの上では、SSE平行関係の使用がなければ、UMACは1バイトあたり2サイクルのピークを達成します。 より短いメッセージでは、UMACはまだよく振る舞っています: 256バイトのメッセージと2のバイトあたりおよそ4サイクルは1500年のバイトのメッセージを1バイト単位で循環します。 それの半分が、96と128ビットのタグが1.5で2倍長い状態で取っている間、64ビットのタグを作り出す必要があったより32ビットのタグを作り出す時間はそれぞれもう少しです。
Optimized source code, performance data, errata, and papers concerning UMAC can be found at http://www.cs.ucdavis.edu/~rogaway/umac/.
http://www.cs.ucdavis.edu/~rogaway/umac/ でUMACに関して最適化されたソースコード、性能データ、誤字、および書類を見つけることができます。
2. Notation and Basic Operations
2. 記法と基本的な操作
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のアルゴリズムはすべての大文字で指示されます。 ストリング長のためのそれらとストリング-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.
強調("_")が変数のあとに続いているときはいつも、強調が添字を指示することを意図します、「副-原稿を書」かれた表現が変数の意味を解決するために評価されている状態で。 例えば次に_2*私が参照するMからi=2であるなら可変M_4。
2.1. Operations on strings
2.1. ストリングにおける操作
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.
論じ尽くされるべきメッセージは無そっと歩くようになるビットのストリングとして適切なバイトの長さまで見なされます。 メッセージがいったんそっと歩くようになると、すべてのストリングがバイトのストリングとして見なされます。 1「バイト」が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: ストリング、bitwiseする、SとT.Strings SとTの排他的論理和には、同じ長さがいつもあります。
Krovetz Informational [Page 4] RFC 4418 UMAC March 2006
2006年の[4ページ]RFC4418UMAC行進の情報のKrovetz
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: ストリング、bitwiseする、SとTがいつも同じ長さに持っているSとT.Stringsの接続詞。
S[i]: The i-th byte of the string S (indices begin at
1).
S[i]: i、-、ストリングS(インデックスリストは1時に始まります)の第バイト。
S[i...j]: The substring of S consisting of bytes i through
j.
S[i...j]: jを通してバイトiから成るSに関するサブストリング。
S || T: The string S concatenated with string T.
S|| T: ストリングSはひもで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がゼロ・ビット(ことによると空の)の最も脆いストリングであることのそのS|| Tは非空です、そして、8nはbitlength(S| | T)を分割します。
2.2. Operations on Integers
2.2. 整数における操作
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.
標準の記法はほとんどの数学の操作に使用されます、乗法のための「*」や、添加のための「+」やモジュールの減少のための「モッズ」などのように。 いくつかのそれほど標準でない記法がここで定義されます。
a^i: The integer a raised to the i-th power.
^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 |
+-----+--------------------+---------------------------------------+
+-----+--------------------+---------------------------------------+ | n| 主要な(n)[小数]| 主要な(n)[16進]| +-----+--------------------+---------------------------------------+ | 36 | 2^36 - 5 | 0x0000000F FFFFFFFB| | 64 | 2^64 - 59 | 0xFFFFFFFF FFFFFFC5| | 128 | 2^128 - 159 | 0xFFFFFFFF FFFFFFFF FFFFFFFF FFFFFF61| +-----+--------------------+---------------------------------------+
Krovetz Informational [Page 5] RFC 4418 UMAC March 2006
2006年の[5ページ]RFC4418UMAC行進の情報のKrovetz
2.3. String-Integer Conversion Operations
2.3. ストリング整数変換操作
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であり、そうでなければ、整数0を返すなら(インデックスリストは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): t-2Sがt長さビットの当時のstr2uint(S)=2^t-1*+ (S、1)2ビット^であるなら2進法表示が正式にストリングS.Moreである非負の整数*ビット(S、2)+… + 噛み付かれるか(S、t-1)、または噛み付かれた2^1*(S、t)。
uint2str(n,i): The i-byte string S such that str2uint(S) = n.
uint2str(n、i): i-バイトは、str2uint(S)がnと等しいように、Sを結びます。
2.4. Mathematical Operations on Strings
2.4. ストリングにおける数学の操作
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つはストリングの上の添加と乗法の繰り返された適用です。 The operations "+_32", "+_64", and "*_64" are defined
"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" 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).
These operations correspond well with the addition and multiplication operations that are performed efficiently by modern computers.
これらの操作は現代のコンピュータによって効率的に実行される添加と乗法操作によく対応しています。
2.5. ENDIAN-SWAP: Adjusting Endian Orientation
2.5. エンディアンスワッピング: 調整しているエンディアンオリエンテーション
Message data is read little-endian to speed tag generation on little-endian computers.
リトルエンディアンは、リトルエンディアンコンピュータでタグ世代を促進するためにメッセージデータに読み込まれます。
2.5.1. ENDIAN-SWAP Algorithm
2.5.1. エンディアンスワッピングアルゴリズム
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
//
4バイトの塊//への////中断S
Krovetz Informational [Page 6] RFC 4418 UMAC March 2006
2006年の[6ページ]RFC4418UMAC行進の情報のKrovetz
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.
nはbytelength(S) / 4Let S_1、S_2と等しいです…, S、4バイトの長さのストリングがそのように、そのS_であった、1|| S_2|| ... || Sは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
1〜各塊、およびiのための<の空のストリング強化T//T=>=nがそのように、バイトがそのWであったならLet W_1、W_2、W_3、W_4をするバイト////逆_1|| W_2|| W_3|| W_4=S_i SReversed_iはW_4と等しいです。|| W_3|| W_2|| W_1TはTと等しいです。|| 私が終わるSReversed_
Return T
リターンT
3. Key- and Pad-Derivation Functions
3. キーとパッド派生機能
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とタグ世代時点で、内部的に必要です。 機能は、これらのビットを発生させるようにこのセクション使用でブロック暗号を記載しました。
3.1. Block Cipher Choice
3.1. ブロック暗号選択
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バイト)を使用するP(一連のBLOCKLENバイト)で解くENCIPHER(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と等しいでしょう、そして、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は少なくとも162のパワーであるに違いありません。
AES is defined in another document [1].
AESは別のドキュメント[1]で定義されます。
Krovetz Informational [Page 7] RFC 4418 UMAC March 2006
2006年の[7ページ]RFC4418UMAC行進の情報のKrovetz
3.2. KDF: Key-Derivation Function
3.2. KDF: 主要な派生機能
The key-derivation function generates pseudorandom bits used to key the hash functions.
機能が発生させる主要な派生擬似ランダムビットはキーにハッシュ関数を使用しました。
3.2.1. KDF Algorithm
3.2.1. KDFアルゴリズム
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未満^64numbytes、非負の整数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
1〜nがT=uint2strをするi=にカウンタモード//でブロック暗号を使用して、////はYを建てます(BLOCKLEN-8、索引をつけてください)。|| uint2str(i、8)TはENCIPHER(K、T)Y=Yと等しいです。|| tは終わります。
Y = Y[1...numbytes]
YはYと等しいです。[1…numbytes]
Return Y
リターンY
3.3. PDF: Pad-Derivation Function
3.3. PDF: パッド派生機能
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バイトのパッドを発生させるとき)発生するパッドが同じブロック暗号暗号化から得られるのに注意してください。 これで、連続した一回だけのためにただ一つのブロック暗号実施をキャッシュして、共有します。
Krovetz Informational [Page 8] RFC 4418 UMAC March 2006
2006年の[8ページ]RFC4418UMAC行進の情報のKrovetz
3.3.1. PDF Algorithm
3.3.1. PDFアルゴリズム
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バイトtaglenへの長さ1、整数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
////抽出が噛み付きますが、(taglen=4かtaglen=8)が索引をつけるなら必要な//がstr2uintの(一回だけ)のモッズ(BLOCKLEN/taglen)一回だけの=一回だけのxor uint2str(索引をつけてください、bytelengthです(一回だけの))エンドと等しいなら、どんな安値もNonceの(s)に噛み付きませんでした。
//
// Make Nonce BLOCKLEN bytes by appending zeroes if needed
//
Nonce = Nonce || zeroes(BLOCKLEN - bytelength(Nonce))
////はNonce BLOCKLENを//一回だけであることで必要であるならゼロを追加するのによるバイト=一回だけにします。|| ゼロ(BLOCKLEN--bytelength(一回だけ))
//
// 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
'////は、T[1…taglen](taglenは4かtaglen=8と等しいです)Y=t[(インデックス*taglen)…1+taglenな+(インデックス*taglen)]のほかのY=終わりであるならKDF(K、0、KEYLEN)索引をつけられたサブストリング//K'=T=ENCIPHER(K'、Nonce)をサブキーを発生させて、暗号化して、抽出します。
Return Y
リターンY
Krovetz Informational [Page 9] RFC 4418 UMAC March 2006
2006年の[9ページ]RFC4418UMAC行進の情報のKrovetz
4. UMAC Tag Generation
4. UMACタグ世代
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を一回だけに適用して、結果として起こるストリングのxorを計算して。 パッドと細切れ肉料理の長さは4バイトか8バイトか12バイトか16バイトどちらかであるかもしれません。
4.1. UMAC Algorithm
4.1. UMACアルゴリズム
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バイトtaglenへの長さ1、整数4、8、12または16のストリング。 出力: タグ、長さのtaglenバイトのストリング。
Compute Tag using the following algorithm.
以下のアルゴリズムを使用して、Tagを計算してください。
HashedMessage = UHASH(K, M, taglen)
Pad = PDF(K, Nonce, taglen)
Tag = Pad xor HashedMessage
HashedMessageはUHASH(K、Mはtaglenされる)パッド=PDF(K、Nonceはtaglenする)タグ=パッドxor HashedMessageと等しいです。
Return Tag
リターンタグ
4.2. UMAC-32, UMAC-64, UMAC-96, and UMAC-128
4.2. UMAC-32、UMAC-64、UMAC-96、およびUMAC-128
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)
UMAC(K、M、一回だけ、12)UMAC(K、M、一回だけ、8)UMAC(K、M、一回だけ、4)UMAC-32(K、M、一回だけ)=UMAC-64(K、M、一回だけ)=UMAC-96(K、M、一回だけ)=UMAC-128(K、M、一回だけ)はUMACと等しいです。(K、M、一回だけ、16)
5. UHASH: Universal Hash Function
5. UHASH: 普遍的なハッシュ関数
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
UHASHは合わせられたハッシュ関数であり、4、8、12、または16バイトの出力を起こします。(任意の長さのストリングを入力するとき、それは、取ります)。 UHASHは3つのステージ、または層で仕事します。 メッセージは最初に、L1-HASHによって論じ尽くされて、次に、出力は次に、出力がL3-HASHが論じ尽くされるL2-HASHによって論じ尽くされます。 論じ尽くされるメッセージが1024バイトよりもうであるなら、L2-HASHは最適化としてスキップされます。 L3-HASHが長さが4バイト長であるにすぎないストリングを出力するので、4バイトより長い総細切れ肉料理出力が要求されるなら、この3層の細切れ肉料理の複数の繰り返しが使用されています。 メモリを減らすために
Krovetz Informational [Page 10] RFC 4418 UMAC March 2006
2006年の[10ページ]RFC4418UMAC行進の情報のKrovetz
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.
使用、L1-HASHは繰り返しの間の主要な材料の大部分を再利用します。 かなりの量の内部のキーがUHASHに必要ですが、UMACのキーが変わりがない限り、それは一定のままで残っています。 メッセージが論じ尽くされるたびに内部のキーを発生させるか、またはメッセージの間でそれらをキャッシュするかが、implementerの選択です。
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は説明されて、それぞれのコンポーネントが論じ尽くすその時は寄贈されます。
5.1. UHASH Algorithm
5.1. 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、^67ビット2未満の長さの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バイトの出力//itersあたり////1つの内部の繰り返しが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は繰り返しの間の最も主要な材料を再利用します。 KDF(K、3、iters*64)KDF(K、2、iters*24)KDF(K、1、1024年の+(iters--1)*16)//L1Key=L2Key=L3Key1=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]
各繰り返し、抽出のための////は、3層の細切れ肉料理を合わせて、します。 //はbytelength(M)<であるなら1024、当時のスキップL2-HASHと等しいです。 itersへのi=1がL1Key_i=L1Key(i-1)*16+1…(i-1) *16+1024] L2Key_iはL2Key(i-1)*24+1と等しいです… i*24]L3Key1_iをするので、<の空のストリング//Y=>はL3Key1と等しいです。[(i-1)*64+1…i*64]
Krovetz Informational [Page 11] RFC 4418 UMAC March 2006
2006年の[11ページ]RFC4418UMAC行進の情報のKrovetz
L3Key2_i = L3Key2[(i-1) * 4 + 1 ... i * 4]
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
=L1-HASH(L1Key_i、M)は次に、(bitlength(M)<はbitlength(L1Key_i)と等しいです)Bであるならゼロ(8)と等しいです。|| CがL3-HASH(L3Key1_i、L3Key2_i、B)Y=Yと等しいなら、Bほかの=L2-HASH(L2Key_i、A)は終わります。|| Cは終わります。
Return Y
リターンY
5.2. L1-HASH: First-Layer Hash
5.2. L1-細切れ肉料理: 初層細切れ肉料理
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年のバイトの塊に細かく分けて、機能がニューハンプシャーと呼ばれている状態で、それぞれを論じ尽くします。 結果を連結すると、ストリングは形成されます。(それは、オリジナルより最大128倍少ないです)。
5.2.1. L1-HASH Algorithm
5.2.1. L1-細切れ肉料理アルゴリズム
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.
1024年のバイトの塊(最終的な塊は、より短いかもしれない)//t=最大(ceil(bitlength(M)/8192)、1)への////中断MはM_1、M_2をさせました…, M_t、MがM_1と等しいためのストリングになってください。|| M_2|| ... || すべての0<i<tのためのM_t、およびbytelength(M_i)=1024。
//
// 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
最終以外の各塊のための////: エンディアンで調整してください、ニューハンプシャーは、//を論じ尽くして、ビット-長さを加えます。 結果を使用して、t-1へのi=1のための<の空のストリングY=>がそうするY.//レン=uint2str(1024*8、8)にENDIAN-SWAP(M_i)Y=Yを建ててください。|| (NH(K, M_i) +_64 Len) 終わります。
Krovetz Informational [Page 12] RFC 4418 UMAC March 2006
2006年の[12ページ]RFC4418UMAC行進の情報のKrovetz
//
// 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バイト境界の、そして、エンディアンで適応している//ニューハンプシャー細切れ肉料理にそっと歩いてください、そして、ビット-長さを加えてください。 zeropad(M_t、32)ENDIAN-SWAP(M_t)Y Y.//レン=uint2str(bitlength(M_t)、8)M_t==Yに結果を連結してください。|| (NH(K, M_t) +_64 Len)
return Y
リターンY
5.2.2. NH Algorithm
5.2.2. ニューハンプシャーアルゴリズム
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.
4バイトの塊//tへの////中断MとKはbytelength(M) / 4Let M_1、M_2と等しいです…, M_t、MがM_1と等しいための4バイトのストリングになってください。|| M_2|| ... || M_t。 K_1、K_2をさせてください…, K_t、したがって、4バイトがそのK_1つを結ぶということになってください。|| 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つ離れてある単語を対にして、////は塊にニューハンプシャー細切れ肉料理を実行します。 // 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
Krovetz Informational [Page 13] RFC 4418 UMAC March 2006
2006年の[13ページ]RFC4418UMAC行進の情報のKrovetz
5.3. L2-HASH: Second-Layer Hash
5.3. L2-細切れ肉料理: 第2層の細切れ肉料理
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番目の層は、POLYと呼ばれる多項式細切れ肉料理を使用することでL1-HASH出力を作り直します。 L1-HASH出力が長いなら、POLYはL1-HASHの接頭語でかつての出力と呼ばれて、残りでの異なった設定を使用すると呼ばれます。 (L1-HASH出力をこのツーステップの論じ尽くすことがメッセージ長が16メガバイト以上である場合にだけ必要です。) POLYの慎重な実現が、可能なタイミング攻撃を避けるのに必要です(詳しい情報に関してセクション6.6を見てください)。
5.3.1. L2-HASH Algorithm
5.3.1. L2-細切れ肉料理アルゴリズム
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)
////は、キーを抽出して、Mask128=uint2str(0x01ffffff01ffffff01ffffff01ffffff、16)k64=str2uint(K[1...8]とMask64)k128=str2uintを特別な主要なセット//Mask64=uint2str(0x01ffffff01ffffff、8)に制限します。(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ビットの//そうでない主要の下の細切れ肉料理は、最初に、主要な64ビットの2^17バイト下の細切れ肉料理と128ビットの主要の下の//残りです。 //、そして、//2つの(bytelength(M)<=2^17)^の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
64ビットの単語、およびPOLY法//が(64)(そして制限された2^64--2^32で)を用意する使用の勢ぞろいとしての////視点Mはそれを論じ尽くします。 ほか..等しい..0×80..終わる
Krovetz Informational [Page 14] RFC 4418 UMAC March 2006
2006年の[14ページ]RFC4418UMAC行進の情報のKrovetz
Y = uint2str(y, 16)
Yはuint2strと等しいです。(y、16)
Return Y
リターンY
5.3.2. POLY Algorithm
5.3.2. ポリーアルゴリズム
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か128maxwordrange、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
////は範囲の外で主要な(wordbits)単語//wordbytes=wordbits / 8p=オフセット=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
長さのwordbytesバイト//nの塊への////中断Mはbytelength(M) / wordbytes Let M_1、M_2と等しいです…, M、長さのwordbytesバイトがストリングあるので、MはM_1と等しいです。|| M_2|| ... || M
//
// 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--相殺する)(範囲の両方)は論じ尽くされます。 (k*y+マーカー)モッズ次に、(m>はmaxwordrangeと等しいです)y=p yがモッズのpほかのy=(k*y+m)モッズpと等しいなら(k*y+(m--相殺してください))1〜i=nがm=str2uint(M_i)をするので、//y=1は終わりであるなら終わります。
Return y
リターンy
Krovetz Informational [Page 15] RFC 4418 UMAC March 2006
2006年の[15ページ]RFC4418UMAC行進の情報のKrovetz
5.4. L3-HASH: Third-Layer Hash
5.4. L3-細切れ肉料理: 第3層の細切れ肉料理
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バイトのストリングを論じ尽くします。
5.4.1. L3-HASH Algorithm
5.4.1. L3-細切れ肉料理アルゴリズム
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バイトの長さのストリング。 ケーツー、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
// // 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
そして、内側の////製品細切れ肉料理、抽出が32ビット続く、アフィンである、-翻訳してください、//y=(m_1*k_1+…+m_8*k_8)モッズ主要(36)yがyモッズ2^と等しい、32、Y、= uint2str(y、4)YはY xorケーツーと等しいです。
Return Y
リターンY
Krovetz Informational [Page 16] RFC 4418 UMAC March 2006
2006年の[16ページ]RFC4418UMAC行進の情報のKrovetz
6. Security Considerations
6. セキュリティ問題
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の適切な理解と使用に、重要ないくつかのセキュリティ問題について説明します。
6.1. Resistance to Cryptanalysis
6.1. 暗号文解読術への抵抗
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)。 この仕様では、両方の操作は、デフォルトでブロック暗号を使用することで実行されます。エー・イー・エス(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]の分析は証明可能なセキュリティを持つためにこの計画を示しています、現代の暗号の意味で、きつい減少を通して。 これが確率でそんなにかなり鍛造するUMACに対する敵の攻撃がUHASHの確立した衝突確率を超えているということであることを意味することは匹敵する複雑さの攻撃を起こすでしょう。 この攻撃はブロック暗号を破るでしょう、無作為の順列の家族とブロック暗号を区別するという意味で。 この設計手法はUMACで本質的には暗号文解読術の必要性を取り除きます: 結果は、cryptanalyticの努力がブロック暗号に焦点を合わせるほうがよいのを含意します。
6.2. Tag Lengths and Forging Probability
6.2. タグの長さと鍛造物確率
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
MACアルゴリズムは、秘密のMACキーK.を共有する2回のパーティーの間のメッセージを認証するのに使用されます。An認証タグは、メッセージのためにKとUMACなどのいくつかのMACアルゴリズムによる一回だけを使用することで計算されます。 伝えられて、パーティーが彼らのタグによって同伴されるというメッセージとことによると一回だけ。 MACを壊すのは、攻撃者が主要なKに関する知識のないそれ自身のところで新しいメッセージMを発生させることができることを意味します、そして、(すなわち、1は以前に、正統のパーティーの間を伝わりませんでした)主要なK.Thisの下でMで正しい認証タグを計算するのは偽造と呼ばれます。 タグが認証であるなら長さtがあるように指定されて、その時が攻撃者であることに注意してください。
Krovetz Informational [Page 17] RFC 4418 UMAC March 2006
2006年の[17ページ]RFC4418UMAC行進の情報のKrovetz
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.
確率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より良い状態でどんな攻撃戦略も正しいタグを作り出すことができないのを示します。 [3、6]に結合されると、別の結果[2]は、AESが擬似ランダム順列として安全であるので1/2^60をかなり増加させることのない確率関数の代わりにそれを使用できるようにそれほど長い間確率を作り出して、その2未満^を仮定して、64のメッセージが認証されるのを示します。 同様に、擬似ランダム順列として1/2^30、1/2^90、および1/2^120確率とうまくいっている攻撃の確率以上でAESに対して32、96、および128ビットのタグを鍛造できません。
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を区別できないと思うなら、確率デルタ(より正確に、デルタは攻撃者のコンピュータのリソースと機能を抽出するその性能の関数である)、私たちが得るそのような攻撃者でないのがそうすることができるその時で、確率が1/^の1/2^30、60、1/2^90、または1/2^120、および3*デルタより大きい状態でUMACを鍛造してください。 N偽造試みの上では、確率が2^90、またはN/N/2のN/2^30、N/^60、^120、および3*デルタほど多くない偽造は起こります。 値のデルタは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タグを鍛造するのを試みる攻撃者は、メッセージタグについて確かめる実体と対話して、1つが成功しそうな前に多くの偽造を試みる必要があるでしょう。 システム構築はこれが可能である範囲を測定するでしょう。 よくarchitectedされたシステムには、偽造MACsを寄贈して、彼らが有効であるかどうか決定するための少しの高帯域能力もあるべきではありません。 特に、検証パーティーでの認証失敗の数は制限されるべきです。 そのような多くの試みが検出されるなら、記録されていて、主要な使用でセッションは、監査ログの低下していて出来事であるべきです。
Krovetz Informational [Page 18] RFC 4418 UMAC March 2006
2006年の[18ページ]RFC4418UMAC行進の情報のKrovetz
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のためのどんなそのような攻撃もありません。 代わりに、攻撃者がN偽造試み(攻撃者がN/2^60確率より多くにしないそれらのさらに1つ以上が正しくなるその時)を持つことができるなら、1/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つはメッセージを作り出すことができません。 1/2^30偽造確率が高いと公正に考えられるので32ビットのタグを使用するとき、特別な注意を払わなければなりません。 それでも、少ない値のデータか急速に変えている主要な環境で有効に高い速度低いセキュリティ認証を適用できます。
6.3. Nonce Considerations
6.3. 一回だけの問題
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.
長さが範囲1にある状態で、UMACはBLOCKLENバイトに一回だけを必要とします。 認証セッションにおけるすべての一回だけが長さにおいて等しいに違いありません。 安全な操作において、単一のUMACセッションキーの人生中にどんな一回だけの値も繰り返すべきではありません。 一回だけが繰り返されるとき、メッセージの信憑性の保証が全くないので、繰り返された一回だけによって伴われたメッセージは本物でないと考えられるべきです。
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回のパーティーがメッセージを互いに送るところ)の上にメッセージを認証するために、各指示に異なったキーを使用できました。 同じキーが両方の方向に使用されるなら、すべての一回だけが異なっているのは、重要です。 例えば、相手が変なものを使用している間、1回のパーティーが一回だけさえ使用できます。 受領者は、送付者が訂正用紙の一回だけを使用していることを確かめなければなりません。
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:
この仕様はタグを作り出す実体とタグについて確かめる実体の間で一回だけの値を作成するか、アップデートするか、またはどう伝えるかを示しません。 ↓これは可能性です:
Krovetz Informational [Page 19] RFC 4418 UMAC March 2006
2006年の[19ページ]RFC4418UMAC行進の情報のKrovetz
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. 一回だけは8バイトの符号のない数、Counterです。(そのCounterはゼロに初期化されて、それぞれの認証タグの世代に続いて、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-バイト、符号のない数、Counter。(そのCounterはゼロに初期化されて、それぞれの認証タグの世代に続いて、1つ増加されます)。 Counterは送付者と受信機の間で明らかに伝えられません。代わりに、2が信頼できる輸送の上で交信すると思われて、それぞれが、現在の一回だけの値がものであることは動向をおさえるためにそれ自身のカウンタを主張します。
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[5]によって必要とされた一回だけを指定するためにそれを選出できます)。 そして、アプリケーションはこの既に既存の分野から一回だけを組み立てる方法を指定するでしょう。
6.4. Replay Attacks
6.4. 反射攻撃
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では、受信機にどんな一回だけの値も二度使用されないのをチェックさせることによって、通常、受信機にこれをするでしょう。 頼もしい接続のときに一回だけがカウンタであるときに、これは些細です。 頼り無い接続のときに一回だけがカウンタであるときに、通常、1つは最近の一回だけのある窓をキャッシュするでしょう。 窓が許容することを超えた不適切なメッセージ配送はそうでなければ、有効な認証タグを拒絶するのに結果として生じるでしょう。 私たちは、与えられた(メッセージ、一回だけ、タグ)三重が正統であると考えられるとき、それが受信機次第であると強調します。 確かに、UMACによって決定されるようにメッセージと一回だけには、タグは有効であるべきですが、一回だけが再生になるように検出されるので、メッセージは本物でないとまだ考えられているかもしれません。
Krovetz Informational [Page 20] RFC 4418 UMAC March 2006
2006年の[20ページ]RFC4418UMAC行進の情報のKrovetz
6.5. Tag-Prefix Verification
6.5. タグ接頭語検証
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ビットの接頭語が不正確である手に負えないa64ビットのタグを拒絶するかもしれません。 そのような習慣は、潜在的に危険であり、確かめられた接頭語の長さにセッションのセキュリティを下げる攻撃に通じることができます。 UMACキー(または、セッション)には、関連していて不変のタグの長さがなければなりません、そして、実現はタグの与えられた適切な接頭語が有効であるか、または無効であるかを明らかにする情報を漏らすべきではありません。
6.6. Side-Channel Attacks
6.6. サイドチャンネル攻撃
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アルゴリズムには場所がタイミング情報を何気なく漏らすことができたところにあると警告します。 値のmが特定の範囲から脱しているか否かに関係なく、特に、POLYアルゴリズム(セクション5.3.2)はテストされます、そして、結果によって、アルゴリズムの振舞いは異なります。 タイミング攻撃が避けられることであるなら、どちらの場合も計算時間を均等化するために注意するべきです。 また、タイミング攻撃は効果をキャッシュするのを含むより微妙な理由で起こることができます。
7. Acknowledgements
7. 承認
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、0240000、および9624560、および贈り物の下のこの仕事のサポートを受けました。
Krovetz Informational [Page 21] RFC 4418 UMAC March 2006
2006年の[21ページ]RFC4418UMAC行進の情報のKrovetz
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:
UMACによってキーKと一回だけNを使用することで発生したタグは以下の通りです。
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
メッセージの32ビットのタグ64ビットのタグ96ビットのタグ------- ---------- ---------- ---------- <の空の>113145FB6E155FAD26900BE1 32FEDB100C79AD58F07FF764 'a'*3 3B91D102 44B5CB542F220104 185E4FE905CBA7BD85E4C2DC 'a'*2^10 599B350B 26BF2F5D60118BD9 7A54ABE04AF82D60FB298C3C 'a'*2^15 58DCF532 27F8EF643B0D118D 7B136BD911E4B734286EF2BE 'a'*2^20DB6364D1 A4477E87E9F55853 F8ACFA3AC31CFEEA047F7B11 'a'*2^25 5109A660 2E2DBC36860A0A5F 72C6388BACE3ACE6FBF062D9'abc'*1ABF3A3A0 D4D7B9F6BD4FBFCF 883C3D4B97A61976FFCF2323'abc'*500ABEB3C8B 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'ストリングのストリングであるメッセージに関する小標本をリストアップします。 残っているコラムは16進で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)
繰り返し1繰り返し2----------- ----------- ニューハンプシャー(セクション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_1ACD79B4F C6DFECA2K_2 6EDA0D0E 964A710D K_3 1625B603 AD7EDE4D K_4 84F9FC93 A1D3935E K_5C6DFECA2 62EC8672… K_256 0BF0F56C 744C294F
L2-HASH (Section 5.3.1)
L2-細切れ肉料理(セクション5.3.1)
k64 0094B8DD0137BEF8 01036F4D000E7E72
k64 0094B8DD0137BEF8 01036F4D000E7E72
L3-HASH (Section 5.4.1)
L3-細切れ肉料理(セクション5.4.1)
k_5 056533C3A8 0504BF4D4E
k_5 056533C3A8 0504BF4D4E
Krovetz Informational [Page 22] RFC 4418 UMAC March 2006
2006年の[22ページ]RFC4418UMAC行進の情報のKrovetz
k_6 07591E062E 0126E922FF
k_7 0C2D30F89D 030C0399E2
k_8 046786437C 04C1CB8FED
K2 2E79F461 A74C03AA
2Eの07591 0126 062E E Eの922FF k_7 0C2D30F89D 030C0399E2k_8 046786437Cのk_6 04C1CB8FEDケーツー79F461 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
繰り返し1----------- L1-細切れ肉料理E6096F94EDC45CAC1BEDCD0E7FDAA906 L2-細切れ肉料理0000000000000000A6C537D7986FA4AA L3-細切れ肉料理05F86309
Iteration 2
-----------
L1-HASH 2665EAD321CFAE79C82F3B90261641E5
L2-HASH 00000000000000001D79EAF247B394BF
L3-HASH DF9AD858
繰り返し2----------- L1-細切れ肉料理2665EAD321CFAE79C82F3B90261641E5 L2-細切れ肉料理00000000000000001D79EAF247B394BF L3-細切れ肉料理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のために発生するパッドはD13745D4304F1842です。(L3-HASH結果があるxor'edであるときに、そのD13745D4304F1842はD4CF26DDEFD5C01Aのタグをもたらします)。
Krovetz Informational [Page 23] RFC 4418 UMAC March 2006
2006年の[23ページ]RFC4418UMAC行進の情報のKrovetz
References
参照
Normative References
引用規格
[1] FIPS-197, "Advanced Encryption Standard (AES)", National
Institute of Standards and Technology, 2001.
[1] FIPS-197、「エー・イー・エス(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。 この仕事はCryptologyで「ウェッグマン・カーター・シャウプ固有識別文字のための、より強いセキュリティ領域」、Advancesを精製します--EUROCRYPT2005、LNCS vol.3494、ページ 164-180、追出石-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.黒、S.ハレビ、H.Krawczyk、T.Krovetz、およびP.Rogaway、「UMAC:」 「通報認証を速さに、そして証明可能に保証してください」、CryptologyのAdvances--CRYPTO'99、LNCS vol.1666、ページ、' 216- 233、追出石-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とSystem Sciences、18(1979)、ページ 143- 154.
[5] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303,
December 2005.
[5] ケント、S.、「セキュリティ有効搭載量(超能力)を要約するIP」、RFC4303、2005年12月。
[6] T. Krovetz, "Software-optimized universal hashing and message
authentication", UMI Dissertation Services, 2000.
[6] UMI Dissertation Services、T.がKrovetzして、「普遍的な論じ尽くすことをソフトウェアで最適化して、認証を通信する」、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とSystem Sciences、22(1981)、ページ 265-279.
Krovetz Informational [Page 24] RFC 4418 UMAC March 2006
2006年の[24ページ]RFC4418UMAC行進の情報のKrovetz
Authors' Addresses
作者のアドレス
John Black Department of Computer Science University of Colorado Boulder, CO 80309 USA
コロラドボウルダー、CO80309米国のジョンBlackのコンピュータサイエンス学部大学
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
ShaiハレビIBM T.J.ワトソン研究所私書箱704ヨークタウンの高さ、ニューヨーク10598米国
EMail: shaih@alum.mit.edu
メール: shaih@alum.mit.edu
Alejandro Hevia Department of Computer Science University of Chile Santiago 837-0459 CHILE
アレハンドロ・Heviaコンピュータサイエンス学部チリサンティアゴ大学837-0459チリ
EMail: ahevia@dcc.uchile.cl
メール: ahevia@dcc.uchile.cl
Hugo Krawczyk IBM Research 19 Skyline Dr Hawthorne, NY 10533 USA
ユーゴーKrawczyk IBM Research19地平線Hawthorne博士、ニューヨーク10533米国
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
カリフォルニア95819米国のテッドKrovetz(エディタ)コンピュータサイエンス学部カリフォルニア州立大学のサクラメント
EMail: tdk@acm.org
メール: tdk@acm.org
Krovetz Informational [Page 25] RFC 4418 UMAC March 2006
2006年の[25ページ]RFC4418UMAC行進の情報のKrovetz
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
科学チェンマイ大学Chiang Mai50200タイのフィリップRogawayコンピュータサイエンス学部のカリフォルニア大学のデイヴィス、カリフォルニア95616米国、およびコンピュータサイエンス学部の教授陣
EMail: rogaway@cs.ucdavis.edu
メール: rogaway@cs.ucdavis.edu
Krovetz Informational [Page 26] RFC 4418 UMAC March 2006
2006年の[26ページ]RFC4418UMAC行進の情報のKrovetz
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Krovetz Informational [Page 27]
Krovetz情報です。[27ページ]
一覧
スポンサーリンク
