search

golang / go

The Go programming language
https://go.dev
BSD 3-Clause "New" or "Revised" License
122.95k stars 17.53k forks source link

x/crypto/sha3: add KMAC #24988

Closed conradoplg closed 2 years ago

conradoplg commented 6 years ago

The KMAC message authentication code specified in NIST SP 800-185 may be a useful MAC implementation.

In particular, it can be used as a KDF as specified by NIST SP 800-56C.

I'm submitting a CL implementing it, in case there is interest. I can also add support for TupleHash and ParallelHash.

gopherbot commented 6 years ago

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

agnivade commented 6 years ago

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

conradoplg commented 6 years ago

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.

agnivade commented 6 years ago

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.

FiloSottile commented 6 years ago

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

FiloSottile commented 6 years ago

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.

agl commented 6 years ago

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!

conradoplg commented 6 years ago

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.

FiloSottile commented 6 years ago

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

Scratch-net commented 6 years ago

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

conradoplg commented 4 years ago

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

I can add TupleHash if desired.

Scratch-net commented 4 years ago

That would be awesome

conradoplg commented 3 years ago

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

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

FiloSottile commented 2 years ago

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.

conradoplg commented 2 years ago

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.

rautammi commented 1 year ago

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?