cc @FiloSottile

I sent a PR containing a proposed implementation at https://go-review.googlesource.com/c/crypto/+/371315

Change https://golang.org/cl/371315 mentions this issue: x/crypto: implement kbkdf

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

For what it's worth, looks like the entirety of the public API is

package kbkdf

func HMACCounter(h func() hash.Hash, keyLen int, secret, label, context []byte) []byte

In contrast, x/crypto/pbkdf2 calls the equivalent function just 'Key', and the arguments are in approximately the reverse order. (See https://pkg.go.dev/golang.org/x/crypto/pbkdf2.) It seems like at the least we should try to make kbkdf's API look as close to pbkdf2's as possible. That would mean:

package kbkdf

func Key(secret, label, context []byte, keyLen int, h func() hash.Hash) []byte

unless the existing API is trying to match something else.
And of course I may misunderstand the details of the API here.
Are there other possible kbkdf functions?
Is that why HMACCounter was in the name?

Thanks, Russ. I agree, we could reorder the parameters to more closely match pbkdf's ordering. The ordering of parameters I've suggested is more based on https://pkg.go.dev/golang.org/x/crypto/hkdf. (hkdf is the newer, better PRF based KDF that TPM missed the boat on by a couple of years, it seems).

KBKDF can be based on HMAC or CMAC (though I don't think the Go crypto libraries support CMAC yet - see https://pkg.go.dev/github.com/aead/cmac for what looks like a reasonable implementation).
KBKDF can also be in one of three modes: Counter (implemented in my Gerrit change), Feedback, and Double-Pipeline Iteration modes. OpenSSL only supports the first two, and TPM only uses the first one.

I wanted to leave room for growth, either CMAC based or other-modes. We could also implement something like

func Counter(h func() hash.Hash, keyLen int, label, context []byte) []byte

but this would require callers to write something like

key := Counter(func() hash.Hash {return hmac.New(sha256.New, "secret")}, 32, []byte("label"), []byte("context"))

and while flexible (supports bring-your-own-CMAC implementation) it seems more finnicky to use. It's also unintuitive, we would be asking for a parameter of a type called Hash but what we mean is HMAC or CMAC (which happen to implement the interface called Hash - though one way to mitigate this would be to duplicate the hash.Hash interface as kbkdf.PRF)

/cc @golang/security

Discussed with @chrisfenner offline and I believe this does not clear the bar for addition to x/crypto:

• there is no scenario in which a new application would want to choose KBKDF over HKDF, which is more widely adopted and analyzed, and already available in x/crypto
• KBKDF has a myriad of variants, and we'd have to implement them all to be useful to all users of KBKDF, as the assumption is that they are bound by compatibility and not free to choose the variant we implement
• the only spec that requires KBKDF that I am aware of is the TPM one, and we had never gotten a request to implement it before, which suggests this belongs in the go-tpm tree
• the implementation is very simple and unsubtle, and shares no code with x/crypto internals, so I am not worried about it living in a third-party module

Based on the discussion above, this proposal seems like a likely decline.
— rsc for the proposal review group

No change in consensus, so declined.
— rsc for the proposal review group