4
$\begingroup$

I am encrypting files for storage in an untrusted location, using a custom Java program to do that. There is only one user, but there are many files. I am using AES in CBC mode with PKCS5 padding, and the key is created from a single passphrase using PBKDF2.

Question: Would it increase security if I used a different salt for encrypting each file, or would that only make sense if I also used a different passphrase for each file?

The posts I could find deal with a multi-user scenario, where of course you need per-user salts. But I have only 1 user and 1 passphrase, so creating a new key for each file feels wrong to me.

Improve this question
$\endgroup$

2 Answers 2

Reset to default
6
$\begingroup$

In a scenario such as yours, where there is only one password/passphrase, but it is used as key material for the encryption of multiple CBC encrypted files, you will (as you noted yourself) obviously not make it any harder for an attacker to compute your password, should you use a salt.

However, using a salt would mean that the encryption of each file is independently keyed, which might increase resistance against collisions in the CBC chaining state, should you use the same password for encrypting a very large number of very large files. Since you are using AES-CBC and AES has a 128 bit block size, you would have to encrypt billions of GB sized files to get close to a 0.5 probability there would be just one such collision (in two 128 bit blocks somewhere), but depending on your security requirements, even such a small risk might be unacceptable. An alternative to using salts, would in such case be to use a cipher with a 256 bit block size instead of AES.

A third alternative would be to use random keys for each file, and only encrypt that file specific key using the key you derived from your password. If you put those encrypted keys together in a separate index file, you will get two additional benefits:

  1. Changing the passphrase will become much cheaper, in particular if you have a large number of files or very large files. Changing the passphrase might, or might not, be something that improves your security. Obviously, if an adversary at some point in time gets hold of all of your files and is able to compute the passphrase you were using at that point in time, you gain nothing by later changing the passphrase. The file specific keys (for the files that existed at that point in time) will already be compromised.
  2. However, using random file specific keys, will make it possible for you to put together index files for other users, containing only the keys of the files those users are supposed to get access to.
Improve this answer
$\endgroup$
8
  • 1
    $\begingroup$ @rath: You seem to be talking about an implementation detail, but perhaps I am missing something. Why not simply store all information required to decrypt the individual file (except the passphrase, of course) in the individual file itself? $\endgroup$
    – Henrick Hellström
    Aug 12, 2013 at 11:17
  • 1
    $\begingroup$ @Thomas: Using a key encrypted random encryption key, means that each file is independently keyed. The only consequence is that CBC mode state collisions will be less likely. Should the number of files be very large, this might be something necessary. $\endgroup$
    – Henrick Hellström
    Aug 12, 2013 at 19:08
  • 1
    $\begingroup$ @Thomas You should never use a password-derived to encrypt more than a small amount of data. If you change your password, then you'll need to reencrypt all the data that's encrypted with it. If your password is compromised, then the data encrypted with it will be compromised even if the ciphertext is exposed in the future. Additionally, using the same key to encrypt multiple files makes it impossible to grant someone access to one file only. So encrypt each file with a different key, encrypt the file encryption keys with a random key, and encrypt the random key with the passphrase key. $\endgroup$
    – Gilles 'SO- stop being evil'
    Aug 13, 2013 at 17:22
  • 1
    $\begingroup$ @Gilles: Actually, using a separate key file (as rath suggested in a comment above) is a common way to make it possible to change the passphrase, without having to re-encrypt more than a single, relatively small file. $\endgroup$
    – Henrick Hellström
    Aug 13, 2013 at 17:27
  • 1
    $\begingroup$ @HenrickHellström Well, yes, rath and you had already said that but without explaining why. CBC collisions are a rather theoretical risk in most scenarios. Password repudiation is a very real concern, it's real reason why an indirect key scheme should be used. $\endgroup$
    – Gilles 'SO- stop being evil'
    Aug 13, 2013 at 17:36
0
$\begingroup$

Your feeling is correct. Using a different password will impact usability, unless you can keep as many passwords as files in your head at the same time. If you can't (I'm assuming the only user is you) you might end up writing them down somewhere, or choosing really easy passwords. The first is bad depending on your threat model, the second is always bad. As an aside, you might want to consider using a passphrase instead of a password.

Using a different salt would increase security because it would force the attacker to repeat the attack with each file. You can safely store the salt in the clear (perhaps as part of the filename). As a bonus, you can later add more users without changing the salt policy.

Improve this answer
$\endgroup$
3
  • 1
    $\begingroup$ This is not quite clear to me yet. If an attacker managed to find the passphrase, which is the same for all files, he would be able to decrypt all files, because their salts are public. It wouldn't matter what the individual salts are. Wouldn't security even decrease with individual salts, because there is a slight increase in chances that one of the attacker's rainbow tables can be used? $\endgroup$
    – barfuin
    Aug 11, 2013 at 21:45
  • $\begingroup$ I am using a passphrase, not a password. Just updated the question accordingly. $\endgroup$
    – barfuin
    Aug 11, 2013 at 21:51
  • 1
    $\begingroup$ Good question. Salts are in place to defeat rainbow tables, and if you use enough bytes (32 should do it IMO), it wouldn't even make sense for an adversary to try generating a table foe each possible salt. To draw a parallel, that's why websites use (should use anyway) a different salt for each user. Yes, if the attacker found the password you're done. If you keep the salt secret however, you are in fact turning that into a password, so now you have to keep track of 2 things. See the answer by mikeazo in the question I linked for more. Cheers @Thomas $\endgroup$
    – rath
    Aug 11, 2013 at 21:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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