@FiloSottile

@FiloSottile, saw your tweet here

How does this issue request fall wrt to your perspectives on security v safety of golang standard crypto lib? Should we close this issue because it perhaps asks for something unsafe?

With the right minimums, it can be safe, but any new API adds confusion. I guess it matter whether you need a non-128-or-256 size for compatibility (in which case, with what?), or you'd just like an API that provides both. The former is a stronger case.

I vote for this request as well.

but any new API adds confusion

In fact adding blake2s.New(size, key) reduces confusion. blake2b already has New(size, key) method and it would be great if blake2s stay consistent with blake2b.

whether you need a non-128-or-256 size for compatibility

There are cases when blake2s used with non-128-or-256 keys. For example in cryptsetup (if you have Ubuntu with full-disk-encryption enabled then you use this library). cryptsetup supports blake2s-128,blake2s-160,blake2s-224,blake2s-256.

And Linux kernel supports these key sizes as well. See https://github.com/torvalds/linux/blob/31caf8b2a847214be856f843e251fc2ed2cd1075/include/crypto/blake2s.h#L19

Getting the golang's crypto library in parity with widely used practice would be a great thing.