Salt for non-stored passwords 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 &gt; KDF &gt; key &gt; 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?
If you are dealing with encryption using user-provided passwords, the resulting ciphertext might be attacked using pre-computations à la &quot;dictionary attack&quot;, 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 &quot;entropy&quot; 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 &quot;pre-compute&quot; 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 &quot;pre-computation&quot; 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.