# Building multiple keys from the same input using a KDF [duplicate]

Let's say I have a single secret with high entropy, S, for the entire application. I want to generate keys K1, K2 for 2 different users of the app. I run:

K1 = PBKDF2(S, salt1)
K2 = PBKDF2(S, salt2)


where each salt is some 128 bit random number.

Is this a safe construction or do KDFs (or PBKDF2 specifically) have any properties that user 1, knowing K1, could infer any part of K2?

EDIT:

Assume a non-broken hash and a sufficient number of iterations for the KDF

• If you have a high entropy secret, use a KBKDF (key-based KDF) not a PBKDF (password-based KDF) – Xander Mar 2 '16 at 20:54

## 1 Answer

Assuming you aren't using a completely broken hash function (speaking of which, what hash and iteration counts are you using? Are they dynamically selected, and if so how?), what you're doing should work.

More specifically, assuming user 1 knows K1 (their own derived key), salt1 (the salt used to derive K1), and salt2 (user 2's salt), but doesn't know S or K2, they should not be able to derive K2 (or S, which would let them get K2 if they know salt2).

With that said, I can't really recommend this approach; it's not really the way KDFs are specifically meant to be used, and adapting cryptographic functions to new uses is often dangerous. Their security properties are not always what you intuitively think they are.

For example, to a naïve understanding of hash functions, knowing the digest of some blob B (without knowing B), and knowing the suffix X that gets appended to B, should not be enough for you to know the digest of concat(B, X). That is, people usually assume that if you don't know the entire input to a hash function, you can't possibly predict the output... even if you know the output of a different input, and know what change was made to that output (in this case, concatenating a suffix). However, due to length extension attacks, it sometimes can be possible to know what the digest will be after appending a known suffix, even if you don't know the original message.

I don't know that anything similar applies to PBKDF2 (or any other KDFs) but I'm still leery of using them in an unusual way. The purpose of the salt is so that, even if two users unknowingly use the same password, you can't tell it's the same password because the derived keys will be different. If you know from the start that the passwords are the same, I don't believe the function is known to guarantee that no additional information could be derived. Maybe it does, maybe it only does with certain hashes, maybe it doesn't... but I don't know, and I don't know if anybody has studied it.

• Iteration count is irrelevant when a high entropy key is the input. If the input is no easier to guess than the output, you don't need iterations to add work factor to the generation process. And this is not a new construct, though oddly implemented. Generally speaking, this is how a KBKDF is used. – Xander Mar 2 '16 at 20:59