3
$\begingroup$

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?

Improve this question
$\endgroup$
2
  • 1
    $\begingroup$ Actually using only a single salt may be more error-prone, as some people may use variable length concatenation where they have proper separation right now which may lead to conincidentally same salts. My impression is that "personalization" is more for static things like "company name" or perhaps "company name, key-id" so that everyone has a different hash and salt is more for dynamic randomness that all parties doing the computation just happen to have. But I don't think this is technically enforced / swapping this will at most cost one extra compression call. $\endgroup$
    – SEJPM
    Jan 23, 2020 at 19:15
  • $\begingroup$ Interesting, I didn't think of variable length concatenation. That's a good point! $\endgroup$
    – Danilo Bargen
    Jan 23, 2020 at 21:04

1 Answer 1

Reset to default
2
$\begingroup$

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.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.