hmac.New takes a func() hash.Hash because it needs to create two separate hash.Hashes. It's not clear to me what is supposed to happen with HMAC-around-Blake2b as far as whether both should be keyed the same. But yes we should try to find a way to make Blake2b work with hmac.New.

/cc @aead

HMAC-BLAKE2 does not make a lot of sense since BLAKE2 can be used itself as a keyed MAC, but I agree that x/crypto/blake2b should expose func() hash.Hash functions.

I wish we called the keyed options NewXXXWithKey, but I guess we can call the un-keyed versions (which don't return an error) NewHashXXX:

func NewHash256() hash.Hash
func NewHash384() hash.Hash
func NewHash512() hash.Hash

👍 ?

I would agree with @FiloSottile , BLAKE2 combined with HMAC doesn't make much sense - as far as I can see... However if someone wants to use BLAKE2 as a hash function for the HMAC construction I would prefer something like this (works only with 1.9):

import (
	"crypto"
	"crypto/hmac"
	"fmt"

	_ "golang.org/x/crypto/blake2b"
)

func main() {
	key := make([]byte, 32)
	msg := []byte("hello world")
	hash := hmac.New(crypto.BLAKE2b_256.New, key)
	hash.Write(msg)
	fmt.Println(hash.Sum(nil))
}

over adding new functions to the blake2(b/s) packages. They already contain a lot of exported functions and with crypto.Hash there is already a mechanism to create a hash.Hash

Forcing the indirection through package crypto is a bit odd. Do any real-world protocols use HMAC-BLAKE2? Maybe we don't need to do this?

I'm not aware of any protocols using HMAC-BLAKE2. I agree that the indirection is a bit odd compared to code using HMAC-SHA2. On the other hand BLAKE2 can be used as a MAC directly. However, the usage of BLAKE2 as a hash function is a bit different because of the error handling:

hash, err := blake2b.New256(nil)
if err != nil {
      // this will never happen...
}

Of course crypto.Hash solves this but I think many people use the package directly instead of crypto.Hash.New()

It sounds like there are thorny API issues here and on top of that "BLAKE2 combined with HMAC doesn't make much sense". And we know of no protocols that actually need HMAC-BLAKE2. So the fact that it's hard to do (well, a few lines of code) seems OK.