The problem is that users may use too short hash values. The package tries to achieve a security level of at least 128 bit. See also RFC 7693

However I'm currently working on #19896 which requires arbitrary digest sizes.
In general I would recommend the XOF (blake2x) construction if arbitrary digest sizes are required.

The package tries to achieve a security level of at least 128 bit. See also RFC 7693

Ah! That's why you didn't include id-blake2b160.

In general I would recommend the XOF (blake2x) construction if arbitrary digest sizes are required.

Agreed. For a little context here: I was writing a golang implementation of libsodium's sealed box. It's the same as NaCl's sealed box except it specifies the creation of the nonce as 24-byte-blake2b-mac(pubkey1 CONCAT pubkey2).

Ah! That's why you didn't include id-blake2b160.

Correct -However it's still available here.

Agreed. For a little context here: I was writing a golang implementation of libsodium's sealed box. It's the same as NaCl's sealed box except it specifies the creation of the nonce as 24-byte-blake2b-mac(pubkey1 CONCAT pubkey2).

That sounds like a use case for a XOF like BLAKE2x, SHA3 / SHAKE or Kangaroo 12.

Too-short hash values may have legitimate use-cases, like birthday paradox proof-of-work where hash collisions are what you're trying to find, e.g. equihash. If you're aiming for a very short proof-of-work period, you need a very short hash. The XOF doc says "Note that an ℓ smaller or equal than 64 is acceptable, there’s just no reason to use it since BLAKE2b already provides hashes of 64 bytes or less". From that comment, it seems to me that arbitrary length BLAKE2b was intended.

@sporkmonger
I'm not saying there are no use cases for short hash values - like 64 bit. There are many applications for example preventing hash-flooding attacks. However a collision based proof-of-work could be implemented by truncating a larger hash or just considering only a specific number of bits - that would make the difficulty adjustable...

The XOF doc says "Note that an ℓ smaller or equal than 64 is acceptable, there’s just no reason to use it since BLAKE2b already provides hashes of 64 bytes or less". From that comment, it seems to me that arbitrary length BLAKE2b was intended.

Sure, the problem is that users may use a too short hash to achieve collision resistance. However the BLAKE2b package will support arbitrary hash sizes because of Argon2.

Fixed by #19896 - Can be closed.

Thanks!