Best way to generate a IV for AES-CBC when encrypting files? The situation is that I want to use symmetric encryption to store some info in files. I'm going to use AES-CBC algorithm. The user is going to remember the password (meaning it will not be stored anywhere but in the brain of the owner of the files) however I'm worried about the management of the salt and the IV.

From several sources I've seen that the salt must be unique and never reused (which imples using a cryptographically secure pseudorandom number generator) but it can be safely appended in clear text to the encrypted data. Is this right?

For the IV I have seen two different approaches:


Similar to the salt, generate in randomly and store in clear text.
Derive it from the password and salt, the same way it is done with the key used to encrypt each block via the AES algorithm.


Which is the preferred / safest way?
Generate a random IV (with a cryptographically secure random generator of course) and prepend the IV to the ciphertext.

Some modes of encryption don't require a random IV, but you can never go wrong with a random IV as long as your RNG works fine. An IV does not need to be secret (it's a matter of terminology — if it had to be secret it woulnd't be called an IV).

In the case of CBC, a non-random IV is safe if the key is only ever used for a single message. Your key is apparently derived from a user password and a salt, which makes it unique for this password-salt combination — but are you always going to generate a new salt when you encrypt a new version of the file? Even if you currently do this, are you sure that version 3 of your program isn't going to do things differently and encrypt several files with the same key?

Use a random IV, generated independently from the salt. The maintenance cost is negligible and arguably negative (it's one line of code, less long than the comment explaining why it would be safe to use a non-random IV), the performance cost is negligible.

Don't forget that CBC only ensures confidentiality, it doesn't protect the file against modification. Strongly consider using an authenticated encryption mode instead, which protects both the confidentiality and the authenticity of the data.

Finally, or rather firstly, there are already plenty of libraries and plugins to do this out there — do you really need to reinvent the wheel?