2
$\begingroup$

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?

$\endgroup$
  • 1
    $\begingroup$ It's fine as long as you don't reuse encryption IV for the same passphrase. $\endgroup$ – DannyNiu Jun 28 '17 at 12:05
1
$\begingroup$

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.

$\endgroup$
  • $\begingroup$ to clarify, I would only ever re-use the same salt when encrypting the same thing with the same password. to make this simpler, imagine there is a single user and a single file. what are the advantages and disadvantages of using a different salt (and therefore a different key) everytime? $\endgroup$ – JonathanR Jul 3 '17 at 10:18
  • $\begingroup$ If I follow your question, are you suggesting that each time a user decrypts their file the file is then re-encrypted with a new key? If that is correct, the obvious downside to doing this is the performance hit. $\endgroup$ – kkl Jul 3 '17 at 15:45
  • $\begingroup$ that is in the read-only case, where i wouldn't re-encrypt at all anyway. if the user makes any changes to the file and it needs to be re-encrypted it makes no difference to performance whether the salt (and therefore key) are re-used or not. $\endgroup$ – JonathanR Jul 4 '17 at 14:54
0
$\begingroup$

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.

$\endgroup$
  • $\begingroup$ The question is about re-using the salt for the same user, not in general. In both cases every user's password is salted differently. $\endgroup$ – JonathanR Aug 8 '17 at 16:31

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.