Regarding HKDF, the specification says a salt may be re-used.

However, I have set up my system to generate a new, long and cryptographically random salt that persists with the user. This salt is not a secret. (See the RFC, section 3.1)

In addition, I am taking our unique user identifier and using it as context info for the third parameter in HKDF.

So our HKDF looks like this:

DK = HKDF(MasterKey, PublicUserSpecificSalt, UUID)

My questions are:

  1. Are there any issues with creating a random, user-specific salt, and using this for the salt input in HKDF? It seems the spec expects the salt to be re-used, which I am not doing.
  2. If I do use a random, user-specific salt, what is the benefit of the UUID as context info? Should I just remove it, since it would add unnecessary complexity?
  • $\begingroup$ @R1w Please don't make minimal edits until we don't have to perform an additional review, this is just not worth the cost. $\endgroup$
    – Maarten Bodewes
    Sep 19, 2018 at 23:02

1 Answer 1


By HKDF, I guess you mean HKDF-Expand, which takes as input a pseudorandom key, a label, and the output length. A public label is OK, but it is better unique rather than random due to HKDF-Expand's pseudorandom function security. I think using UUID only as the label is good enough.

  • $\begingroup$ Hi! Thanks for your answer! Just to clarify -- by unique, do you mean a unique value that is shared across all users, or a value that is unique to that user? $\endgroup$
    – jrl
    Sep 20, 2018 at 17:58
  • $\begingroup$ @jrl If the server uses the same master key for all users, then the salt should be unique among all users. $\endgroup$
    – Shan Chen
    Sep 20, 2018 at 18:21
  • $\begingroup$ The HKDF function that takes a salt is HKDF-Extract, not HKDF-Expand. $\endgroup$ Sep 21, 2018 at 0:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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