10
$\begingroup$

I am planning to implement a MAC function for the SHA3. I read that its latest variant is KMAC. I am confused by the comments in the http://keccak.noekeon.org/ website. Its says...

Unlike SHA-1 and SHA-2, Keccak does not have the length-extension weakness, hence does not need the HMAC nested construction. Instead, MAC computation can be performed by simply prepending the message with the key.

Also

KMAC is a keyed hash function or pseudo-random function (PRF) that can be used, e.g., to compute a message authentication code (MAC) or to derive a session key from a master key. It is more efficient than HMAC by removing the need for HMAC's nested construction.

So if I want to implement a MAC function Can i just do the first method ?? just pad the message with key and do the hash ? Or do I need to follow the KMAC steps?

KMAC128(K, X, L, S): Validity Conditions: $len(K) < 2^{2040}$ and $0 \leq L < 2^{2040}$ and $len(S) < 2^{2040}$

  1. newX = bytepad(encode_string(K), 168) || X || right_encode(L).
  2. return cSHAKE128(newX, L, “KMAC”, S). Could anyone help ? which method we should use
Improve this question
$\endgroup$
6
  • 3
    $\begingroup$ You really should follow the procedure(s) outlined by the standard, they're there for a reason... $\endgroup$
    – SEJPM
    Jan 4, 2017 at 0:14
  • $\begingroup$ Is KMAC the new standard that is similar to HMAC? $\endgroup$
    – ajith
    Jan 4, 2017 at 0:18
  • $\begingroup$ KMAC is currently a draft for a NIST special publication standard. Not quite on-par with HMAC put about on-par with GCM when it comes to standardization once finished. $\endgroup$
    – SEJPM
    Jan 4, 2017 at 0:20
  • 1
    $\begingroup$ KMAC has the same purpose but is more versatile as the output size can be larger than HMAC. It also doesn't require an additional pass of the hashing (well, the sponge function in this case) over the key - so despite the encoding functions it's more efficient. $\endgroup$
    – Maarten Bodewes ♦
    Jan 4, 2017 at 0:22
  • 6
    $\begingroup$ @SEJPM: SP 800-185, the document defining KMAC, is no longer a draft. It was finalized not two weeks ago. (Direct link to PDF.) $\endgroup$
    – Luis Casillas
    Jan 4, 2017 at 1:03

2 Answers 2

Reset to default
4
$\begingroup$

So if I want to implement a MAC function Can i just do the first method ?? just pad the message with key and do the hash ?

Yes, $mac = \text{SHA3}(k||m)$ is a secure MAC if $k$ is a fixed-length key. This is an explicit design goal of SHA3.

You can also rely on HMAC or KMAC instantiated with SHA3. These will also give you secure MACs but the added complexity is not necessary.

Improve this answer
$\endgroup$
4
  • $\begingroup$ Just to put this out there, the mac should actually be: mac = SHA3(k || constant || m), is that a key and message "a" + "bc" = "ab" + "c" (where + is concatenation). The constant can simply be a space. (This is just a nitpick, but since future devs might see this, I would definitely put that out there.) $\endgroup$
    – 09182736471890
    Nov 27, 2019 at 7:11
  • $\begingroup$ @09182736471890: My answer assumed that k is a fixed-length key and states this assumption. If k is not fixed-length, then you definitively need some way to encode the pair (k,m). However, I don't think that using a space will work: k or m could contain spaces, too. And then it's ambiguous. $\endgroup$
    – real-or-random
    Nov 28, 2019 at 9:08
  • $\begingroup$ The constant just has to be any character which isn't used by k or m, if spaces are unreliable, then use whatever character or string of characters you need. I like using "||" since any keys are unlikely to have those characters. $\endgroup$
    – 09182736471890
    Nov 28, 2019 at 19:23
  • $\begingroup$ @09182736471890: What is the purpose of the constant? $\endgroup$
    – Brandon
    Mar 18 at 6:19
4
$\begingroup$

The prefix-PRF function $F_k\colon m \mapsto H(k \mathbin\| m)$ is conjectured to be a pseudorandom function family—and therefore a good MAC—under the key $k$ when $H$ is any of the fixed SHA-3 functions SHA3-256, SHAKE128, etc. This was an explicit design goal of SHA-3.

However, it also coincides with the fixed functions on some inputs: you could use $F_k(m)$ in one part of your application as a secret, and reveal the fixed hash under $H$ of the string $k \mathbin\| m$ for some reason, and as soon as you've done that, your security flies out the window.

The benefit of using $\operatorname{KMAC128}_k(m)$ instead of $H(k \mathbin\| m)$ is that there is no danger of such colliding uses.

Finally, while you technically can use HMAC with SHA-3, there's no point because KMAC and prefix-PRF are perfectly good choices with SHA-3, and are simpler and faster than HMAC.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.