Is salting values an essential good practice with Rijndael or AES encryption?

I've implemented an encryption function using the Rijndael/AES encryption provider in .NET. My "understanding" of the algorithm suggests that as long as the Key and IV aren't compromised then the data is safe. However I've read on some sites where salting passwords is the best practice. The confusion for me comes in where there seems to be a though that salting is only necessary wi开发者_如何学Goth hash function based encryption. What is the best practice when using Rijndael or AES, and what value should be salted(clear text, Key, IV)?

If you encrypt different datasets with the same key and same IV, the same clear text always results in the same encrypted text. If several users have the same password, they will also have the same encrypted password and it will be obvious from the encrypted data that their passwords are the same.

If you add salt to the clear text before every encryption, the same password will result in different encrypted strings, because (usually) there are different salts used in each case.

So if you use the same key and IV for all the password encryptions the scenario is the same as when using a hash functions and using salt has the same advantages. If you use different keys or IVs for each encryption, the same passwords result in different encrypted text and you don't have these problems. In this case salting doesn't improve anything.

The IV is the salt. It is perfectly safe to prepend the IV to the ciphertext when sending the ciphertext across the network or saving the ciphertext to disk. Make sure that the IV is generated by a cryptographically strong pseudo-random number generator for each message.

In strong cryptography, the only secret is the key. The IV is not a secret and neither is the ciphertext.

However, if you are using the same IV with the same key for multiple encryptions (a "session IV"), then you must protect the IV just as you would protect the key.

Salt is only meaningful for hashes; it prevents pre-computed dictionaries.

There is no value in using salt for encryption.

If the key is derived from a password, the key derivation algorithm should include a salt. Mainstream algorithms (such as PBKDF2) do.

For the encryption part, established modes of operation all include an IV that, in a way, is itself similar to a salt. It is not necessary to further randomize the data before encryption.

The IV is safe for public knowledge, and usually you want to generate a new one for every encryption operation. If you used the same one each time, then you would be generating the same ciphertext for the same encrypted values. This is somewhat the way WEP encryption was cracked. (http://en.wikipedia.org/wiki/Initialization_vector)

Hashing the value you are going to encrypt doesn't do much for you. The IV already introduces a randomization factor into the ciphertext, and you don't want to have to parse the salt out of the decrypted value.

As SLaks mentioned, salting is only useful for a hash. To further this, it is useful for a hash you are going to compare with another hash to see if the value put into the hash function both times is the same value. The salt prevents dictionary attacks (aka Rainbow tables) where people have gone through and pre-calculated the hash values for several inputs. The salt means that the calculated table has to be generated for every salt value.

There is more you can do with the salt value too, but this is one example.