7
$\begingroup$

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?

$\endgroup$
5
$\begingroup$

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?

$\endgroup$
  • $\begingroup$ I strongly agree with you in not reinventing the wheel! I was just asking because I could not find such library (probably this is gonna develop into a new question...) $\endgroup$ – Jordi Nov 29 '16 at 18:19
5
$\begingroup$

With AES-CBC you usually need a random IV. However, in the case where you use each key only once, like when using password-based encryption with random salts for each file, you can use a fixed, zero IV. So as long as you use a new salt for each file – and even new versions of the same file – you can forgo storing an IV and just use a zero block.

Note that CBC alone will not prevent an attacker from modifying the encrypted file. So you may want to consider whether you also need authentication (i.e. a ).

(BTW, in practice you probably want to prepend the salt, not append, for convenience and maybe performance.)

$\endgroup$
  • $\begingroup$ Personally I think that - if the salt is going to be changed every time - using a derived IV - as Jordi already indicated - is better than using a zero IV. $\endgroup$ – Maarten Bodewes Aug 26 '16 at 10:54
  • $\begingroup$ @MaartenBodewes why? $\endgroup$ – otus Aug 26 '16 at 11:16
  • 2
    $\begingroup$ If just for the general notion that CBC's IV should be unpredictable. And there is of course the idiotic notion that a KCV is the encryption of an all zero block of data (I don't know which idiot came up with that, but he should be shaming in a corner somewhere). And if it doesn't add anything, it certainly should not hurt overly much to derive the IV unless PBKDF2 is used to derive IV and key. In that case you might want to use a separate KBKDF. $\endgroup$ – Maarten Bodewes Aug 26 '16 at 11:22
  • 1
    $\begingroup$ @MaartenBodewes, ok if the zero block is used for something else then, sure, I agree. Otherwise I'm of the opinion that there needs to be a good reason to add complexity. $\endgroup$ – otus Aug 26 '16 at 11:25
  • 1
    $\begingroup$ There is a fine line between configurability and KISS. If you'd want to add a MAC key later on (or even extend to a larger key size than the output of the hash) then having a KBKDF / PBKDF combination could very well pay off. But yeah, not really required for the current protocol, especially if a SHA-256 bit hash or higher is used. $\endgroup$ – Maarten Bodewes Aug 26 '16 at 11:48
1
$\begingroup$

If you're generating the encryption key from the password and a salt with something like PBKDF (or anything else with an extensible output), you can get an IV for free with the same key-derivation process. That will save the (minor) trouble of storing another field in the file, any suspicion on the predictability of the IV, and has the advantage that you can easily generate another key for a MAC with the same system, if you ever need one.

In any case, with a password, you should be using some slow key stretching method to slow down dictionary against on the password.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.