Hypothetical. Lets say you have an application where you generate a master key from a user password using PBKDF2 (static salt) and then use the master key to derive two passwords keys for an encrypt-then-mac scheme using HKDF (unique salt per encryption).

The password would be shared by two individuals, who would then potentially share many messages. Each message would share the same master key, but would have unique encryption and MAC keys. Does this make sense, or is the unique salts in HKDF unnecessary?


2 Answers 2


Yes, the salt in the HKDF can provide for key separation between the encrypt-then-mac applications. If that's needed depends on the system, maybe using an IV/nonce is enough, it depends on how many messages you want to encrypt and the used encryption and MAC scheme basically.

Some other remarks:

  • we derive keys - not passwords - for ciphers and MAC algorithms;
  • using an authenticated cipher such as GCM mode instead of encrypt-then-mac would be wise, in that case you only need to derive one key;
  • you'd use a static salt with PBKDF2 to derive the same master key, it's probably best to only use a static salt if you need to reuse the key (which of course assumes that you also use the same password);
  • you may want to additionally use a separate KDF invocation to derive a "key check value" stored with the ciphertext to check that you've derived the correct master key (instead of having to rely on authentication tag failures).

Depending on the application, this may allow parallel attacks on multiple encrypted items.

To illustrate the problem, suppose I (the attacker) have a thousand encrypted files, each encrypted with a different user password, all of which used the same salt for PBKDF2 (but different ones for the HKDF stage). I can run a parallel attack like this:

Generate a list of password guesses. For each one:
    Compute key1 = PBKDF2(password guess, static salt)
    For each encrypted file:
        Compute key2 = HKDF(key1, file's salt)
        Test key2 (e.g. by checking the MAC)

The PBKDF2 step is slow, but I only have to do it once per password; once I've done that for a possible password, I can rapidly check it against all thousand files (since HKDF is fast). This gives me nearly a factor of a thousand speedup in my attack vs. what I'd have to do if each file used a different salt for PBKDF2.

(Actually, checking the MAC might be slow if the files are big. But still...)

  • 2
    $\begingroup$ Sorry, but this is wrong. Using a separate salt won't protect you once you've found the single password. That would only work for separate passwords. Or do you assume that the same salt would be used for different passwords in the answer? Because that would indeed be a bad idea. If so please clear it up in the answer! $\endgroup$
    – Maarten Bodewes
    Dec 4, 2020 at 11:22
  • 1
    $\begingroup$ @MaartenBodewes Yes, as I said, I'm assuming each file is encrypted with a different user password; I mention this in the second paragraph. If they all use the same password, the parallel attack doesn't help. $\endgroup$ Dec 4, 2020 at 17:38
  • $\begingroup$ I updated my question with additional info on the application. The idea is that there would potentially be many messages shared between 2 parties using the same password. The iteration count of PBKDF2 would be very high (think 10 seconds to compute) so ideally this is done once per "session" and not once per message. $\endgroup$
    – Chris_F
    Dec 4, 2020 at 21:25
  • 2
    $\begingroup$ @Chris_F Having many messages with the same password & salt isn't a problem, but if you use the same salt with multiple different passwords (e.g. for multiple conversations between different pairs of users), then you're enabling parallel attacks across the different passwords. BTW, there's also a possible problem with precomputation of key1 for different passwords; depending on your threat model, this might or might not be a problem. $\endgroup$ Dec 4, 2020 at 23:37

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.