Score:1

Salt value in scrypt algorithm

gf flag
cjd

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?

JAAAY avatar
us flag
Yes all those except the password are called public parameters and can be stored in public.
kelalaka avatar
in flag
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...](https://crypto.stackexchange.com/a/84440/18298)
Score:3
kr flag

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.

kelalaka avatar
in flag
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)
kr flag
@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.
kr flag
@kelalaka: And look at the title: The OP is asking namely about handling of salt for scrypt.
kelalaka avatar
in flag
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..
cjd avatar
gf flag
cjd
Yes this answers the question @mentallurg. So it is safe to store the salt (as well as the IV) in public?
kr flag
@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
kr flag
@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.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.