UMAC


In cryptography, a message authentication code based on universal hashing, or UMAC, is a type of message authentication code calculated choosing a hash function from a class of hash functions according to some secret process and applying it to the message. The resulting digest or fingerprint is then encrypted to hide the identity of the hash function used. As with any MAC, it may be used to simultaneously verify both the data integrity and the authenticity of a message.
A specific type of UMAC, also commonly referred to just UMAC, is specified in RFC 4418, it has provable cryptographic strength and is usually a lot less computationally intensive than other MACs. UMAC's design is optimized for 32-bit architectures with SIMD support, with a performance of 1 CPU cycle per byte with SIMD and 2 cpb without SIMD. A closely related variant of UMAC that is optimized for 64-bit architectures is given by VMAC, which has been submitted to the IETF as a draft but never gathered enough attention for becoming a standardized RFC.

Background

Universal hashing

Let's say the hash function is chosen from a class of hash functions H, which maps messages into D, the set of possible message digests. This class is called universal if, for any distinct pair of messages, there are at most |H|/|D| functions that map them to the same member of D.
This means that if an attacker wants to replace one message with another and, from his point of view the hash function was chosen completely randomly, the probability that the UMAC will not detect his modification is at most 1/|D|.
But this definition is not strong enough — if the possible messages are 0 and 1, D= and H consists of the identity operation and not, H is universal. But even if the digest is encrypted by modular addition, the attacker can change the message and the digest at the same time and the receiver wouldn't know the difference.

Strongly universal hashing

A class of hash functions H that is good to use will make it difficult for an attacker to guess the correct digest d of a fake message f after intercepting one message a with digest c. In other words,
needs to be very small, preferably 1/|D|.
It is easy to construct a class of hash functions when D is field. For example, if |D| is prime, all the operations are taken modulo |D|. The message a is then encoded as an n-dimensional vector over D. H then has |D|n+1 members, each corresponding to an -dimensional vector over D. If we let
we can use the rules of probabilities and combinatorics to prove that
If we properly encrypt all the digests, an attacker cannot learn anything from them and the same hash function can be used for all communication between the two parties. This may not be true for ECB encryption because it may be quite likely that two messages produce the same hash value. Then some kind of initialization vector should be used, which is often called the nonce. It has become common practice to set h0 = f, where f is also secret.
Notice that having massive amounts of computer power does not help the attacker at all. If the recipient limits the amount of forgeries it accepts, |D| can be 232 or smaller.

Example

The following C function generates a 24 bit UMAC. It assumes that secret is a multiple of 24 bits, msg is not longer than secret and result already contains the 24 secret bits e.g. f. nonce does not need to be contained in msg.

/* DUBIOUS: This does not seem to have anything to do with the RFC
* definiton. This is probably an example for the general UMAC concept.
* Who the heck from 2007 chooses 3 bytes in an example?
*
* We gotta move this along with a better definition of str. uni. hash into
* uni. hash. */
  1. define uchar uint8_t
void UHash24


  1. define uchar uint8_t
  2. define swap32 << 24 | << 8 | >> 8 | >> 24)
/* This is the same thing, but grouped up.
It is still bad and nobody has explained why it's strongly universal. */
void UHash24Ex

NH and the RFC UMAC

NH

Functions in the above unnamed strongly universal hash-function family uses n multiplies to compute a hash value.
The NH family halves the number of multiplications, which roughly translates to a two-fold speed-up in practice. For speed, UMAC uses the NH hash-function family. NH is specifically designed to use SIMD instructions, and hence UMAC is the first MAC function optimized for SIMD.
The following hash family is -universal:
where
Practically, NH is done in unsigned integers. All multiplications are mod 2^w, all additions mod 2^w/2, and all inputs as are a vector of half-words. The algorithm will then use multiplications, where was the number of half-words in the vector. Thus, the algorithm runs at a "rate" of one multiplication per word of input.

RFC 4418

RFC 4418 does a lot to wrap NH to make it a good UMAC. The overall UHASH routine produces a variable length of tags, which corrsponds to the number of iterations needed in all three layers of its hashing. Several calls to an AES-based key derivation function is used to provide keys for all three keyed hashes.
In RFC 4418, NH is rearranged to take a form of:
Y = 0
for do
Y = Y +_64 *_64 )
Y = Y +_64 *_64 )
Y = Y +_64 *_64 )
Y = Y +_64 *_64 )
end for
This definition is designed to encourage programmers to use SIMD instructions on the accumulation, since only data with four indices away are likely to not be put in the same SIMD register, and hence faster to multiply in bulk. On a hypothetical machine, it could simply translate to:

movq $0, regY ; Y = 0
movq $0, regI ; i = 0
loop:
add     reg1, regM, regI ; reg1 = M + i
add     reg2, regM, regI
vldr.4x32 vec1, reg1 ; load 4x32bit vals from memory *reg1 to vec1
vldr.4x32 vec2, reg2
vmul.4x64   vec3, vec1, vec2 ; vec3 = vec1 * vec2
uaddv.4x64 reg3, vec3 ; horizontally sum vec3 into reg3
add regY, regY, reg3 ; regY = regY + reg3
add regI, regI, $8
cmp regI, regT
jlt loop