I have read a lot about the concept of adding a salt to a password and understand that it protects against various attacks, especially the use of rainbow tables. But this kind of attack is based on getting access to the server side stored-password database.

What if the passwords are never stored? Because the salt is, per definition, not secret, it doesn't help to make a weak password stronger (to my mind, only key stretching will help in this case, right?). Hence an application that encrypts only on the client-side (user enters password > KDF > key > encryption) doesn't seem to have any benefit when feeding a salt into the KDF algorithm.

Is it OK to set the mandatory salt parameter of KDF functions (e.g., PBKDF2) to a hardcoded value? Or have I completely overlooked another salt feature?


1 Answer 1


If you are dealing with encryption using user-provided passwords, the resulting ciphertext might be attacked using pre-computations à la "dictionary attack", which is the same kind of attacks we are trying to mitigate when using a salt to store passwords.

When encrypting with user provided passwords, the KDF is used as a mean to compensate for the poor entropy of the user passwords, but because you cannot consider the salt to be a secret and you have to provide it to the decrypting party in some way, if you use a salt you will not necessarily increase the "entropy" of your password, because an attacker could simply use the same salt to try and brute-force your key. In the same manner, a dictionary attack against encrypted data would still work by simply using the same parameters and salt as you do, since these are supposed public (and is even easier if you have a known plaintext-ciphertext pair).

So in the end, you should still be worried about making a dictionary/brute force attack as costly as possible and this is possible with modern KDF such as Argon2 or Balloon, where you can set the parameters, which can be publicly known, in such a way that the attack will become more and more time consuming and costly for the attacker.

So effectively, I agree with you that the salt is not necessarily useful for your use-case, since having a larger initial, secret entropy is more important to protect your data. But still notice that having a single hard-coded salt will be detrimental to you in the sense that it allows an attacker to "pre-compute" its tables or dictionary attacks for all of your ciphertext at once. This means that using a fixed salt makes the act of cracking multiple ciphertexts on average less costly.

So your use-case benefits from using a KDF, (not just a hash function), with a large iteration number to increase the cost of an attack, and benefits also from using a different random salt for each encryption in order to avoid "pre-computation" attacks that can target all ciphertexts at once. This effectively means each ciphertext would require its very own precomputations and thus it boils down to a bruteforce in the end.

PS: notice that dictionary attacks are only useful when the adversary is able to tell easily whether she has found the correct key or not. Which is typically the case in known plaintext attacks, but not always true for all use-cases.

PPS: I'm not mentioning the pepper since you're aware of its existence given your other question. But a pepper is typically useful in that kind of use-case. Note that the salt, when considered secret is basically a pepper.

  • $\begingroup$ Thank you Lery for confirming my expectation and your further informations. I totally agree with you, that I have to use a KDF algorithm. A problem encountered in practice is that not all (available) crypto libraries support all algorithms (like Argon2). And adding a static pepper doesn't make sense in open source projects where the whole source code is public visible. That's why I asked in the other question if the random-pepper (now as dubious classified :) method could be an improvement. $\endgroup$
    – User01638
    Nov 11, 2017 at 9:32
  • $\begingroup$ An additional question regarding the weak password problem and the missing Argon2/Ballon support: Does it help to chain two KDF methods? E.g. create a key with PBKDF2 (SHA 256) and feed the resulting key to HKDF (SHA 512)? I would assume that there is no advantage. $\endgroup$
    – User01638
    Nov 11, 2017 at 10:00
  • $\begingroup$ @User01638 I cannot see any advantage besides maybe trying to anticipate a break of either... Which is really unlikely. Notice that PBKDF2 with sufficiently big parameters allow to avoid dictionary attacks as well thanks to the computational cost it would induce. $\endgroup$
    – Lery
    Nov 11, 2017 at 17:54
  • $\begingroup$ Salts are used to prevent the use of rainbow tables, and to force breaking passwords one at a time. They are of relatively little value against dictionary attacks. $\endgroup$
    – A. Hersean
    Nov 27, 2020 at 15:42
  • $\begingroup$ In this case I use dictionary attack in the sense of a precomputation attack, like a rainbow table. But rainbow tables are specific to hashes in my vocabulary, not really for encryption. (I guess one could argue that any block cipher can be used as a hash typically thanks to Merkle-Damgård construction for example and thus that rainbow tables still apply.) $\endgroup$
    – Lery
    Nov 27, 2020 at 15:49

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.