IPSec Working Group T. Krovetz, Intel INTERNET-DRAFT J. Black, UNR Expires April 2001 S. Halevi, IBM A. Hevia, U.C. San Diego H. Krawczyk, Technion P. Rogaway, U.C. Davis October 2000 UMAC: Message Authentication Code using Universal Hashing <draft-krovetz-umac-01.txt> Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This specification describes how to generate an authentication tag (also called a "MAC") using the UMAC message authentication code. UMAC is designed to be very fast to compute, in software, on contemporary processors. Measured speeds are as low as 1.0 cycles per byte. The heart of UMAC is a universal hash function, UHASH, which relies on addition and multiplication of 16-bit, 32-bit, or 64-bit numbers, operations well-supported by contemporary machines. To generate the authentication tag on a given message, UHASH 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 "cryptographic" use is a block cipher, AES, to generate the pseudorandom pads and internal key material. Krovetz et al. Expires April 2001 [Page 0]
INTERNET-DRAFT UMAC October 2000 Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1 Organization . . . . . . . . . . . . . . . . . . . . . . . . 5 2 Named parameter sets: UMAC16 and UMAC32 . . . . . . . . . . . . . 5 2.1 Named parameters . . . . . . . . . . . . . . . . . . . . . . 5 2.2 Alternative instantiations . . . . . . . . . . . . . . . . . 6 2.3 Naming convention . . . . . . . . . . . . . . . . . . . . . 7 3 Notation and basic operations . . . . . . . . . . . . . . . . . . 7 3.1 Operations on strings . . . . . . . . . . . . . . . . . . . 8 3.2 Operations on integers . . . . . . . . . . . . . . . . . . . 10 3.3 String-Integer conversion operations . . . . . . . . . . . . 10 3.4 Mathematical operations on strings . . . . . . . . . . . . . 11 4 Key and pad derivation functions . . . . . . . . . . . . . . . . 12 4.1 KDF: Key derivation function . . . . . . . . . . . . . . . . 12 4.2 PDF: Pad-derivation function . . . . . . . . . . . . . . . . 13 5 UHASH-32: Universal hash function for a 32-bit word size . . . . 15 5.1 NH-32: NH hashing with a 32-bit word size . . . . . . . . . 16 5.2 L1-HASH-32: First-layer hash . . . . . . . . . . . . . . . . 17 5.3 POLY: Polynomial hash . . . . . . . . . . . . . . . . . . . 19 5.4 L2-HASH-32: Second-layer hash . . . . . . . . . . . . . . . 20 5.5 L3-HASH-32: Third-layer hash . . . . . . . . . . . . . . . . 22 5.6 UHASH-32: Three-layer universal hash . . . . . . . . . . . . 23 6 UHASH-16: Universal hash function for a 16-bit word size . . . . 24 6.1 NH-16: NH hashing with a 16-bit word size . . . . . . . . . 24 6.2 L1-HASH-16: First-layer hash . . . . . . . . . . . . . . . . 25 6.3 L2-HASH-16: Second-layer hash . . . . . . . . . . . . . . . 27 6.4 L3-HASH-16: Third-layer hash . . . . . . . . . . . . . . . . 28 6.5 UHASH-16: Three-layer universal hash . . . . . . . . . . . . 29 7 UMAC tag generation . . . . . . . . . . . . . . . . . . . . . . . 30 7.1 Interface . . . . . . . . . . . . . . . . . . . . . . . . . 30 7.2 Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . 30 8 Security considerations . . . . . . . . . . . . . . . . . . . . . 31 8.1 Resistance to cryptanalysis . . . . . . . . . . . . . . . . 31 8.2 Tag lengths and forging probability . . . . . . . . . . . . 31 8.3 Selective-assurance authentication . . . . . . . . . . . . . 33 8.4 Nonce considerations . . . . . . . . . . . . . . . . . . . . 34 8.5 Guarding against replay attacks . . . . . . . . . . . . . . 35 9 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 36 10 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 11 Author contact information . . . . . . . . . . . . . . . . . . . 37 A Suggested application programming interface (API) . . . . . . . . 38 B Reference code and test vectors . . . . . . . . . . . . . . . . . 39 Krovetz et al. Expires April 2001 [Page 1]
INTERNET-DRAFT UMAC October 2000 1 Introduction This specification describes how to generate an authentication tag (also called a "MAC") using the UMAC message authentication code. Typically the authentication tag will be transmitted along with a message and a nonce to allow the receiver of the message to verify the message's authenticity. Generation and verification of the authentication tag depends on the message, the nonce, and on a secret key (typically, shared by sender and receiver). UMAC is designed to be very fast to compute, in software, on contemporary processors. The heart of UMAC is a universal hash function, UHASH, which relies on addition and multiplication of 16-bit, 32-bit, and 64-bit numbers. These operations are supported well by contemporary machines. For many applications, especially ones with short-lived authentication needs, sufficient speed is already obtained by algorithms such as HMAC-SHA1 [2, 9] or the CBC-MAC of a block cipher [1, 8]. But for the most speed-demanding applications, UMAC may be a better choice: An optimized implementation of UMAC can achieve peak performance which is about an order of magnitude faster than what can be achieved with HMAC or CBC-MAC. Moreover, UMAC offers a tradeoff between forging probability and speed (it is possible to trade forging probability for speed). UMAC has been designed so that computing the prefix of a tag can be done faster than computing the entire tag. This feature allows for a receiver to verify the authenticity of a message to various levels of assurance depending on its needs and resources. Finally, UMAC enjoys better analytical security properties than many other constructions. Closely associated to this specification are the papers [3, 4, 10, 11]. See those papers for descriptions of the ideas which underlie this algorithm, for performance data, and for proofs of the correctness and maximal forging probability of UMAC. The UMAC algorithms described in the papers [3, 4] are "parameterized". This means that various low-level choices, like the endian convention and the underlying cryptographic primitive, have not been fixed. One must choose values for these parameters before the authentication tag generated by UMAC (for a given message, key, and nonce) becomes fully-defined. In this document we provide two collections of parameter settings, and have named the sets UMAC16 and UMAC32. The parameter sets have been chosen based on experimentation and provide good performance on a wide variety of processors. UMAC16 is designed to excel on processors which provide small-scale SIMD parallelism of the type found in Intel's MMX and Motorola's AltiVec instruction sets, while UMAC32 is designed to do well on processors Krovetz et al. Expires April 2001 [Page 2]
INTERNET-DRAFT UMAC October 2000 with good 32- and 64- bit support. UMAC32 may take advantage of SIMD parallelism in future processors. UMAC has been designed to allow implementations which accommodate "on-line" authentication. This means that pieces of the message may be presented to UMAC at different times (but in correct order) and an on-line implementation will be able to process the message correctly without the need to buffer more than a few dozen bytes of the message. For simplicity, the algorithms in this specification are presented as if the entire message being authenticated were available at once. The ideas which underlie UMAC go back to Wegman and Carter [12]. The sender and receiver share a secret key (the MAC key) which determines: * The key for a "universal hash function". This hash function is "non-cryptographic", in the sense that it does not need to have any cryptographic "hardness" property. Rather, it needs to satisfy some combinatorial property, which can be proven to hold without relying on unproven hardness assumptions. The concept of a universal hash function (family) is due to [5]. * The key for a pseudorandom function. This is where one needs a cryptographic hardness assumption. The pseudorandom function may be obtained (for example) from a block cipher or cryptographic hash function. The concept of a pseudorandom function (family) is due to [6]. To authenticate a message, Msg, one first applies the universal hash function, resulting in a string which is typically much shorter than the original message. The pseudorandom function is applied to a nonce, and the result is used in the manner of a Vernam cipher: the authentication tag is the xor of the output from the hash function and the output from the pseudorandom function. Thus, an authentication tag is generated as AuthTag = f(Nonce) xor h(Msg). Here f is the pseudorandom function shared between the sender and the receiver, and h is a universal hash function shared by the sender and the receiver. In UMAC, a shared key is used to key the pseudorandom function f, and then f is used for both tag generation and internally to generate all of the bits needed by the universal hash function. For a general discussion of the speed and assurance advantages of this approach see, for example, [3, 7]. The universal hash function that we use is called UHASH. It combines Krovetz et al. Expires April 2001 [Page 3]
INTERNET-DRAFT UMAC October 2000 several software-optimized algorithms into a multi-layered structure. The algorithm is moderately complex. Some of this complexity comes from extensive speed optimizations. For the pseudorandom function we use the block cipher of the Advanced Encryption Standard (AES). (At the time of this working draft, the AES definition process is still in progress. Here AES refers to the final blok cipher defined by this process.) Any block cipher with the same block-length (128 bits) and key-length (128 bits) could trivially be substituted in place of what we call AES. With slightly more effort one can define UMAC using a pseudorandom function other than a block cipher. One unusual feature of UMAC is that authentication-tag generation depends on a nonce (in addition to depending on the message and key) It is imperative that the nonce not be reused when generating authentication tags under the same key. Thus the nonce will normally be implemented by a counter, though any other way to achieve a non- repeating value (or almost certainly non-repeating value) is acceptable. This document specifies the procedure for generating the authentication tag from the message, key and nonce. The exact way in which the message, nonce and authentication tag are transmitted between sender and receiver is not specified here. It is the responsibility of the particular applications using UMAC to specify how the message, nonce and tag are transmitted. For example, an application may choose to send the three values concatenated by some encoding scheme while others may choose not to transmit the nonce at all if it is known to both parties (e.g., when the nonce is a shared state used to detect replay of messages), or to send only part of the bits of the nonce. Section 8 discusses security considerations that are important for the proper understanding and use of UMAC. To the authors' knowledge no ideas utilized in UMAC have been or will be patented. To the best of the authors' knowledge, it should be possible to use UMAC immediately, without any intellectual property concerns. Public-domain reference code for UMAC is available from the UMAC homepage: http://www.cs.ucdavis.edu/~rogaway/umac/ Other information, like timing data and papers, are distributed from the same URL. Krovetz et al. Expires April 2001 [Page 4]
INTERNET-DRAFT UMAC October 2000 1.1 Organization The rest of this document is organized as follows: In Section 2 parameters of the named parameter sets UMAC16 and UMAC32 are described. In Section 3 we introduce the basic notations used throughout the rest of the document. Section 4 describes the methods used for generating the Vernam pad and the pseudorandom strings needed internally for hashing. In Sections 5 and 6 the universal hash function is described. Finally, in Section 7 we describe how all these components fit together in the UMAC construction. Some readers may prefer to read sections 4-7 backwards, in order to get a top-down description. Section 8 describes some security considerations in the use of UMAC. 2 Named parameter sets: UMAC16 and UMAC32 As described in [3, 4], a concrete instantiation of UMAC requires the setting of many parameters. We have chosen two sets of values for all of these parameters which allow for good performance on a wide variety of processors. For maximum performance we offer UMAC16 which is designed to exploit the vector-parallel instructions on the Intel MMX and Motorola AltiVec instruction sets. For good performance on processors which support 32- and 64-bit quantities well, we offer UMAC32. 2.1 Named parameters Throughout the algorithms described in this document, we have integrated most of the parameters required for a concrete UMAC instantiation as unnamed numeric constants. However, we have named six parameters and assign them the following values depending on whether one wishes to use UMAC16 or UMAC32. UMAC16 UMAC32 ------ ------ WORD-LEN 2 4 UMAC-OUTPUT-LEN 8 8 L1-KEY-LEN 1024 1024 UMAC-KEY-LEN 16 16 ENDIAN-FAVORITE LITTLE LITTLE L1-OPERATIONS-SIGN SIGNED UNSIGNED Here we give a brief explanation of the role each named parameter plays. Krovetz et al. Expires April 2001 [Page 5]
INTERNET-DRAFT UMAC October 2000 WORD-LEN: Specifies the size in bytes of a "word". UMAC will be significantly faster in execution if the executing machine supports well certain operations on datatypes of this size. Note that WORD-LEN is not necessarily the native wordsize of the target machine (and on some machines a smaller value turns out to be preferable). UMAC-OUTPUT-LEN: Specifies the length of the authentication tag generated by UMAC, in bytes. L1-KEY-LEN: Specifies the "block length," in bytes, on which the hash-function initially operates. This much storage (and then some) will be needed in the run-time environment for UMAC's internal keys. UMAC-KEY-LEN: Specifies the length in bytes of the user-sup- plied UMAC key. ENDIAN-FAVORITE: Specifies which endian-orientation will be fol- lowed in the reading of data to be hashed. This need not be equal to the native endianess of any specific machine running UMAC. L1-OPERATIONS-SIGN: Specifies whether the strings manipulated in the hash-function are to be initially consid- ered as signed or unsigned integers. 2.2 Alternative instantiations Although this document only specifies two named parameter sets, the named parameters could be altered to suit specific authentication needs which are not adequately served by either UMAC16 or UMAC32. Below, we list alternatives that are supported by this specification for each of the named parameters. WORD-LEN ::= 2 | 4 UMAC-OUTPUT-LEN ::= 1 | 2 | ... | 31 | 32 L1-KEY-LEN ::= 32 | 64 | 128 | 256 | ... | 2^28 UMAC-KEY-LEN ::= 16 | 32 ENDIAN-FAVORITE ::= BIG | LITTLE L1-OPERATIONS-SIGN ::= SIGNED | UNSIGNED Roughly speaking, doubling UMAC-OUTPUT-LEN approximately doubles execution time and squares (ie. decreases) the probability of MAC Krovetz et al. Expires April 2001 [Page 6]
INTERNET-DRAFT UMAC October 2000 forgery. Setting ENDIAN-FAVORITE to BIG causes UMAC to perform better on big-endian processors rather than little-endian processors. Setting L1-OPERATIONS-SIGN to UNSIGNED slightly increases UMAC security at the expense of complicating implementations on systems which do not support unsigned integers well. This effectively disallows the use of Intel's MMX instructions which only support signed integers. Finally, increasing L1-KEY-LEN tends to speed tag generation on large messages, but requires more memory for processing and could potentially slow the processor by overflowing its cache. 2.3 Naming convention A concise shorthand may be used to specify an instance of UMAC. The word "UMAC" followed by up to six parameters specifies unambiguously an instance of UMAC. If only a prefix of the six parameters are written, it is implicitly specified that those missing parameters take on default values listed below. The format of the shorthand is "UMAC-w/l/n/k/s/e", and the meaning of the letters (and their defaults) is as follows: w = WORD-LEN (4) l = UMAC-OUTPUT-LEN (8) n = L1-KEY-LEN (1024) k = UMAC-KEY-LEN (16) s = L1-OPERATIONS-SIGN (UNSIGNED) e = ENDIAN-FAVORITE (LITTLE) Some examples UMAC-4/8/1024/16/UNSIGNED/LITTLE (Same as named set "UMAC32" ) UMAC-2/8/1024/16/SIGNED/LITTLE (Same as named set "UMAC16" ) UMAC-4/12 ("UMAC32" with 96-bit output) UMAC-2/8/4096 ("UMAC16" with 4K L1-key and) (unsigned L1-OPERATIONS ) 3 Notation and basic operations The specification of UMAC involves the manipulation of both strings and numbers. String variables are denoted with initial capitals (upper-case), whereas numeric variables are denoted in all lower- case. Global parameters are denoted in all capital letters. Simple functions, like those for string-length and string-xor, are written with all lower-case, while the algorithms of UMAC are named in all upper-case. Whenever a variable is followed by an underscore ("_"), the Krovetz et al. Expires April 2001 [Page 7]
INTERNET-DRAFT UMAC October 2000 underscore is intended to denote a subscript, with the subscripted expression needing to be evaluated to resolve the meaning of the variable. For example, if i=2, then M_{2 * i} refers to the variable M_4. We now define some basic operations for manipulating strings and numbers, and for converting between the two. 3.1 Operations on strings In this specification, we view the messages to be hashed (as well as the keys used for hashing) as strings of bytes. A "byte" is an 8-bit string. The algorithms have been designed so that they are easily extendable to allow arbitrary bit-strings, if necessary. We use the following notation to manipulate these strings. length(S): The length of string S in bytes. zeroes(n): The string made of n zero-bytes. S xor T: The string which is the bitwise exclusive-or of S and T. Strings S and T must have the same length. S and T: The string which is the bitwise conjunction of S and T. Strings S and T must have the same length. S[i]: The i-th byte of the string S (indices begin at 1). S[i..j]: The substring of S consisting of bytes i through j. S || T: The string S concatenated with string T. zeropad(S,n): The string S, padded with zero-bytes to the nearest non-zero multiple of n bytes. Formally, zeropad(S,n) = S || zeroes(i), where i is the smallest nonnegative integer such that S || zeroes(i) is non-empty and n divides length(S)+i. 3.1.1 ENDIAN-SWAP: Adjusting endian orientation This routine is used to make the data input to UMAC conform to the ENDIAN-FAVORITE global parameter. Krovetz et al. Expires April 2001 [Page 8]
INTERNET-DRAFT UMAC October 2000 3.1.1.1 Discussion The most time consuming portion of many UMAC computations involves the reading of key and message data from memory. Because big- and little-endian computers will read these bytes differently, specifying a particular endian-orientation for UMAC could have significant performance ramifications. If necessary, the key-bytes can be preprocessed once during key setup to eliminate the need for their reorientation during performance-critical tag generation. But, message data presumably cannot be preprocessed. Any reorientation needed for each message must be done during tag generation, introducing a significant penalty to computers whose native endian- orientation is opposite to that specified for UMAC. Therefore, UMAC defines a parameter, ENDIAN-FAVORITE, which allows UMAC to be specified to favor big- or little-endian memory conventions. If the parameter is set to favor little-endian computers, then we specify the reversal of the bytes of every word in the input message using the following support function. By reversing the data in the specification, an implementation on a little-endian machine would in fact do nothing but read the input data using native-endian word loads. The loads would automatically reverse the bytes within each word, fulfilling the requirements of the specification. Any other endian reorientation needed to comply with the specification requires an insignificant amount of time during each tag calculation. 3.1.1.2 Interface Function Name: ENDIAN-SWAP Input: S, string with length divisible by WORD-LEN bytes. Output: T, string S with each word endian-reversed. 3.1.1.3 Algorithm Compute T using the following algorithm. // // Break S into word-size chunks // n = length(S) / WORD-LEN Let S_1, S_2, ..., S_n be strings of length WORD-LEN bytes so that S_1 || S_2 || .. || S_n = S. // // Byte-reverse each chunk, and build-up T Krovetz et al. Expires April 2001 [Page 9]
INTERNET-DRAFT UMAC October 2000 // T = <empty string> for i = 1 to n do Let W_1, W_2, ..., W_{WORD-LEN} be bytes so that W_1 || W_2 || ... || W_{WORD-LEN} = S_i SReversed_i = W_{WORD-LEN} || W_{WORD-LEN - 1} || ... || W_1 T = T || SReversed_i Return T 3.2 Operations on integers In this specification, we generally use standard notation for 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 integer i-th power. lg a: The base-2 logarithm of integer a. floor(x): The largest integer less than or equal to x. ceil(x): The smallest integer greater than or equal to x. prime(n): The largest prime number less than 2^n. The prime numbers used in UMAC are: +-----+--------------------+---------------------------------------+ | x | prime(x) [Decimal] | prime(x) [Hexadecimal] | +-----+--------------------+---------------------------------------+ | 19 | 2^19 - 1 | 0x0007FFFF | | 32 | 2^32 - 5 | 0xFFFFFFFB | | 36 | 2^36 - 5 | 0x0000000F FFFFFFFB | | 64 | 2^64 - 59 | 0xFFFFFFFF FFFFFFC5 | | 128 | 2^128 - 159 | 0xFFFFFFFF FFFFFFFF FFFFFFFF FFFFFF61 | +-----+--------------------+---------------------------------------+ 3.3 String-Integer conversion operations We convert between strings and integers using the following functions. Each function treats initial bits as more significant than later ones. Krovetz et al. Expires April 2001 [Page 10]
INTERNET-DRAFT UMAC October 2000 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). Here n must be between 1 and the bit- length of S. 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). uint2str(n,i): The i-byte string S such that str2uint(S) = n. If no such string exists then uint2str(n,i) is unde- fined. str2sint(S): The integer whose binary representation in two's- complement is the string S. More formally, if S is t bits long then str2sint(S) = -2^{t-1} * bit(S,1) + 2^{t-2} * bit(S,2) + ... + 2^{1} * bit(S,t-1) + bit(S,t). sint2str(n,i): The i-byte string S such that str2sint(S) = n. If no such string exists then sint2str(n,i) is unde- fined. 3.4 Mathematical operations on strings One of the primary operations in the universal hashing part of UMAC is repeated application of addition and multiplication on strings. We use "+_n" and "*_n" to denote the string operations which are equivalent to addition and multiplication modulo 2^n, respectively. These operations correspond exactly with the addition and multiplication operations which are performed efficiently on registers by modern computers. So, when n is 16, 32 or 64, these operations can be preformed by computers very quickly. There are two interpretations of the operators depending on whether the strings are interpreted as signed or unsigned integers. The global parameter L1-OPERATIONS-SIGN determines which interpretation is made. If strings S and T are interpreted as signed integers (that is, L1-OPERATIONS-SIGN == SIGNED) then "S *_n T" as uint2str(str2sint(S) * str2sint(T) mod 2^n, n/8), and "S +_n T" as uint2str(str2sint(S) + str2sint(T) mod 2^n, n/8). Krovetz et al. Expires April 2001 [Page 11]
INTERNET-DRAFT UMAC October 2000 If strings S and T are interpreted as unsigned integers (that is, L1-OPERATIONS-SIGN == UNSIGNED) then we define "S *_n T" as uint2str(str2uint(S) * str2uint(T) mod 2^n, n/8), and "S +_n T" as uint2str(str2uint(S) + str2uint(T) mod 2^n, n/8). In any case, the number n must be divisible by 8. In this document we use S *_16 T, S *_32 T, S *_64 T, S +_32 T and S +_64 T, corresponding to multiplication of 2, 4 and 8 byte numbers, and the addition of 4 and 8 byte numbers. 4 Key and pad derivation functions UMAC, as described in this document, requires either a 16- or 32-byte key which is used with a key-derivation function (KDF) to produce pseudorandom bits needed within the universal hash function. 4.1 KDF: Key derivation function Stretching the user-supplied key into pseudorandom bits used internally by UMAC is done with a key-derivation function (KDF). In this section we define a KDF which is efficiently instantiated with a block cipher. The Advanced Encryption Standard (AES) is used in output-feedback mode to produce the required bits. If UMAC-KEY-LEN is 16, then the 128-bit key/128-bit block-length variant of AES is used, and if UMAC-KEY-LEN is 32, then the 256-bit key/128-bit block- length variant is used. The KDF requires an "index" parameter. Using the same key, but different indices, generates different pseudorandom outputs. 4.1.1 Interface Function Name: KDF Input: K, string of length UMAC-KEY-LEN bytes // key to AES index, a non-negative integer less than 256. numbytes, a positive integer. Output: Y, string of length numbytes bytes. Krovetz et al. Expires April 2001 [Page 12]
INTERNET-DRAFT UMAC October 2000 4.1.2 Algorithm Compute Y using the following algorithm. // // Calculate number of AES iterations, set indexed starting point // n = ceil(numbytes / 16) T = zeroes(15) || uint2str(index, 1) Y = <empty string> // // Build Y using AES in a feedback mode // for i = 1 to n do T = AES(K, T) Y = Y || T Y = Y[1..numbytes] Return Y 4.2 PDF: Pad-derivation function The Wegman-Carter MAC scheme used in UMAC requires the exclusive-or of a pseudorandom string with the output from the universal hash function. The pseudorandom string is obtained by applying a pad- derivation function (PDF) to a nonce which, for security reasons, must change with each authentication-tag computation. Nonces may be any number of bytes from 1 to 16, but all nonces in a single authentication session must be of equal length. In this section we define a PDF which is efficiently instantiated with a block cipher. Again we use AES with either 16- or 32-bytes keys depending on the value of UMAC-KEY-LEN. 4.2.1 Discussion The PDF output is exclusive-or'd with the result of the universal hash function. AES, however, may provide more or fewer bits per invocation than are needed for this purpose. For example, UMAC- OUTPUT-LEN is normally 8 bytes and AES produces an output of 16 bytes. It would save processing time if half of the AES output bits could be used to generate one tag, and then the second half of the same AES output could be used for the tag of the next message. For this reason, we include an optimization which allows the use of different substrings of the same AES output. This optimization is Krovetz et al. Expires April 2001 [Page 13]
INTERNET-DRAFT UMAC October 2000 effective only when nonces are sequential. We do so by using the low bits of the nonce as an index into the AES output, which is generated using the higher bits of the nonce which are not used for indexing. This speeds message authentication by reducing the average time spent by AES for each authentication. Note that if a counter-variable is used to exploit this optimization, and the variable is stored in memory, then the variable must be treated as big-endian. If UMAC- OUTPUT-LEN is larger than 16, then two AES invocations are required to produce a sufficient number of bits. 4.2.2 Interface Function Name: PDF Input: K, string of length UMAC-KEY-LEN bytes // key for AES Nonce, string of length 1 to 16 bytes. Output: Y, string of length UMAC-OUTPUT-LEN bytes. 4.2.3 Algorithm Compute Y using the following algorithm. // // Make Nonce 16 bytes by prepending zeroes // Nonce = Nonce || zeroes(16 - length(Nonce)) // // If one AES invocation is enough for more than one // PDF invocation. // if (UMAC-OUTPUT-LEN <= 8) then // // Compute number of index bits needed // i = floor(16 / UMAC-OUTPUT-LEN) numlowbits = floor(lg(i)) // // Extract index bits and zero low bits of Nonce // nlowbitsnum = str2uint(Nonce) mod 2^numlowbits Nonce = Nonce xor uint2str(nlowbitsnum, 16) Krovetz et al. Expires April 2001 [Page 14]
INTERNET-DRAFT UMAC October 2000 // // Generate subkey, AES and extract indexed substring // K' = KDF(K, 128, UMAC-KEY-LEN) T = AES(K', Nonce) Y = T[ nlowbitsnum * UMAC-OUTPUT-LEN + 1 .. (nlowbitsnum + 1) * UMAC-OUTPUT-LEN] else // // Repeated AES calls to build length // K_1 = KDF(K, 128, UMAC-KEY-LEN) K_2 = KDF(K, 129, UMAC-KEY-LEN) if (UMAC-OUTPUT-LEN <= 16) Y = AES(K_1, Nonce) else Y = AES(K_1, Nonce) || AES(K_2, Nonce) Y = Y[1..UMAC-OUTPUT-LEN] Return Y 5 UHASH-32: Universal hash function for a 32-bit word size UHASH is a keyed hash function, which takes as input a string of arbitrary length, and produces as output a string of fixed length (such as 8 bytes). The actual output length depends on the parameter UMAC-OUTPUT-LEN. UHASH has been shown to be epsilon-ASU ("Almost Strongly Universal"), where epsilon is a small (parameter-dependent) real number. Informally, saying that a keyed hash function is epsilon-ASU means that for any two distinct fixed input strings, the two outputs of the hash function with a random key "look almost like a pair of random strings". The number epsilon measures how non-random the output strings may be. For details, see [3, 4, 11]. UHASH has been designed to be fast by exploiting several architectural features of modern commodity processors. It was specifically designed for use in UMAC. But UHASH is useful beyond that domain, and can be easily adopted for other purposes. UHASH does its work in three layers. First, a hash function called NH [3] is used to compress input messages into strings which are typically many times smaller than the input message. Second, the compressed message is hashed with an optimized "polynomial hash Krovetz et al. Expires April 2001 [Page 15]
INTERNET-DRAFT UMAC October 2000 function" into a fixed-length 16-byte string. Finally, the 16-byte string is hashed using an "inner-product hash" into a string of length WORD-LEN bytes. These three layers are repeated (with a modified key) until the outputs total UMAC-OUTPUT-LEN bytes. Note: Because the repetitions of the three-layer scheme are independent (aside from sharing some internal key), it follows that each "word" of the final output can be computed independently. Hence, to compute a prefix of a UMAC tag, one can simply repeat the three-layer scheme fewer times. Thus, computing a prefix of the tag can be done significantly faster than computing the whole tag. 5.1 NH-32: NH hashing with a 32-bit word size The first of the three hash-layers that UHASH uses is the NH hash function [3]. More than any other part of UHASH, NH is designed to be fast on modern processors, because it is where the bulk of the UHASH work is done. The NH universal hash function hashes an input string M using a key K by considering M and K to be arrays of integers, each WORD-LEN bytes in length, and performing a sequence of arithmetic operations on them. See [3] for definitions, proofs and rationale relating to NH. The NH-32 algorithm is designed to perform well on processors which support well multiplications of 32-bit operands into 64-bit results. NH-32 is also designed to exploit the recent trend of including instructions for small-scale vector parallelism in uniprocessor CPUs. Intel's Streaming SIMD 2 instruction set is a good example of this trend. It supports an instruction, which multiplies two pairs of 32-bit operands into two 64-bit results, which can be used by UHASH-32 for accelerated hashing. To accommodate this parallelism, NH-32 accesses data-words in pairs which are 4 words (16 bytes) apart. 5.1.1 Interface Function Name: NH-32 Input: K, string of length L1-KEY-LEN bytes. M, string with length divisible by 32 bytes. Output: Y, string of length 8 bytes. Krovetz et al. Expires April 2001 [Page 16]
INTERNET-DRAFT UMAC October 2000 5.1.2 Algorithm Compute Y using the following algorithm. // // Break M and K into 4-byte chunks // t = length(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 Return Y 5.2 L1-HASH-32: First-layer hash To limit the length of key required in the first layer of hashing, L1-HASH-32 breaks the input message into chunks no longer than L1-KEY-LEN and NH hashes each with a key of the same length. 5.2.1 Discussion The NH hash function requires a key which is just as long as the message being hashed. To limit the amount of key used in the NH hashing layer, we use a key of fixed length (defined by the parameter L1-KEY-LEN), and process the message in chunks of this length (or less). The L1-HASH-32 algorithm takes an input message and breaks it into chunks of L1-KEY-LEN bytes (except the last chuck, which may be shorter and may need to be zero-padded to an appropriate length). Each chunk is hashed with NH-32, and the outputs from all the NH invocations are annotated with some length information and concatenated to produce the final L1-HASH-32 result. Krovetz et al. Expires April 2001 [Page 17]
INTERNET-DRAFT UMAC October 2000 If ENDIAN-FAVORITE is LITTLE, then each word in the input message is required to be endian reversed. 5.2.2 Interface Function Name: L1-HASH-32 Input: K, string of length L1-KEY-LEN bytes. M, string of length less than 2^64 bytes. Output: Y, string of length (8 * ceil(length(M)/L1-KEY-LEN)) bytes. 5.2.3 Algorithm Compute Y using the following algorithm. // // Break M into L1-KEY-LEN byte chunks (final chunk may be shorter) // t = ceil(length(M) / L1-KEY-LEN) Let M_1, M_2, ..., M_t be strings so that M = M_1 || M_2 || .. || M_t, and length(M_i) = L1-KEY-LEN 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(L1-KEY-LEN * 8, 8) Y = <empty string> for i = 1 to t-1 do if (ENDIAN-FAVORITE == LITTLE) then // See endian discussion ENDIAN-SWAP(M_i) // in section 3.1.1 Y = Y || (NH-32(K, M_i) +_64 Len) // // For the last chunk: pad to 32-byte boundary, endian-adjust, // NH hash and add bit-length. Concatenate the result to Y. // Len = uint2str(length(M_t) * 8, 8) M_t = zeropad(M_t, 32) if (ENDIAN-FAVORITE == LITTLE) then ENDIAN-SWAP(M_t) Y = Y || (NH-32(K, M_t) +_64 Len) return Y Krovetz et al. Expires April 2001 [Page 18]
INTERNET-DRAFT UMAC October 2000 5.3 POLY: Polynomial hash The output from L1-HASH is a string which is shorter than, but still proportional to, that of its input. The POLY hash algorithm takes an arbitrary message and hashes it to a fixed length. 5.3.1 Discussion Polynomial hashing treats an input message as a sequence of coefficients of a polynomial, and the hash-key is the point at which this polynomial is evaluated. The security guarantee assured by polynomial hashing degrades linearly in the length of the message being hashed. If two messages of n words are hashed, then the probability they collide when hashed by POLY with a prime modulus of p is no more than n / p. For more information on the polynomial hashing schemes used in UMAC see [10]. The parameter 'wordbits' specifies the prime modulus used in the polynomial as well as the granularity (length of words) in which the input message should be broken. Because some strings of length wordbits are greater than prime(wordbits), a mechanism is needed to fix words which are not in the range 0 .. prime(wordbits) - 1. To this end, any word larger than 'maxwordrange' is split into two words guaranteed to be in range, and each is hashed by the polynomial hash. 5.3.2 Interface Function Name: POLY Input: wordbits, positive integer divisible by 8. 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. 5.3.3 Algorithm Compute y using the following algorithm. // // Define constants used for fixing out-of-range words // wordbytes = wordbits / 8 Krovetz et al. Expires April 2001 [Page 19]
INTERNET-DRAFT UMAC October 2000 p = prime(wordbits) offset = 2^wordbits - p marker = p - 1 // // Break M into chunks of length wordbytes bytes // n = length(M) / wordbytes Let M_1, M_2, ..., M_n be strings of length wordbytes bytes so that M = M_1 || M_2 || .. || M_n // // For each input word, compare it with maxwordrange. If larger // then hash the words 'marker' and (m - offset), both in range. // 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 Return y 5.4 L2-HASH-32: Second-layer hash Because L1-HASH may produce quite long strings, and POLY's security guarantee degrades linearly, a scheme is required to allow long strings while ensuring that the collision probability never grows beyond a certain pre-set bound. This is accomplished by dynamically increasing the prime modulus used in the polynomial hashing as the collision probability bound is approached. 5.4.1 Discussion The probability of two n-word messages hashing to the same result when polynomially hashed with prime modulus p is as much as (n / p). To maintain a limit on the maximum collision probability, a scheme is needed to disallow (n / p) growing too large. The scheme used here hashes a number of words n_1 under modulus p_1 until (n_1 / p_1) reaches a critical point. The result of the hash-so-far is prepended to the remaining message needing to be hashed, and the hashing continues, but under a prime modulus p_2 which is substantially larger than p_1. Hashing continues for n_2 more words until (n_2 / Krovetz et al. Expires April 2001 [Page 20]
INTERNET-DRAFT UMAC October 2000 p_2) also reaches a critical point, at which time a new larger prime p_3 could be used. Because polynomial hashing under a small prime modulus is often faster than hashing under a large one, this dynamic ramping-up of the polynomial's modulus provides a hash function which is faster on short messages, but still accommodates long ones. The keys used for polynomial hashing are restricted to particular subsets to allow for faster implementations on 32-bit architectures. The restrictions allow an implementor to disregard some potential arithmetic carries during computation. For more information see [10]. 5.4.2 Interface Function Name: L2-HASH-32 Input: K, string of length 24 bytes. M, string of length less than 2^64 bytes. Output: Y, string of length 16 bytes. 5.4.3 Algorithm Compute y using the following algorithm. // // 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 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 (length(M) <= 2^17) then // 2^14 64-bit words // // View M as an array of 64-bit words, and use POLY modulo Krovetz et al. Expires April 2001 [Page 21]
INTERNET-DRAFT UMAC October 2000 // 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 .. length(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) Y = uint2str(y, 16) Return Y 5.5 L3-HASH-32: Third-layer hash The output from L2-HASH-32 is 16 bytes long. This final hash function hashes the 16-byte string to a fixed length of 4 bytes using a simple inner-product hash with affine translation. A 36-bit prime modulus is used to improve security. 5.5.1 Interface Function Name: L3-HASH-32 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. 5.5.2 Algorithm Compute Y using the following algorithm. 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] Krovetz et al. Expires April 2001 [Page 22]
INTERNET-DRAFT UMAC October 2000 m_i = str2uint(M_i) k_i = str2uint(K_i) mod prime(36) // // Inner-product hash, extract last 32 bits and affine-translate // y = (m_1 * k_1 + ... + m_8 * k_8) mod prime(36) y = y mod 2^32 Y = uint2str(y, 4) Y = Y xor K2 Return Y 5.6 UHASH-32: Three-layer universal hash The hash functions L1-HASH, L2-HASH and L3-HASH are used together in a straightforward manner. 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 L1-KEY-LEN bytes, then L2-HASH is skipped as an optimization. Because L3-HASH outputs a string whose length is only WORD-LEN bytes long, multiple iterations of this three-layer hash are used, with different keys each time, until UMAC-OUTPUT-LEN have been generated. To reduce memory requirements, L1-HASH and L3-HASH both reuse most of their key-material between iterations. 5.6.1 Interface Function Name: UHASH-32 Input: K, string of length UMAC-KEY-LEN bytes. M, string of length less than 2^64 bytes. Output: Y, string of length UMAC-OUTPUT-LEN bytes. 5.6.2 Algorithm Compute Y using the following algorithm. // // Calculate iterations needed to make UMAC-OUTPUT-LEN bytes // streams = ceil(UMAC-OUTPUT-LEN / WORD-LEN) // Krovetz et al. Expires April 2001 [Page 23]
INTERNET-DRAFT UMAC October 2000 // Define total key needed for all iterations using KDF. // L1Key and L3Key1 both reuse most key between iterations. // L1Key = KDF(K, 0, L1-KEY-LEN + (streams - 1) * 16) L2Key = KDF(K, 1, streams * 24) L3Key1 = KDF(K, 2, streams * 64) L3Key2 = KDF(K, 3, streams * 4) // // For each iteration, extract key and three-layer hash. // If length(M) <= L1-KEY-LEN, then skip L2-HASH. // Y = <empty string> for i = 1 to streams do L1Key_i = L1Key [(i-1) * 16 + 1 .. (i-1) * 16 + L1-KEY-LEN] L2Key_i = L2Key [(i-1) * 24 + 1 .. i * 24] L3Key1_i = L3Key1[(i-1) * 64 + 1 .. i * 64] L3Key2_i = L3Key2[(i-1) * 4 + 1 .. i * 4] A = L1-HASH-32(L1Key_i, M) if (length(M) <= L1-KEY-LEN) then B = zeroes(8) || A else B = L2-HASH-32(L2Key_i, A) C = L3-HASH-32(L3Key1_i, L3Key2_i, B) Y = Y || C Y = Y[1 .. UMAC-OUTPUT-LEN] Return Y 6 UHASH-16: Universal hash function for a 16-bit word size See Section 5 (UHASH-32) for general discussion of the UHASH algorithm. Each sub-section of Section 6 will note only differences between UHASH-32 and UHASH-16. 6.1 NH-16: NH hashing with a 16-bit word size The NH-16 algorithm is designed to exploit the recent trend of including instructions for small-scale vector parallelism in uniprocessor CPUs. Intel's MMX and Mororola's AltiVec instruction sets are good examples of this trend. Both support single- instruction multiply-add instructions on vectors of 16-bit words which can be used by UHASH-16 for accelerated hashing. To accommodate this parallelism, NH-16 accesses data-words in pairs which are 8 words (16 bytes) apart. Krovetz et al. Expires April 2001 [Page 24]
INTERNET-DRAFT UMAC October 2000 6.1.1 Interface Function Name: NH-16 Input: K, string of length L1-KEY-LEN bytes. M, string with length divisible by 32 bytes. Output: Y, string of length 4 bytes. 6.1.2 Algorithm Compute Y using the following algorithm. // // Break M and K into 2-byte chunks // t = length(M) / 2 Let M_1, M_2, ..., M_t be 2-byte strings so that M = M_1 || M_2 || .. || M_t. Let K_1, K_2, ..., K_t be 2-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 8 apart to accommodate vector-parallelism. // Y = zeroes(4) i = 1 while (i < t) do Y = Y +_32 ((M_{i+0} +_16 K_{i+0}) *_32 (M_{i+ 8} +_16 K_{i+ 8})) Y = Y +_32 ((M_{i+1} +_16 K_{i+1}) *_32 (M_{i+ 9} +_16 K_{i+ 9})) Y = Y +_32 ((M_{i+2} +_16 K_{i+2}) *_32 (M_{i+10} +_16 K_{i+10})) Y = Y +_32 ((M_{i+3} +_16 K_{i+3}) *_32 (M_{i+11} +_16 K_{i+11})) Y = Y +_32 ((M_{i+4} +_16 K_{i+4}) *_32 (M_{i+12} +_16 K_{i+12})) Y = Y +_32 ((M_{i+5} +_16 K_{i+5}) *_32 (M_{i+13} +_16 K_{i+13})) Y = Y +_32 ((M_{i+6} +_16 K_{i+6}) *_32 (M_{i+14} +_16 K_{i+14})) Y = Y +_32 ((M_{i+7} +_16 K_{i+7}) *_32 (M_{i+15} +_16 K_{i+15})) i = i + 16 Return Y 6.2 L1-HASH-16: First-layer hash To limit the length of key required in the first layer of hashing, L1-HASH-16 breaks the input message into chunks no longer than Krovetz et al. Expires April 2001 [Page 25]
INTERNET-DRAFT UMAC October 2000 L1-KEY-LEN bytes and NH hashes each with a key of that same length. 6.2.1 Interface Function Name: L1-HASH-16 Input: K, string of length L1-KEY-LEN bytes. M, string of length less than 2^64 bytes. Output: Y, string of length (4 * ceil(length(M)/L1-KEY-LEN)) bytes. 6.2.2 Algorithm Compute Y using the following algorithm. // // Break M into L1-KEY-LEN byte chunks (final chunk may be shorter) // t = ceil(length(M) / L1-KEY-LEN) Let M_1, M_2, ..., M_t be strings so that M = M_1 || M_2 || .. || M_t, and length(M_i) = L1-KEY-LEN 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(L1-KEY-LEN * 8, 4) Y = <empty string> for i = 1 to t-1 do if (ENDIAN-FAVORITE == LITTLE) then // See endian discussion ENDIAN-SWAP(M_i) // in section 3.1.1 Y = Y || (NH-16(K, M_i) +_32 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(length(M_t) * 8, 4) M_t = zeropad(M_t, 32) if (ENDIAN-FAVORITE == LITTLE) then ENDIAN-SWAP(M_t) Y = Y || (NH-16(K, M_t) +_32 Len) return Y Krovetz et al. Expires April 2001 [Page 26]
INTERNET-DRAFT UMAC October 2000 6.3 L2-HASH-16: Second-layer hash L2-HASH-16 differs from L2-HASH-32 by beginning the ramped hash with a smaller prime modulus. See Section 5.3 for the definition of POLY. 6.3.1 Interface Function Name: L2-HASH-16 Input: K, string of length 28 bytes. M, string of length less than 2^64 bytes. Output: Y, string of length 16 bytes. 6.3.2 Algorithm Compute Y using the following algorithm. // // Extract keys and restrict to special key-sets // Mask32 = uint2str(0x1fffffff, 4) Mask64 = uint2str(0x01ffffff01ffffff, 8) Mask128 = uint2str(0x01ffffff01ffffff01ffffff01ffffff, 16) k_32 = str2uint(K[1..4] and Mask32) k64 = str2uint(K[5..12] and Mask64) k128 = str2uint(K[13..28] and Mask128) // // If M no more than 2^11 bytes, hash under 32-bit prime. // Otherwise, hash under increasingly long primes. // if (length(M) <= 2^11) then // 2^9 32-bit words y = POLY(32, 2^32 - 6, k_32, M) else if (length(M) <= 2^33) then // 2^31 32-bit words M_1 = M[1 .. 2^11] M_2 = M[2^11 + 1 .. length(M)] M_2 = zeropad(M_2 || uint2str(0x80,1), 8) y = POLY(32, 2^32 - 6, k_32, M_1) y = POLY(64, 2^64 - 2^32, k64, uint2str(y, 8) || M_2) else Krovetz et al. Expires April 2001 [Page 27]
INTERNET-DRAFT UMAC October 2000 M_1 = M[1 .. 2^11] M_2 = M[2^11 + 1 .. 2^33] M_3 = M[2^33 + 1 .. length(M)] M_3 = zeropad(M || uint2str(0x80,1), 16) y = POLY(32, 2^32 - 6, k_32, M_1) y = POLY(64, 2^64 - 2^32, k64, uint2str(y, 8) || M_2) y = POLY(128, 2^128 - 2^96, k128, uint2str(y, 16) || M_3) Y = uint2str(y, 16) Return Y 6.4 L3-HASH-16: Third-layer hash The L3-HASH-16 algorithm differs from L3-HASH-32 by hashing under a 19-bit prime modulus (instead of a 36-bit prime modulus) and then returning a 2-byte result (instead of a 4-byte result). 6.4.1 Interface Function Name: L3-HASH-16 Input: K1, string of length 32 bytes. K2, a string of length 2 bytes. M, a string of length 16 bytes. Output: Y, a string of length 2 bytes. 6.4.2 Algorithm Compute Y using the following algorithm. 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) * 4 + 1 .. i * 4] m_i = str2uint(M_i) k_i = str2uint(K_i) mod prime(19) // Krovetz et al. Expires April 2001 [Page 28]
INTERNET-DRAFT UMAC October 2000 // Inner-product hash, extract last 32 bits and affine-translate // y = (m_1 * k_1 + ... + m_8 * k_8) mod prime(19) y = y mod 2^16 Y = uint2str(y, 2) Y = Y xor K2 Return Y 6.5 UHASH-16: Three-layer universal hash The algorithm UHASH-16 differs from UHASH-32 only in the size of its keys generated, and in that it refers to the 16-bit variants of the three-layer hash functions. 6.5.1 Interface Function Name: UHASH-16 Input: K, string of length UMAC-KEY-LEN bytes. M, string of length less than 2^64 bytes. Output: Y, string of length UMAC-OUTPUT-LEN bytes. 6.5.2 Algorithm Compute Y using the following algorithm. // // Calculate iterations needed to make UMAC-OUTPUT-LEN bytes // streams = ceil(UMAC-OUTPUT-LEN / WORD-LEN) // // Define total key needed for all iterations using KDF. // L1Key and L3Key1 both reuse most key between iterations. // L1Key = KDF(K, 0, L1-KEY-LEN + (streams - 1) * 16) L2Key = KDF(K, 1, streams * 28) L3Key1 = KDF(K, 2, streams * 32) L3Key2 = KDF(K, 3, streams * 2) // // For each iteration, extract key and three-layer hash. Krovetz et al. Expires April 2001 [Page 29]
INTERNET-DRAFT UMAC October 2000 // If length(M) <= L1-KEY-LEN, then skip L2-HASH. // Y = <empty string> for i = 1 to streams do L1Key_i = L1Key [(i-1) * 16 + 1 .. (i-1) * 16 + L1-KEY-LEN] L2Key_i = L2Key [(i-1) * 28 + 1 .. i * 28] L3Key1_i = L3Key1[(i-1) * 32 + 1 .. i * 32] L3Key2_i = L3Key2[(i-1) * 2 + 1 .. i * 2] A = L1-HASH-16(L1Key_i, M) if (length(M) <= L1-KEY-LEN) then B = zeroes(12) || A else B = L2-HASH-16(L2Key_i, A) C = L3-HASH-16(L3Key1_i, L3Key2_i, B) Y = Y || C Y = Y[1 .. UMAC-OUTPUT-LEN] Return Y 7 UMAC tag generation Tag generation for UMAC proceeds as follows. Use UHASH to hash the message and apply the PDF to the nonce to produce a string to xor with the UHASH output. The resulting string is the authentication- tag. 7.1 Interface Function Name: UMAC Input: K, string of length UMAC-KEY-LEN bytes. M, string of length less than 2^64 bytes. Nonce, string of length 1 to 16 bytes. Output: AuthTag, string of length UMAC-OUTPUT-LEN bytes. 7.2 Algorithm Compute AuthTag using the following algorithm. if (WORD-LEN == 2) then HashedMessage = UHASH-16(K, M) else HashedMessage = UHASH-32(K, M) Krovetz et al. Expires April 2001 [Page 30]
INTERNET-DRAFT UMAC October 2000 Pad = PDF(K, Nonce) AuthTag = Pad xor HashedMessage Return AuthTag 8 Security considerations As a specification of a message authentication code, this entire document is about security. Here we describe some security considerations important for the proper understanding and use of UMAC. 8.1 Resistance to cryptanalysis 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 it is assumed that both operations are implemented using the Advanced Encryption Standard (AES). However, the full design and specification allow for the replacement of these components. Indeed, it is straightforward to use other block ciphers or other cryptographic objects, such as SHA-1 or HMAC for the realization of the KDF or PDF. The core of the UMAC design, the UHASH function, does not depend on any "cryptographic assumptions": its strength is specified by a purely mathematical property stated in terms of collision probability, and this property is proven in an absolute sense. In this way, the strength of UHASH is guaranteed regardless of future advances in cryptanalysis. The analysis of UMAC [3, 4] 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 which forges with probability significantly exceeding the established collision probability will give rise to an attack of comparable complexity which breaks the AES, in the sense of distinguishing AES from a family of random permutations. This design approach essentially obviates the need for cryptanalysis on UMAC: cryptanalytic efforts might as well focus on AES, the results imply. 8.2 Tag lengths and forging probability A MAC algorithm is used between two parties that share a secret MAC key, K. Messages transmitted between these parties are accompanied by authentication tags computed using K and a given nonce. Breaking Krovetz et al. Expires April 2001 [Page 31]
INTERNET-DRAFT UMAC October 2000 the MAC means that the attacker is able to generate, on its own, a new message M (i.e. one not previously transmitted between the legitimate parties) and to compute on M a correct authentication tag under the key K. This is called a forgery. Note that if the authentication tag is specified to be of length t then the attacker can trivially break the MAC with probability 1/2^t. For this the attacker can just generate any message of its choice and try a random tag; obviously, the tag is correct with probability 1/2^t. By repeated guesses the attacker can increase linearly its probability of success. UMAC is designed to make this guessing strategy the best possible attack against UMAC as long as the attacker does not invest the computational effort needed to break the underlying cipher, e.g. AES, used to produce the one time pads used in UMAC computation. More precisely, under the assumed strength of this cipher UMAC provides for close-to-optimal security with regards to forgery probability as represented in the next table. -------------------------------------------------------------------- UHASH-OUTPUT-LEN Forging probability Approximate actual forging (bytes) using a random tag probability in UMAC (using a clever tag) 2 2^-16 2^-15 4 2^-32 2^-30 8 2^-64 2^-60 16 2^-128 2^-120 -------------------------------------------------------------------- Recall that the parameter UHASH-OUTPUT-LEN specifies the length of the UMAC authentication tag. The above table states, for example, for the case of an 8-byte tag that the ideal forging probability would be 2^-64 while UMAC would withstand an actual forging probability of 2^-60. Note that under this tag length (which is the default length in UMAC) the probability of forging a message is well under the chance that a randomly guessed DES key is correct. DES is now widely seen as vulnerable, but the problem has never been that some extraordinarily lucky attacker might, in a single guess, find the right key. Instead, the problem is that large amounts of computation can be thrown at the problem until, off-line, the attacker finds the right key. With UMAC, off-line computation aimed at exceeding the forging probability is hopeless, regardless of tag length, as long as the underlying cipher is not broken. The only way to forge is to interact with the entity that verifies the MAC and to try a huge amount of forgeries before one is likely to succeed. The system Krovetz et al. Expires April 2001 [Page 32]
INTERNET-DRAFT UMAC October 2000 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. Let us reemphasize: a forging probability of 1 / 2^60 does not mean that there is an attack that runs in 2^60 time - as long as AES maintains its believed security there is no such attack for UMAC. Instead, a 1 / 2^60 forging probability means that if an attacker could try out 2^60 MACs, then the attacker would probably get one right. But the architecture of any real system should render this infeasible. One can certainly imagine an attacker having a high bandwidth channel (e.g., 1 Gbit/second or more) over which it can continually present attempted forgeries, the attacker being signaled when a correct tag is found, but realizing such a scenario in a real system would represent a major lapse in the security architecture. It should be pointed out that once an attempted forgery is successful, it is entirely possible that all subsequent messages under this key may be forged, too. This is important to understanding in gauging the severity of a successful forgery. In conclusion, the default 64-bit tags seem appropriate for most security architectures and applications. In cases where when the consequences of an authentication failure are not extremely severe, and when the system architecture is designed to conscientiously limit the number of forgery attempts before a session is torn down, 32-bit authentication tags may be adequate. For the paranoid, or if an attacker is allowed a fantastic number of forgery tests, 96- or 128-bits may be utilized. 8.3 Selective-assurance authentication We have already remarked about the flexibility built into UMAC to use authentication tags of various lengths: shorter tags are faster to compute and one needs to transmit fewer bits, but the forging probability is higher. There is an additional degree of flexibility built into the design of UMAC: even if the sender generates and transmits a tag of 8 bytes, say, a receiver may elect to verify only the first 4 bytes of the tag, and computing that 4-byte prefix by the receiver will be substantially faster than computing what the full 8-byte tag would be. Indeed when WORD-LEN is 2 one can more quickly check the 2-byte prefix of the tag than the 4-byte prefix of the tag, one can more quickly check the 4-byte prefix of the tag than the Krovetz et al. Expires April 2001 [Page 33]
INTERNET-DRAFT UMAC October 2000 6-byte prefix of the tag, and so forth. When WORD-LEN is 4 one can more quickly check the 4-byte prefix of the tag than an entire 8-byte tag, and so forth. This type of flexibility allows different parties who receive a MAC (as in a multicast setting) to authenticate the transmission to the extent deemed necessary and to the extent consistent with any computational limits of the receiver. In a scenario where receivers are allowed to verify short prefixes of longer tags, it is even more important that conservative policies are followed when a bad tag is presented to the receiver. Because short prefixes are easier to forge than are long ones, an attacker may attempt to forge short prefixes and then leverage information gained from these attacks to forge longer tags. If the attacker can learn which short tags are good and which are bad, the attacker may be able to learn enough to allow longer forgeries. One salient feature of the security-performance trade-off offered by UMAC is its usability in contexts where performance is severely constrained. In such cases, using a mild-security authentication tag can be of significant value especially if the alternative would be not to use authentication at all (a possible such scenario could be the high-speed transmission of real-time multimedia streams). Another potential scenario where short and fast-to-compute tags can be useful is for fast detection of data forgery intended as a denial of service attack. In this case, even a moderate increase in the attacker's difficulty to produce forgeries may suffice to make the attack worthless for the attacker. Moreover, being able to detect just a portion of attempted forgeries may be enough to identify the attack. 8.4 Nonce considerations The function UMAC (Section 7) requires a nonce with length in the range 1 to 16 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. To authenticate messages over a duplex channel (where two parties send messages to each other), a different key could be used for each direction. If the same key is used in both directions, then it is crucial that all nonces be distinct. For example, one party can use even nonces while the other party uses odd ones. The receiving party must verify that the sender is using a nonce of the correct form. This specification does not indicate how nonce values are created, updated, or communicated between the entity producing a tag and the entity verifying a tag. The following exemplify some of the Krovetz et al. Expires April 2001 [Page 34]
INTERNET-DRAFT UMAC October 2000 possibilities: 1. The nonce is an eight-byte [resp., four-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 [resp., 2^32] messages within a session. 2. The nonce is a 16-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. 3. The nonce is a 16-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).) 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. The application will then specify how to construct the nonce from this already-existing field. Note that if the nonce starts at zero and is incremented with each message then an attacker can easily ascertain the number of messages which have been sent during a session. If this is information which one wishes to deny the attacker then one might have the sender initialize the nonce to a random value, rather than to zero. Inspecting the current nonce will no longer reveal to the attacker the number of messages which have been sent during this session. This is a computationally cheaper approach than enciphering the nonce. 8.5 Guarding against replay attacks A replay attack entails the attacker repeating a message, nonce, and authentication tag. In systems, replay attacks may be quite damaging, and many applications will want to guard against them. 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 Krovetz et al. Expires April 2001 [Page 35]
INTERNET-DRAFT UMAC October 2000 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 and tag 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. 9 Acknowledgments Thanks are due to David Balenson and David Carman of NAI Labs, who suggested the advantages of allowing a receiver to verify authentication tags to various forgery probabilities. Thanks are also due to David McGrew and Scott Fluhrer of Cisco Systems for encouraging us to improve UMAC performance on short messages. Phillip Rogaway, John Black, and Ted Krovetz were supported in this work under Rogaway's NSF CAREER Award CCR-962540, and under MICRO grants 97-150, 98-129, and 99-103 funded by RSA Data Security, Inc., and ORINCON Corporation. Much of Rogaway's work was carried out during two sabbatical visits to Chiang Mai University. Special thanks to Prof. Darunee Smawatakul for helping to arrange these visits. 10 References [1] ANSI X9.9, "American National Standard for Financial Institution Message Authentication (Wholesale)", American Bankers Association, 1981. Revised 1986. [2] M. Bellare, R. Canetti, and H. Krawczyk, "Keyed hash functions and message authentication", Advances in Cryptology - CRYPTO '96, LNCS vol. 1109, pp. 1-15. Full version available from http://www.research.ibm.com/security/keyed-md5.html/ [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. Full version available from http://www.cs.ucdavis.edu/~rogaway/umac [4] J. Black, S. Halevi, H. Krawczyk, T. Krovetz, and P. Rogaway, "The UMAC message authentication code", work in progress, 2000. Krovetz et al. Expires April 2001 [Page 36]
INTERNET-DRAFT UMAC October 2000 To be available from http://www.cs.ucdavis.edu/~rogaway/umac [5] L. Carter and M. Wegman, "Universal classes of hash functions", Journal of Computer and System Sciences, 18 (1979), pp. 143-154. [6] O. Goldreich, S. Goldwasser and S. Micali, "How to construct random functions", Journal of the ACM, 33, No. 4 (1986), pp. 210-217. [7] S. Halevi and H. Krawczyk, "MMH: Software message authentication in the Gbit/second rates", Fast Software Encryption, LNCS Vol. 1267, Springer-Verlag, pp. 172-189, 1997. [8] ISO/IEC 9797-1, "Information technology - Security techniques - Data integrity mechanism using a cryptographic check function employing a block cipher algorithm", International Organization for Standardization, 1999. [9] H. Krawczyk, M. Bellare, and R. Canetti, "HMAC: Keyed-hashing for message authentication", RFC-2104, February 1997. [10] T. Krovetz, and P. Rogaway, "Fast universal hashing with small keys and no preprocessing", work in progress, 2000. To be available from http://www.cs.ucdavis.edu/~rogaway/umac [11] T. Krovetz, and P. Rogaway, "Variationally universal hashing", work in progress, 2000. To be available from http://www.cs.ucdavis.edu/~rogaway/umac [12] 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. 11 Author contact information Authors' Addresses John Black Department of Computer Science University of Nevada Reno NV 89557 USA EMail: jrb@cs.unr.edu Shai Halevi Krovetz et al. Expires April 2001 [Page 37]
INTERNET-DRAFT UMAC October 2000 IBM T.J. Watson Research Center P.O. Box 704 Yorktown Heights NY 10598 USA EMail: shaih@watson.ibm.com Alejandro Hevia Department of Computer Science & Engineering University of California at San Diego La Jolla CA 92093 USA EMail: ahevia@cs.ucsd.edu Hugo Krawczyk Deprtment of Electrical Engineering Technion Haifa 32000 ISRAEL EMail: hugo@ee.technion.ac.il Ted Krovetz Intel Corporation 1900 Prairie City Road Folsom CA 95630 USA EMail: tdk@acm.org Phillip Rogaway Department of Computer Science University of California Davis CA 95616 USA EMail: rogaway@cs.ucdavis.edu A Suggested application programming interface (API) /* umac.h */ typedef struct UMAC_CTX *umac_ctx_t; umac_ctx_t umac_alloc(char key[]); /* Dynamically allocate UMAC_CTX struct */ Krovetz et al. Expires April 2001 [Page 38]
INTERNET-DRAFT UMAC October 2000 /* initialize variables and generate */ /* subkeys for default parameters. */ int umac_free(umac_ctx_t ctx); /* Deallocate the context structure. */ int umac_set_params(umac_ctx_t ctx, void *params); /* After default initialization, */ /* optionally set parameters to */ /* different values and reset for */ /* new message. */ int umac_update(umac_ctx_t ctx, char *input, long len); /* Incorporate len bytes pointed to by */ /* input into context ctx. */ int umac_final(umac_ctx_t ctx, char tag[], char nonce[]); /* Incorporate nonce value and return */ /* tag. Reset ctx for next message. */ int umac(umac_ctx_t ctx, char *input, long len, char tag[], char nonce[]); /* All-in-one (non-incremental) */ /* implementation of the functions */ /* umac_update() and umac_final(). */ Each routine returns zero if unsuccessful. B Reference code and test vectors See the UMAC World Wide Web homepage for reference code and test vectors. http://www.cs.ucdavis.edu/~rogaway/umac/ Krovetz et al. Expires April 2001 [Page 39]