Closed kirelagin closed 2 years ago
BLAKE2b supports any key size in the [0..64] range.
Using short keys for domain separation is perfectly fine as long as the application expects a hash function and not a PRF.
The crypto_generichash_KEYBYTES_MIN
constant is a guideline, and maybe we shouldn't suddenly panic on shorter keys, especially if that would break existing applications.
But the documentation can indeed be updated. I'll do it soon.
Thanks!
The documentation for
crypto_generichash
states that the size ofkey
can be betweencrypto_generichash_KEYBYTES_MIN
andcrypto_generichash_KEYBYTES_MAX
, but the implementation does not actually check these bounds. And there is code in the wild (not going to point fingers) that passes short “personalization” ascii strings as keys.crypto_generichash_KEYBYTES_MIN
is defined ascrypto_generichash_blake2b_KEYBYTES_MIN
, which, in turn, is defined as16
. Similarly,crypto_generichash_KEYBYTES_MIN
is defined viacrypto_generichash_blake2b_KEYBYTES_MAX
as64
.The implementation does check the upper bound, although via a different constant,
BLAKE2B_KEYBYTES
, which is completely unrelated tocrypto_generichash_blake2b_KEYBYTES_MAX
, although happens to have the same value.Here is a reproducer:
This program outputs
6084ca07be5ad316a2f14149e960676c0304f48ef2138e70b1fc6e085c62c908
, while, based on the documentation, I would expect it to crash.I think that either the implementation should check the lower bound, or the documentation needs to be updated to remove the mention of this lower bound, or the lower bound should be defined as 0 (or 1?).