For encryption with a passphrase, should you re-use the same salt for key generation?

Question

Let's say I have a simple "vault" application where users can enter data and a passphrase, and it will be encrypted, requiring them to re-enter the passphrase to decrypt it.

This would be implemented as follows:

• generate salt for key generation
• generate key from (salt, passphrase) with argon2, scrypt, or whatever else libsodium is using
• generate nonce or iv
• encrypt and sign (plaintext, key, nonce or iv) with chacha / aes-gcm / whatever else libsodium is using
• store (ciphertext with signature, salt, iv or nonce) as I need all 3 to decrypt from the passphrase

My question: is there an advantage or disadvantage to re-using the salt everytime for the same user? Most crypto examples re-use keys, which is fine as long as the IV or nonce is different. However if I generate and store the salt everytime I'm effectively using a different key everytime. Is this good / bad / unimportant?

Answer 1

The purpose of a salt started with password storage. Within the very common use-case of using a hash function to store usernames and passwords, unsalted password hashes reveal which users have the same password. This reveals a lot of information about the underlying passwords and would make password hash "cracking" much more efficient.

In your use-case you are not dealing with hashed passwords but password-derived keys, however, the use-case for salts is similar. Would it be an acceptable design for your vault to reveal that all ciphertexts are encrypted using the same derived key? If, for example, your vault allowed users to specify per-file passwords for key derivation a static salt may reveal that multiple files used the same password to derive their encryption key.

Answer 2

The security of your model is really dependent upon the security of your hash function. One of the primary reasons for using salt's is for defense against rainbow tables, but in this case you are secure from rainbow tables as your hash is not exposed.

You have however, made the attackers job significantly easier if you make all the passwords have the same salt. Lets say that the table has N entries,and as an attacker, I want to try to get as many user's vault data as possible. At this point I am running a dictionary attack. In your model, where every password has the same salt, I only have to hash any given password once, and then attempt to symmetrically decrypt each file. When each user has a unique salt, you have to perform N hashes. Password hashes are designed to be slow and memory intensive hashes. Thus this is a big deal, and is alot of extra workload on an attacker who is trying to break as many users as possible. Therefore using the same salt does have security concerns, as you lose that factor of N extra work which was placed upon the attacker.