1
$\begingroup$

I see there are a lot of questions relating to handling of a salt value but nothing I have seen so far has cleared the following question.

When using a KDF such a scrypt, I believe the value of the salt should be random and change each time even on a per user basis (same user generating two different keys at different points in time). Due to this is it safe to store the randomly generated salt in some persistent storage?

I am using scrypt to generate a key for AES. I do not store the key used for encryption. As such, to decrypt the data I must use scrypt once again to generate the key. To do this I must take the users password (this is entered by the user each time) and the salt. Given the key must match the key used for encryption, must I have stored the salt in order to re-derive the same key?

Similarly to an initialisation vector, can this salt to be stored in public? For my use case the encrypted string and IV will both be stored in public, can the salt also be stored like this?

$\endgroup$
2
  • 1
    $\begingroup$ Yes all those except the password are called public parameters and can be stored in public. $\endgroup$
    – tur11ng
    Commented Apr 5, 2022 at 21:29
  • $\begingroup$ How many times you are going to use this password for different files? What is the encryption mode of operation that you want to use? There are lots of questions/pitfalls when you want to encrypt files. Even a file update can be dangerous if you don't change the key... $\endgroup$
    – kelalaka
    Commented Apr 5, 2022 at 22:54

1 Answer 1

3
$\begingroup$

The purpose of salt is to prevent usage of rainbow tables. Simply put, use different salts for hashing of different passwords. Salt does not need to be secret. It is a common practice that salt is stored in easily accessible form.

To derive the same AES key with scrypt, you should use the same input. Not only the salt should be the same, but also other parameters like the number of iterations should be the same and that's why should also be stored. And these parameters as well as salt don't need to be secret.

$\endgroup$
7
  • $\begingroup$ OP talking about an AES key, not about deriving passwords... Also, the IV can be also derived together with the key ( there is no mention on the IV on your post) $\endgroup$
    – kelalaka
    Commented Apr 5, 2022 at 22:48
  • $\begingroup$ @kelalaka: Are you sure? OP is saying: "I am using scrypt to generate a key for AES ... To do this I must take the users password (this is entered by the user each time) and the salt". The author asks user for a password, then adds salt (I suppose the other parameters are some constants) and generates a key, which is then used for encryption/decryption with AES. This is standard procedure in KeePass and some other tools. $\endgroup$
    – mentallurg
    Commented Apr 5, 2022 at 23:25
  • $\begingroup$ @kelalaka: And look at the title: The OP is asking namely about handling of salt for scrypt. $\endgroup$
    – mentallurg
    Commented Apr 5, 2022 at 23:29
  • $\begingroup$ You use 'To derive the same password with scrypt, you should use the same input. Should be To derive the same AES key with scrypt, you should use the same input. For the IV part, my mistake.. $\endgroup$
    – kelalaka
    Commented Apr 5, 2022 at 23:37
  • 1
    $\begingroup$ @kelalaka: OK, you are right 🙂 I meant "to get the same output you need the same input". But using word "password" in this context is not a good idea. The OP is talking about AES key, so we should stick to it. I have edited my answer. Thank you 🙂 $\endgroup$
    – mentallurg
    Commented Apr 6, 2022 at 1:32

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.