Network Working Group                                    T. Krovetz, Ed.
Request for Comments: 4418                                CSU Sacramento
Category: Informational                                       March 2006
        
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).

版权所有(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被设计为在当代单处理器上以软件进行计算的速度非常快。测量的速度低至每字节一个周期。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.

为了在给定消息上生成认证标签,对消息和密钥应用“通用”散列函数以生成短的固定长度散列值,然后将该散列值与密钥派生的伪随机pad异或。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
        
   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. 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是威格曼和卡特风格的MAC[4,7]。快速“通用”散列函数用于将输入消息M散列为短字符串。然后用伪随机pad用异或屏蔽这个短字符串,从而生成UMAC标记。安全性取决于发送方和接收方共享随机选择的秘密哈希函数和伪随机pad。这是通过使用键控哈希函数H和伪随机函数F实现的。通过执行计算生成标记

     Tag = H_K1(M) xor F_K2(Nonce)
        
     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是随每个生成的标记而变化的值。接收方需要知道发送方使用了哪个nonce,因此需要使用一些同步nonce的方法。这可以通过显式地发送nonce以及消息和标记来实现,或者同意使用一些其他非重复值,例如序列号。nonce不需要保密,但需要注意确保在UMAC密钥的生命周期内,每个消息使用不同的nonce。

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,并使用伪随机函数F,其默认实现使用高级加密标准(AES)算法。UMAC设计用于生成32、64、96或128位标记,具体取决于所需的安全级别。Wegman-Carter Mac的理论和对UMAC的分析表明,如果一个人用真正随机的键和焊盘“实例化”UMAC,那么攻击者(即使是计算上无边界的攻击者)为其选择的任何消息生成正确标记的概率不超过1/2^30、1/2^60、1/2^90,或者,如果UMAC输出的标记长度分别为32、64、96或128位,则为1/2^120(此处符号^表示求幂)。当攻击者进行N次伪造尝试时,获得一个或多个正确标记的概率线性增加,最多为N/2^30、N/2^60、N/2^90或N/2^120。在UMAC的一个实际实现中,使用AES生成密钥和PAD,上面列出的伪造概率与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指令在英特尔奔腾4上生成64位标记(并行执行其中两个乘法)的过程中,UMAC以每字节约一个CPU周期的峰值速率处理消息,在约4 KB或更长的消息上达到峰值。在奔腾III上,在不使用SSE并行的情况下,UMAC实现了每字节两个周期的峰值。对于较短的消息,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的优化源代码、性能数据、勘误表和论文,请访问http://www.cs.ucdavis.edu/~rogaway/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的算法用所有大写字母表示。简单的函数,如用于字符串长度和字符串异或的函数,都是用小写字母编写的。

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。

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.

要散列的消息被视为将零填充到适当字节长度的位字符串。消息填充后,所有字符串都将被视为字节字符串。“字节”是一个8位字符串。以下符号用于操作这些字符串。

bytelength(S): The length of string S in bytes.

ByTeleLength(S):字符串的长度,以字节为单位。

bitlength(S): The length of string S in bits.

bitlength(S):字符串的长度(以位为单位)。

zeroes(n): The string made of n zero-bytes.

零(n):由n个零字节组成的字符串。

S xor T: The string that is the bitwise exclusive-or of S and T. Strings S and T always have the same length.

S xor T:是S和T的按位异或的字符串。字符串S和T总是具有相同的长度。

S and T: The string that is the bitwise conjunction of S and T. Strings S and T always have the same length.

S和T:S和T的按位合取字符串。字符串S和T的长度始终相同。

S[i]: The i-th byte of the string S (indices begin at 1).

S[i]:字符串S的第i个字节(索引从1开始)。

S[i...j]: The substring of S consisting of bytes i through j.

S[i…j]:由i到j字节组成的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):字符串S,用零位填充到n字节的最近正倍数。形式上,zeropad(S,n)=S | | T,其中T是零位的最短字符串(可能为空),因此S | | T为非空,8n除以位长度(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.

标准符号用于大多数数学运算,如“*”表示乘法,“+”表示加法,“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 |
    +-----+--------------------+---------------------------------------+
        
    +-----+--------------------+---------------------------------------+
    |  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 |
    +-----+--------------------+---------------------------------------+
        
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,则返回整数1,否则返回整数0(索引从1开始)。

str2uint(S): The non-negative integer whose binary representation is the string S. More formally, if S is t bits long then str2uint(S) = 2^{t-1} * bit(S,1) + 2^{t-2} * bit(S,2) + ... + 2^{1} * bit(S,t-1) + bit(S,t).

str2uint(S):二进制表示为字符串S的非负整数。更正式地说,如果S为t位长,则str2uint(S)=2^{t-1}*位(S,1)+2^{t-2}*位(S,2)+…+2^{1}*位(S,t-1)+位(S,t)。

uint2str(n,i): The i-byte string S such that str2uint(S) = n.

uint2str(n,i):i字节字符串S,使得str2uint(S)=n。

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中的一个主要操作是对字符串重复应用加法和乘法。定义了操作“+_32”、“+_64”和“*_64”

"S +_32 T" as uint2str(str2uint(S) + str2uint(T) mod 2^32, 4), "S +_64 T" as uint2str(str2uint(S) + str2uint(T) mod 2^64, 8), and "S *_64 T" as uint2str(str2uint(S) * str2uint(T) mod 2^64, 8).

“S+_32T”作为uint2str(str2uint(S)+str2uint(T)模块2^32,4),“S+_64T”作为uint2str(str2uint(S)+str2uint(T)模块2^64,8),而“S*_64T”作为uint2str(str2uint(S)*str2uint(T)模块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. ENDIAN-SWAP:调整ENDIAN方向

Message data is read little-endian to speed tag generation on little-endian computers.

在little endian计算机上读取消息数据以加快标签生成。

2.5.1. ENDIAN-SWAP Algorithm
2.5.1. ENDIAN-SWAP算法

Input: S, string with length divisible by 4 bytes. Output: T, string S with each 4-byte word endian-reversed.

输入:S,长度可被4字节整除的字符串。输出:T,字符串S,每个4字节字的尾端都反转。

Compute T using the following algorithm.

使用以下算法计算T。

     //
     // Break S into 4-byte chunks
     //
        
     //
     // 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.

n=bytellength(S)/4让S_1,S_2,…,S_n是长度为4字节的字符串,因此S_1 | | | | S| u 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
        
     //
     // 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

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).

ENCIPHER(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,ENCIPHER将引用AES函数。

Unless specified otherwise, AES with 128-bit keys shall be assumed to be the chosen block cipher for UMAC. Only if explicitly specified otherwise, and agreed to by communicating parties, shall some other block cipher be used. In any case, BLOCKLEN must be at least 16 and a power of two.

除非另有规定,否则应假定具有128位密钥的AES为UMAC的选定分组密码。只有在通信双方另有明确规定并同意的情况下,才能使用其他分组密码。在任何情况下,BLOCKLEN必须至少为16且为2的幂。

AES is defined in another document [1].

AES在另一个文档[1]中定义。

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字节的字符串。不小于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>
        
     //
     // 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
        
     //
     // 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…个字节]

Return Y

返回Y

3.3. PDF: Pad-Derivation Function
3.3. PDF:Pad求导函数

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.

此函数接受一个键和一个nonce,并返回一个伪随机pad,用于生成标记。可以生成长度为4、8、12或16字节的焊盘。请注意,使用仅在最后一位(生成8字节焊盘时)或最后两位(生成4字节焊盘时)不同的nonce生成的焊盘来自相同的分组密码加密。这允许缓存和共享一个针对连续nonce的块密码调用。

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字节的字符串。Nonce,长度为1到BLOCKLEN字节的字符串。taglen,整数4、8、12或16。输出:Y,长度为taglen字节的字符串。

Compute Y using the following algorithm.

使用以下算法计算Y。

      //
      // Extract and zero low bit(s) of Nonce if needed
      //
      if (taglen = 4 or taglen = 8)
        index = str2uint(Nonce) mod (BLOCKLEN/taglen)
        Nonce = Nonce xor uint2str(index, bytelength(Nonce))
      end if
        
      //
      // 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))
        
      //
      // 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
        
      //
      // 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

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应用于nonce,并计算结果字符串的xor来进行。pad和hash的长度可以是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位的字符串。Nonce,长度为1到BLOCKLEN字节的字符串。taglen,整数4、8、12或16。输出:标记,长度为taglen字节的字符串。

Compute Tag using the following algorithm.

使用以下算法计算标记。

     HashedMessage = UHASH(K, M, taglen)
     Pad           = PDF(K, Nonce, taglen)
     Tag           = Pad xor HashedMessage
        
     HashedMessage = UHASH(K, M, taglen)
     Pad           = PDF(K, Nonce, taglen)
     Tag           = Pad 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-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)
        
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的工作分为三个阶段或三个层次。消息首先通过L1-HASH进行散列,然后通过L2-HASH对其输出进行散列,然后通过L3-HASH对其输出进行散列。如果要散列的消息长度不超过1024字节,则作为优化跳过L2-HASH。由于L3-HASH输出的字符串长度仅为四个字节,因此如果请求的总哈希输出长度超过四个字节,则使用此三层哈希的多次迭代。减少内存

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的密钥不变,它就保持不变。实现者可以选择是在每次对消息进行哈希处理时生成内部密钥,还是在消息之间缓存它们。

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,然后给出了它的每个组件哈希。

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、 长度小于2^67位的字符串。taglen,整数4、8、12或16。输出:Y,长度为taglen字节的字符串。

Compute Y using the following algorithm.

使用以下算法计算Y。

     //
     // One internal iteration per 4 bytes of output
     //
     iters = taglen / 4
        
     //
     // 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)
        
     //
     // 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]
        
     //
     // 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]
        
       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
        
       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

5.2. L1-HASH: First-Layer Hash
5.2. L1-HASH:第一层哈希

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倍。

5.2.1. L1-HASH Algorithm
5.2.1. L1-HASH算法

Input: K, string of length 1024 bytes. M, string of length less than 2^67 bits. Output: Y, string of length (8 * ceil(bitlength(M)/8192)) bytes.

输入:K,长度为1024字节的字符串。M、 长度小于2^67位的字符串。输出:Y,长度为(8*ceil(位长度(M)/8192))字节的字符串。

Compute Y using the following algorithm.

使用以下算法计算Y。

     //
     // Break M into 1024 byte chunks (final chunk may be shorter)
     //
     t = max(ceil(bitlength(M)/8192), 1)
     Let M_1, M_2, ..., M_t be strings so that M = M_1 || M_2 || ... ||
        M_t, and bytelength(M_i) = 1024 for all 0 < i < t.
        
     //
     // 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 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)
        
     //
     // 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

5.2.2. NH Algorithm
5.2.2. NH算法

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.
        
     //
     // 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
        
     //
     // 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

5.3. L2-HASH: Second-Layer Hash
5.3. L2-HASH:第二层哈希

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).

第二层使用称为POLY的多项式散列重新散列L1-HASH输出。如果L1-HASH输出很长,则在L1-HASH输出的前缀上调用POLY一次,并在剩余部分上使用不同的设置调用POLY。(只有当消息长度大于16兆字节时,才需要对L1-HASH输出进行两步哈希处理。)需要仔细实施POLY以避免可能的定时攻击(有关更多信息,请参阅第6.6节)。

5.3.1. L2-HASH Algorithm
5.3.1. L2-HASH算法

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)
        
     //
     //  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
        
     //
     // 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
        
        //
        // 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

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.

输入:字位,整数64或128。maxwordrange,小于2^字位的正整数。k、 范围为0的整数。。。素数(字位)-1。M、 长度可被(字位/8)字节整除的字符串。输出:y,范围为0的整数。。。素数(字位)-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
        
     //
     // 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
        
     //
     // 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
        
     //
     // 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

5.4. L3-HASH: Third-Layer Hash
5.4. L3-HASH:第三层哈希

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字节的固定长度。

5.4.1. L3-HASH Algorithm
5.4.1. L3-HASH算法

Input: K1, string of length 64 bytes. K2, string of length 4 bytes. M, string of length 16 bytes. Output: Y, string of length 4 bytes.

输入:K1,长度为64字节的字符串。K2,长度为4字节的字符串。M、 长度为16字节的字符串。输出:Y,长度为4字节的字符串。

Compute Y using the following algorithm.

使用以下算法计算Y。

     y = 0
        
     y = 0
        
     //
     // Break M and K1 into 8 chunks and convert to integers
     //
     for i = 1 to 8 do
       M_i = M [(i - 1) * 2 + 1 ... i * 2]
       K_i = K1[(i - 1) * 8 + 1 ... i * 8]
       m_i = str2uint(M_i)
       k_i = str2uint(K_i) mod prime(36)
     end for
        
     //
     // 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
        
     //
     // 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

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)和pad派生函数(PDF)。在本规范中,这两种操作都使用分组密码实现,默认情况下使用高级加密标准(AES)。但是,UMAC的设计允许更换这些部件。实际上,可以使用其他分组密码或其他加密对象,例如(正确键控的)SHA-1或HMAC来实现KDF或PDF。

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进行密码分析的需要:结果表明,密码分析工作也可能集中在分组密码上。

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的双方之间的消息进行身份验证。使用K以及在某些MAC算法(如UMAC)中使用nonce计算消息的身份验证标签。当事方之间传输的消息带有它们的标签,可能还有nonce。破坏MAC意味着攻击者能够在不知道密钥K的情况下自行生成新消息M(即,以前未在合法各方之间传输的消息),并在M上计算密钥K下的正确身份验证标签。这称为伪造。请注意,如果将身份验证标记指定为长度t,则攻击者

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的正确标记。另一个结果[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经过了广泛的研究,被认为是非常安全的伪随机置换。如果我们假设没有具有可行计算能力的攻击者能够区分随机键控AES和随机选择的概率增量排列(更准确地说,增量是攻击者的计算资源及其对函数进行采样的能力的函数),然后我们得到,没有这样的攻击者能够伪造概率大于1/2^30、1/^60、1/2^90或1/2^120加上3*delta的UMAC。在N次伪造尝试中,伪造发生的概率不超过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次伪造尝试,那么攻击者获得一次或多次正确伪造的概率将不超过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可以产生96或128位的标签,其基本冲突概率最多为1/2^90和1/2^120。如果需要更少的安全性,那么UMAC可以产生32位的标签,从而减少大约50%的计算量。在这种情况下,在与以前相同的假设下,无法伪造概率大于1/2^30的消息。使用32位标记时必须特别小心,因为1/2^30的伪造概率相当高。不过,高速低安全性身份验证可以有效地应用于低值数据或快速变化的关键环境。

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.

UMAC需要长度在1到BLOCKLEN字节范围内的nonce。身份验证会话中的所有nonce的长度必须相等。对于安全操作,在单个UMAC会话密钥的生命周期内不应重复任何nonce值。当一个nonce被重复时,不能保证消息的真实性,因此伴随着一个重复的nonce的消息应该被认为是不真实的。

To authenticate messages over a duplex channel (where two parties send messages to each other), a different key could be used for each direction. If the same key is used in both directions, then it is crucial that all nonces be distinct. For example, one party can use even nonces while the other party uses odd ones. The receiving party must verify that the sender is using a nonce of the correct form.

为了通过双工通道(双方互相发送消息)对消息进行身份验证,可以对每个方向使用不同的密钥。如果在两个方向上使用相同的键,那么所有的nonce必须是不同的。例如,一方可以使用偶数,而另一方可以使用奇数。接收方必须验证发送方使用的是正确格式的nonce。

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:

本规范未说明如何在生成标记的实体和验证标记的实体之间创建、更新或传递nonce值。以下是各种可能性:

1. The nonce is an 8-byte unsigned number, Counter, which is initialized to zero, which is incremented by one following the generation of each authentication tag, and which is always communicated along with the message and the authentication tag. An error occurs at the sender if there is an attempt to authenticate more than 2^64 messages within a session.

1. nonce是一个8字节的无符号数字计数器,它被初始化为零,在生成每个身份验证标记后递增1,并且始终与消息和身份验证标记一起通信。如果试图验证会话中超过2^64封邮件的身份,则发送方会出错。

2. The nonce is a BLOCKLEN-byte unsigned number, Counter, which is initialized to zero and which is incremented by one following the generation of each authentication tag. The Counter is not explicitly communicated between the sender and receiver. Instead, the two are assumed to communicate over a reliable transport, and each maintains its own counter so as to keep track of what the current nonce value is.

2. nonce是一个块字节无符号数计数器,初始化为零,并在生成每个身份验证标记后递增1。发送方和接收方之间没有明确地通信计数器。相反,假设这两个计数器通过可靠的传输进行通信,并且每个计数器都维护自己的计数器,以便跟踪当前的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位值中的重复预计约为2^(n/2)次试验,因此在使用n位nonce的会话中要传输的消息数量不应接近2^(n/2)。)

We emphasize that the value of the nonce need not be kept secret.

我们强调暂时的价值不必保密。

When UMAC is used within a higher-level protocol, there may already be a field, such as a sequence number, which can be co-opted so as to specify the nonce needed by UMAC [5]. The application will then specify how to construct the nonce from this already-existing field.

当在更高级别的协议中使用UMAC时,可能已经存在一个字段,例如序列号,可以对其进行增选以指定UMAC所需的nonce[5]。然后,应用程序将指定如何从这个已经存在的字段构造nonce。

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.

重播攻击需要攻击者重复消息、nonce和身份验证标记。在许多应用程序中,重放攻击可能具有相当大的破坏性,必须加以防止。在UMAC中,这通常在接收器处通过让接收器检查两次没有使用nonce值来完成。在可靠连接上,当nonce是计数器时,这是微不足道的。在不可靠的连接上,当nonce是计数器时,通常会缓存最近的nonce的某个窗口。超出窗口允许范围的无序消息传递将导致拒绝其他有效的身份验证标记。我们强调,当一个给定的三元组(消息、nonce、标记)被认为是真实的时,这取决于接收者。当然,标记对于消息和nonce应该是有效的,这由UMAC确定,但是消息仍然可能被认为是不真实的,因为nonce被检测为重播。

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位前缀不正确的64位标记。此类做法具有潜在危险,可能导致攻击,从而将会话的安全性降低到验证前缀的长度。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.

侧通道攻击的目标是通过利用密码系统的实现特性来破坏其安全性。一种常见的侧信道攻击是测量系统响应时间,并获取有关正在处理的数据所满足条件的信息。这种攻击称为“定时攻击”。关于定时和其他侧通道攻击的讨论超出了本文档的范围。然而,我们警告说,UMAC算法中的某些地方可能会无意中泄露定时信息。特别是,多边形算法(第5.3.2节)测试值m是否超出特定范围,并且算法的行为因结果而异。如果要避免定时攻击,应注意在这两种情况下均衡计算时间。定时攻击也可能出于更微妙的原因发生,包括缓存效果。

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.

思科系统公司的David McGrew和Scott Fluhrer通过鼓励我们更加关注短信的性能,在改进UMAC方面发挥了重要作用。感谢Jim Schaad和向CFRG邮件列表提供有用建议的人在RFC审议期间改进本文件。Black、Krovetz和Rogaway在NSF奖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字节键的AES在输入值集合上的UMAC输出示例。允许

     K  = "abcdefghijklmnop"                  // A 16-byte UMAC key
     N  = "bcdefghi"                          // An 8-byte nonce
        
     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:

UMAC使用密钥K和nonce 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
        
     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”字符串。其余的列以十六进制表示在使用相应的消息nonce N和键K调用UMAC时生成的标记。

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)
        
                              Iteration 1         Iteration 2
                              -----------         -----------
     NH (Section 5.2.2)
        

K_1 ACD79B4F C6DFECA2 K_2 6EDA0D0E 964A710D K_3 1625B603 AD7EDE4D K_4 84F9FC93 A1D3935E K_5 C6DFECA2 62EC8672 ... K_256 0BF0F56C 744C294F

K_1 ACD79B4F C6DFECA2 K_2 EDA0D0E 964A710D K_3 1625B603 AD7EDE4D K_4 84F9FC93 A1D3935E K_5 C6DFECA2 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

k_6 07591E062E 0126E922FF k_7 0C2D30F89D 030C0399E2 k_8 046786437C 04C1CB8FED K2 2E79F461 A74C03AA

k_6 07591E062E 0126E922F 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 1
                   -----------
     L1-HASH  E6096F94EDC45CAC1BEDCD0E7FDAA906
     L2-HASH  0000000000000000A6C537D7986FA4AA
     L3-HASH  05F86309
        
                   Iteration 2
                   -----------
     L1-HASH  2665EAD321CFAE79C82F3B90261641E5
     L2-HASH  00000000000000001D79EAF247B394BF
     L3-HASH  DF9AD858
        
                   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.

连接两个L3-HASH结果将生成最终UHASH结果05F86309DF9AD858。为nonce N生成的pad是D13745D4304F1842,当与L3-HASH结果异或时,将生成一个标记D4CF26DDEFD5C01A。

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.Bernstein,“置换的更强安全边界”,未出版的手稿,2005年。这项工作完善了“Wegman-Carter-Shoup认证器的更强安全界限”,《密码学进展——欧洲密码2005》,LNCS第3494卷,第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:快速且可证明安全的消息认证”,密码学进展-加密'99,LNCS第1666卷,第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.Carter和M.Wegman,“哈希函数的通用类”,《计算机与系统科学杂志》,第18期(1979年),第143-154页。

[5] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.

[5] Kent,S.,“IP封装安全有效载荷(ESP)”,RFC 4303,2005年12月。

[6] T. Krovetz, "Software-optimized universal hashing and message authentication", UMI Dissertation Services, 2000.

[6] T.Krovetz,“软件优化的通用哈希和消息认证”,UMI论文服务,2000年。

[7] M. Wegman and L. Carter, "New hash functions and their use in authentication and set equality", Journal of Computer and System Sciences, 22 (1981), pp. 265-279.

[7] M.Wegman和L.Carter,“新的哈希函数及其在身份验证和集相等中的使用”,《计算机和系统科学杂志》,22(1981),第265-279页。

Authors' Addresses

作者地址

John Black Department of Computer Science University of Colorado Boulder, CO 80309 USA

约翰布莱克科罗拉多大学计算机科学系博尔德,CO 80309美国

   EMail: jrblack@cs.colorado.edu
        
   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.Watson研究中心美国纽约约克敦高地704号信箱,邮编10598

   EMail: shaih@alum.mit.edu
        
   EMail: shaih@alum.mit.edu
        

Alejandro Hevia Department of Computer Science University of Chile Santiago 837-0459 CHILE

智利大学计算机科学系圣地亚哥智利8370 049 9

   EMail: ahevia@dcc.uchile.cl
        
   EMail: ahevia@dcc.uchile.cl
        

Hugo Krawczyk IBM Research 19 Skyline Dr Hawthorne, NY 10533 USA

Hugo Krawczyk IBM Research 19天际线霍桑博士,美国纽约州10533

   EMail: hugo@ee.technion.ac.il
        
   EMail: hugo@ee.technion.ac.il
        

Ted Krovetz (Editor) Department of Computer Science California State University Sacramento, CA 95819 USA

Ted Krovetz(编辑)美国加利福尼亚州萨克拉门托市加利福尼亚州立大学计算机科学系,邮编95819

   EMail: tdk@acm.org
        
   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

菲利浦ReFaWe加利福尼亚大学计算机科学系,戴维斯,CA 95616美国和清迈大学计算机科学系清迈大学清迈50200泰国

   EMail: rogaway@cs.ucdavis.edu
        
   EMail: rogaway@cs.ucdavis.edu
        

Full Copyright Statement

完整版权声明

Copyright (C) The Internet Society (2006).

版权所有(C)互联网协会(2006年)。

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

本文件受BCP 78中包含的权利、许可和限制的约束,除其中规定外,作者保留其所有权利。

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

本文件及其包含的信息是按“原样”提供的,贡献者、他/她所代表或赞助的组织(如有)、互联网协会和互联网工程任务组不承担任何明示或暗示的担保,包括但不限于任何保证,即使用本文中的信息不会侵犯任何权利,或对适销性或特定用途适用性的任何默示保证。

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秘书处披露的知识产权副本和任何许可证保证,或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果,可从IETF在线知识产权存储库获取,网址为http://www.ietf.org/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的IETF-ipr@ietf.org.

Acknowledgement

确认

Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).

RFC编辑器功能的资金由IETF行政支持活动(IASA)提供。