# Is a salt necessary for PBKD when the hash is used as an encryption key?

I'm generating a key from a password to encrypt data with AES256. Since the generated hash is not stored, would I need to use a salt? If I use a salt and it is made public, is my encrypted data any less secure?

I don't see a need to protect against rainbow attacks since the generated hash is never saved but instead just used as an encryption key and there is no central repository for the encrypted data.

Updated answer based on new info:

Humans aren't very creative when it comes to password. This makes these passwords a poor choice as seeds to generate encryption keys (which should have a high entropy). Quoting from a study:

Burnett did an analysis of 6 million username and password combinations last year, and found that 91 percent of users had used one of the 1,000 most common passwords—with 99.8 percent using a password from the 10,000 most common. And "password" was the leader of them all, in use by 4.7 percent of user accounts.

### Dictionary (and not rainbow) attacks are what you should be worried about

Given the statistics above, its likely that you are dealing with a very miniscule subset of total possible encryption keys ( a couple thousands or millions!). A 256 bit AES key has a address space of 2^256. In such a case, you should be worrying about the dictionary attacks.

Consider a following PBKD function:

The PBKDF above uses does `c` iterations of a hash function `H` over the (password||salt) combination

Also, consider a password dictionary of 1M passwords and that our application has 100 users

Without salt

When there is no per user salt, the PBKDF function above reduces to:

All attacker needs to do is to calculate a dictionary of 1M AES keys corresponding to each password in the dictionary.

``````The number of times a user needs to run the KDF function = 1M.
``````

With salt

Now that each user has a salt, a generic 1M list of AES keys will not work. An attacker will now need to do 1M KDF operations per user to create a specific set of possible AES keys for that specific user.

``````The number of times a user needs to run the KDF function = 100M.
``````

PBKDFs, like bcrypt and scrypt, are deliberately slow functions just to ward off dictionary attacks like these.

### Finally

It is advised to use a salt with PBKDF functions to make sure that the resultant keys have more entropy and an attacker needs to compute a dictionary per user to do a dictionary based brute force attack. Since PBKDF functions are designed to be slow, creating a per-user dictionary list is a order magnitude slower than a single list.

Salts will be useful in the scenario where two different users have same passwords and the same data. If a deterministic encryption is used, the resulting cipher texts will be same (since the encryption keys derived using PBKDF will be the same) thus opening up vectors for cryptanalysis. If passwords are salted, the resulting cipher text will be different in the aforementioned case.

Salts are not a secret. You don't have to encrypt/hide the salts. They should be unique for each user though.

Also if you don't have a concept of users/passphrases, then you don't need to use PBKDF to generate keys. As Lucas mentioned, you can use a secure random number generator to create random keys directly.

• I apologize for poorly wording my question earlier. I've updated it to be more clear. The user data will never be the same and there is no central repository for storing encrypted data. Passwords are necessary for the user to eventually decrypt the data. Jan 14, 2017 at 15:46

PBKDF2 is used to derive a key from a passphrase, if you are just generating keys without actually using a passphrase, you can also just use a secure random generator to generate a set of bytes.

A salt does not make your data less secure, salts are not considered secret.

• Sorry for not being clear earlier. I've updated my question. I am using a passphrase. The point of using PBKD is to not force users to use a specific length password. Jan 14, 2017 at 15:49