UMAC: to what extent is it in use today?

Question

Inspired slightly by the Encrypt-then-MAC question. The most obvious message authentication code is probably HMAC or RFC 2104 which is basically a hash of the input, an xor with a key... you get the idea.

However, I've also discovered UMAC which sounds very much like a hash function/lookup table to select an appropriate hash for use in a MAC, via, crucially, "some secret process".

Is selecting an algorithm secretly in this way secure? Is the only secret in UMAC the algorithm in use, or does it combine some known secret as HMAC does? In other words, is it HMAC with a random H?

Finally, is this being used anywhere? HMAC has its own RFC whereas UMAC does not appear to have yet been so well adopted.

Answer 1

UMAC is described in full details in RFC 4418.

When the RFC talks about "secret selection", it really means "there is a secret key involved here". UMAC works with universal hashing, which can be viewed as a family of hash functions, and a key which selects which hash function we are talking of. The term "hash function" might be a bit confusing here, because this is not at all the same kind of beast than, say, SHA-256. These "hash functions" would be utterly weak if left alone in the wild.

So UMAC works like this:

• There is a nonce which must be used only once; for each new message a new nonce value must be selected (this is extremely important).
• There are two keys $K_1$ and $K_2$. $K_1$ selects the universal hash function $h$ in its family, while $K_2$ is used in a suitable function which can operate on a block; namely, the AES or another block cipher.
• The input message is processed with $h$, and the output of $h$ is then encrypted by XORing it with $\mathrm{AES}_{K_2}$ (nonce)_.

The idea is that the hash function $h$ (selected by $K_1$) remains "hidden" by the final encryption. Thanks to the nonce, and assuming that the final encryption is decent, successively MACed messages leak no information whatsoever on $h$ to the attacker. This is valid even in the presence of a very lightweight $h$, much faster than a conventional hash function.

UMAC is not much used by itself, because it is quite recent, and the nonce is a hard requirement, quite similar to IV management for block ciphers. HMAC is much easier, in the sense that it is much harder to get it wrong. UMAC or UMAC-like systems are however quite popular when integrated with encryption, because the nonce/IV requirement can then be shared. This is how OCB and GCM work, for instance.

Answer 2

This doesn't exactly address the question, but I thought I would toss my hat into the ring: HMAC uses crypto hash functions like MD5, SHA1, etc. Those are (relatively) slow.

There is another class of MACs that use Universal Hash Function families. These families are not cryptographic; they have a simple combinatorial property, and so they tend to be much faster than a crypto hash function. At the heart of UMAC is the family NH which was tuned to run fast on commodity processors and run blistering fast on processor with SIMD instructions. Poly1305 is another very fast hash family that does better or worse than NH depending on platform details.

As Thomas points out, a hash family by itself is easy to break (ie, easy to forge messages against), so you have to do some simple post-processing (like run AES on it, eg), but in general these things are still much faster than HMAC which has to use two calls to a crypto hash function.

And yes, the universal-hash-based MACs like NH (UMAC), and Poly1305 aren't widely used because they are newfangled compared to old workhorses like CBCMAC.

Answer 3

By the way, if you're interested in UMAC, you may also be interested in VMAC, Poly1305, or Badger. If I had to choose one MAC to use today, without doing any further research on it, I would use Poly1305.