Return to Answer

Given that you use the SHA-3 hash (which is resistant against length extension attacks), would you still need to go through that procedure in order to produce a secure MAC?

No, you don't need to do that, but you can.

Needless to say we'd still use a key, which we prepend or append to the message, but is that sufficient for a MAC?

Yes, you can prepend the message with the key, i.e. use $H(K||M)$.

Quoting the Keccak (SHA3) website:

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.

However, the standard does not specify this MAC mode, only a hash function. So using HMAC-SHA-3 would be the more conservative choice if you wanted to use only standardized primitives.

There is now a draft specification (pdf) of KMAC (and other constructions) based on SHA-3, or specifically the SHAKE extendable output functions. The changes from "prepend key to message" are key padding as well as the inclusion of constants and the output length, which are all done for domain separation.

It is possible to implement KMAC in this form using SHAKE128/SHAKE256 but not using the other SHA-3 variants.

Given that you use the SHA-3 hash (which is resistant against length extension attacks), would you still need to go through that procedure in order to produce a secure MAC?

No, you don't need to do that, but you can.

Needless to say we'd still use a key, which we prepend or append to the message, but is that sufficient for a MAC?

Yes, you can prepend the message with the key, i.e. use $H(K||M)$.

Quoting the Keccak (SHA3) website:

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.

However, the original standard does not specify this MAC mode, only a hash function.

There is now a specification (pdf) of KMAC (and other constructions) based on SHA-3, or specifically the SHAKE extendable output functions. The changes from "prepend key to message" are key padding as well as the inclusion of constants and the output length, which are all done for domain separation.

It is possible to implement KMAC in this form using SHAKE128/SHAKE256 but not using the other SHA-3 variants.

Given that you use the SHA-3 hash (which is resistant against length extension attacks), would you still need to go through that procedure in order to produce a secure MAC?

No, you don't need to do that, but you can.

Needless to say we'd still use a key, which we prepend or append to the message, but is that sufficient for a MAC?

Yes, you can prepend the message with the key, i.e. use $H(K||M)$.

Quoting the Keccak (SHA3) website:

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.

However, the standard does not specify this MAC mode, only a hash function. So using HMAC-SHA-3 would be the more conservative choice if you wanted to use only standardized primitives.

Given that you use the SHA-3 hash (which is resistant against length extension attacks), would you still need to go through that procedure in order to produce a secure MAC?

No, you don't need to do that, but you can.

Needless to say we'd still use a key, which we prepend or append to the message, but is that sufficient for a MAC?

Yes, you can prepend the message with the key, i.e. use $H(K||M)$.

Quoting the Keccak (SHA3) website:

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.

However, the standard does not specify this MAC mode, only a hash function. So using HMAC-SHA-3 would be the more conservative choice if you wanted to use only standardized primitives.

There is now a draft specification (pdf) of KMAC (and other constructions) based on SHA-3, or specifically the SHAKE extendable output functions. The changes from "prepend key to message" are key padding as well as the inclusion of constants and the output length, which are all done for domain separation.

It is possible to implement KMAC in this form using SHAKE128/SHAKE256 but not using the other SHA-3 variants.

Given that you use the SHA-3 hash (which is resistant against length extension attacks), would you still need to go through that procedure in order to produce a secure MAC?

No, you don't need to do that, but you can.

Needless to say we'd still use a key, which we prepend or append to the message, but is that sufficient for a MAC?

Yes, you can prepend the message with the key, i.e. use $H(K||M)$.

Quoting the Keccak (SHA3) website:

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.

However, the draft standard does not specify this MAC mode, only a hash function. So using HMAC-SHA-3 would be the more conservative choice if you wanted to use only standardized primitives (after the draft is finalized).

Given that you use the SHA-3 hash (which is resistant against length extension attacks), would you still need to go through that procedure in order to produce a secure MAC?

No, you don't need to do that, but you can.

Needless to say we'd still use a key, which we prepend or append to the message, but is that sufficient for a MAC?

Yes, you can prepend the message with the key, i.e. use $H(K||M)$.

Quoting the Keccak (SHA3) website:

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.

However, the standard does not specify this MAC mode, only a hash function. So using HMAC-SHA-3 would be the more conservative choice if you wanted to use only standardized primitives.