1

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?

cjd
  • 55
  • 3

1 Answers1

3

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.

mentallurg
  • 2,611
  • 1
  • 16
  • 22
  • 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) – kelalaka Apr 05 '22 at 22:48
  • @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. – mentallurg Apr 05 '22 at 23:25
  • @kelalaka: And look at the title: The OP is asking namely about handling of salt for scrypt. – mentallurg Apr 05 '22 at 23:29
  • 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.. – kelalaka Apr 05 '22 at 23:37
  • Yes this answers the question @mentallurg. So it is safe to store the salt (as well as the IV) in public? – cjd Apr 06 '22 at 01:32
  • 1
    @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 – mentallurg Apr 06 '22 at 01:32
  • @cjd: Yes, it is safe to store the salt public. But, as kelalaka pointed out in another comment, a salt may be not sufficient for the good security. For instance, if you use the same salt for multiple passwords, this will reduce the efficiency of the salt. Also it is important what exactly are you doing with AES, e.g. are you encrypting a file with particular password only once, or you are updating this file time to time. Also it is important how exactly are you using AES, as kelalaka asked. Thus, consider also other aspects besides salt. – mentallurg Apr 06 '22 at 01:36