crypto_generichash_KEYBYTES_MIN is not checked

[Kirill Elagin]

The documentation for crypto_generichash states that the size of key can be between crypto_generichash_KEYBYTES_MIN and crypto_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 as crypto_generichash_blake2b_KEYBYTES_MIN, which, in turn, is defined as 16. Similarly, crypto_generichash_KEYBYTES_MIN is defined via crypto_generichash_blake2b_KEYBYTES_MAX as 64.

The implementation does check the upper bound, although via a different constant, BLAKE2B_KEYBYTES, which is completely unrelated to crypto_generichash_blake2b_KEYBYTES_MAX, although happens to have the same value.

Here is a reproducer:

#include <stdio.h>
#include <sodium.h>

int main(void) {
  unsigned char key[] = "hi";
  unsigned char out[crypto_generichash_BYTES];

  crypto_generichash(out, crypto_generichash_BYTES, 0, 0, key, sizeof(key) - 1);

  for (int i = 0; i < crypto_generichash_BYTES; ++i) {
    printf("%02x", out[i]);
  }
  printf("\n");

  return 0;
}

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?).

[Frank Denis]

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!