# Should HMAC-SHA3 be preferred over H(C(k,M))?

If I understand correctly SHA-3 (Keccak) is resistant against more attacks than SHA-2. This would make it possible - again if I understand correctly - to use SHA-3 with a simpler scheme than HMAC.

Would there still be a reason to use the HMAC construction with SHA-3? Would it be a better idea to simply use $H(C(k, M))$ where $H$ is simply SHA-3 and $C$ is a function to create a canonical representation (encoding) of the key $k$ and the message $M$ to set them apart?

Of course I imagine that HMAC-SHA3 will be used in the majority of protocols anyway as SHA-3 was created as a drop in replacement of SHA-2. But is there any security related reason to use HMAC-SHA3 over an (even) simpler scheme?

HMAC does not provide an obvious security improvement over the KMAC construction, which is optimal for Keccak based functions. HMAC is designed to create a secret initialization vector or IV for Merkle-Damgård type hash functions, KMAC does the same for sponge based hash functions but much more efficiently. HMAC also needs to deal with the length extension property

KMAC extends the key to the block size and prepends it to the message. I believe this will be standardized (if it has not already) as the default MAC construction for SHA-3. Because it extends the key to the block size, an F iteration is performed over the key prior to message absorption, creating a secret keyed state.

This is the basic sponge MAC construction discussed during the Keccak design phase, and in later discussion of both Keccak and SHA-3. There needs to be some kind of encoding or padding to effectively separate keys of different sizes, but this is not discussed in those documents; the $C$ function you mention would perform such separation. KMAC as discussed during the August 2014 SHA-3 workshop shortly after the publication of FIPS 202 uses the "keypack" function to pad the key and encode the byte-length of the key block as an 8-bit value, using a minimum of 9 additional bits beyond the length of the key: $\operatorname{Keypack}(K, l) = \operatorname{enc}(l /8) | K | 1 0 ^{l-\operatorname{len}(K)-9}$ where $l$ is the block size.

The "block size" of SHA-3 is at least 576 bits for all variants, meaning a 512-bit key can key the state with only one additional iteration of $f$. Additionally, since there is no block or bit counters, a device with low computational resources but enough memory can simply keep the keyed state as its default state for MAC computations and suffer no performance hit when compared to plain hashing.

Update: Since this answer was originally written, NIST has published SP 800-185 standardizing KMAC and a few other useful Keccak-derived constructions.

• "KMAC extends the key to the block size with 0-padding" Does that mean that they don't have a disambiguation for different key lengths? – CodesInChaos May 7 '16 at 14:12
• Could you add a reference for KMAC? The Keccak site and paper speak of simply prepending the key, with no mention of padding. – otus May 7 '16 at 18:41
• @CodesInChaos The PDF I found here specifies: $\operatorname{Keypack}(K, l) = \operatorname{enc}(l /8) | K | 1 0 ^{l-\operatorname{len}(K)-9}$ (after which the message follows), but I'm not 100% sure that this is the KMAC under consideration. So basically key length, key, bit padding up to one "block", and then finally the message. The first block and/or the intermediate value could be cached that way. – Maarten Bodewes May 7 '16 at 20:44
• @MaartenBodewes Crucially that includes a 1 bit as part of the padding, removing the ambiguity. (Unlike plain zero padding) – CodesInChaos May 7 '16 at 22:21
• I have found several references to KMAC with and without keylength encoding, and with and without a padding scheme, most likely by omission because a length or padding is needed for domain separation, I will update and elaborate the post – Richie Frame May 8 '16 at 4:35

You're essentially asking if SHA-3 can use a keyed hash instead of an HMAC.

The short answer is yes. But there's more to it than that.

In the SHA-3 competition, two of the finalists (Keccak and Skein) were specifically designed to have a one-pass MAC as part of their design, and that's what the answer above is giving about Keccak. KMAC is Keccak's one-pass MAC. Skein also has a one-pass MAC. It's a fine answer — really, you ought to use KMAC rather than either a keyed hash or HMAC because KMAC has security proofs over a keyed hash and it's faster than HMAC. But that isn't the question you asked, you asked about keyed hashes.

But any of the five finalists are collision resistant enough that a keyed hash is likely to be as good as HMAC. In that word "likely" is presuming that they're as collision-resistant as presently thought. HMAC is a construction that protects against certain types of flaws in a hash function, but what that actually means is a huge discussion that you didn't ask about.

If you're going to do a keyed hash function, you should hash . I am presuming that your message has been canonicalized in whatever way you want. You want to hash the key before the message and the length of each field before the field because assuming hash flaws (like those that exist in Merkle-Damgård constructions), that puts the important things where they're less vulnerable to collision issues, and collisions are much harder.

The bottom line is that if you're going to use SHA-3, you should use KMAC. If you're using an HMAC, yes, you can drop-in-replace an older function with SHA-3 and that's even better. And yes, if you use a modern hash function like any of the SHA-3 finalists with a keyed hash, it can be as good as either.

— Jon (Skein co-author)

• Hi Jon, thanks for the additional info. I've got a question though. You seem to compare a keyed hash vs a one-pass MAC. I'm not sure of the difference. I mean, HMAC, KMAC and most other hashes are single pass, right? The fact that the key is used twice in HMAC should not change that. So in my understanding KMAC is both a keyed hash and a one-pass MAC. Is it possible for you to clear this up for me? – Maarten Bodewes May 10 '16 at 17:36
• They can be equivalent. It's better if I talk about Skein because I know it. The details may be different, but the principle is the same in Keccak. It is useful to take different uses of the hash function and force them into different domains. Skein defined a bunch of domains, and these are really just a tag that gets mixed into the hash function. Consider this to be a salt. So a one-pass MAC of K,M will be a different output value than the MAC. Every time you hash X, you are implicitly hashing Tag,X. There's just a different tag for a MAC and a hash. – Jon Callas May 10 '16 at 21:20
• The reason this is important is that there's a tacit collision between K,M and a message that happens to be K,M by chance. This is why the One-Pass-MAC feature of the function is better than a keyed hash. There's no tacit collision possible, and thus no accidental leaks. Does this make sense? – Jon Callas May 10 '16 at 21:26
• Yes it does. But that means a separate configuration option (the "salt") which needs to be supported by an implementation, right? Sorry for the slow response my laptop is drying after I spilled beer over it. – Maarten Bodewes May 10 '16 at 21:44
• Or that it's built into the algorithm itself, one way or another. SHA-3 is calling these things "domain separation" and also has "customization strings" that serve these purposes. Domain separation is the generic term. Look at John Kelsey's slides here: csrc.nist.gov/news_events/cif_2015/research/… – Jon Callas May 11 '16 at 0:13