Change https://golang.org/cl/108715 mentions this issue: x/crypto/sha3: add NewKMAC128 and NewKMAC256

This adds new API. Any new public API needs to go through a proposal and accepted first. Perhaps you can create a proposal citing proper reasons why this should be inside x/crypto/sha3 and not in an external package ?

/cc @FiloSottile / @agl

This adds new API. Any new public API needs to go through a proposal and accepted first. Perhaps you can create a proposal citing proper reasons why this should be inside x/crypto/sha3 and not in an external package ?

Sure. What's the proper procedure for that? Should I just add "proposal:" to the title of the issue?

Basically, the main reason is that KMAC is based on the underlying Keccak sponge implementation. If I were to create an external package, I'd have to duplicate the entire Keccak implementation from x/crypto/sha3.

Perhaps, it's better to create a new issue altogether to preserve context, since this one is already polluted a bit. You can update the CL with the new "Fixes #xxxx" text once it gets accepted.

Relatedly, https://golang.org/cl/111281 implements cSHAKE.

I'm inclined to accept both cSHAKE and KMAC, unless @agl has objections. SHA-3 has defined way too many functions, but making people reimplement them or roll their own MAC doesn't sound like the right answer.

I thought it was a requirement of SHA-3 candidates that they not permit length-extension, so I'm unsure what the point of KMAC is. But it looks to be tiny wrapper around cSHAKE, so whatever, throw it in!

That's a good question, apparently KMAC was proposed in a SHA-3 workshop but I did not found a rationale for it. I could only deduce that it's for providing domain separation and to avoid some weird pitfalls when using SHAKE directly such as a 16-byte MAC being the prefix of a 32-byte MAC over the same message/key, or a MAC collision of MAC(K,M) and MAC(K[0:-1], K[-1]||M).

When https://golang.org/cl/111281 is accepted I'll change this CL to use its implementation of cSHAKE.

Ok on adding KMAC and cSHAKE. Docs should point to hmac.Equal.

Please consider adding TupleHash too. It's the only way to hash multiple slices without collisions

I updated my CL with the new cSHAKE some time ago, but forgot to comment here...

I can add TupleHash if desired.

That would be awesome

Not sure if there is still interest in this, but I finally added TupleHash (and TupleHashXOF) to the CL 😅

I guess I should just add ParallelHash too; I'll add it soon.

A few years have passed, and cSHAKE landed. Did KMAC end up used in any protocol we know of? There doesn't seem to be a lot of demand for it here, judging from comments and reactions.

A few years have passed, and cSHAKE landed. Did KMAC end up used in any protocol we know of? There doesn't seem to be a lot of demand for it here, judging from comments and reactions.

Yeah I don't see any point in including KMAC if cSHAKE is available. One Day™️ I'll put my code in a separate project. I'll just go ahead and close this if it's OK.

I beg your pardon for being late with my comment: https://doi.org/10.6028/NIST.SP.800-108r1 specifies KMAC as a KDF but not SHAKE. Shall I open a new issue about really adding KMAC support this time?