BLAKE2: What is the difference between the salt and the personalization? Libsodium builds their KDF on top of BLAKE2b:

BLAKE2B-subkeylen(key=key, message={}, salt=subkey_id || {0}, personal=ctx || {0})


Besides the key, the function has two additional arguments: The subkey ID (a 8 byte value which is 0-padded and becomes the salt) and a personalization context. They document those two values as follows:


  subkey_id can be any value up to (2^64)-1


And:


  Similar to a type, the context ctx is a 8 characters string describing what the key is going to be used for.
  Its purpose is to mitigate accidental bugs by separating domains. The same function used with the same key but in two distinct contexts is likely to generate two different outputs.
  Contexts don't have to be secret and can have a low entropy.


If I understand this correctly, both the 8-byte subkey ID (which becomes the 16-byte salt) and the 8-byte ctx (which becomes the 16-byte personalization) are used for "namespacing", don't have to be secret and may be of low entropy.

In BLAKE2b, what is the difference between the salt and the personalization context? Can the personalization context be considered the "second part of the salt", introduced only for semantic purposes? And if yes, wouldn't using a single 32-byte salt be simpler to understand and less error-prone to implement?
Context should be constant for one "keystore": that is the property of the KDF that is used for namespacing the salt space and make sure that two different application (or keystore) will not reuse the same salt.

Subkey_id, however, needs to be different for each key within a given key store and it is NOT to be used for namespacing. It can be constant for a given subkey ID though (even when the unhashed data changes).

The purpose if to make sure different applications can safely generate unique salt values without having to perform a full scan: all you need if for each app to have it's own context and then they can use a simple counter for subkey ID.