2

I'm developing a simple utility to solve a very specific issue: I want to store all my pictures on cloud. Family pictures, nothing kinky, illegal or death-threatening. the requirements are:

I want them to be at least "obscured", as in "not automatically viewable and indexable when someone sweeps my storage account", like Google or Microsoft when they're collecting stuff to train their cognitive services or any corporation mega.co.nz gives access to my files to. Better would be securely encrypted, obviously.

I need to be able to detect changes to a single image and upload only that, thus avoiding huge archives.

I have developed a sequence of operation using only standard libraries (apache commons crypto mainly) that should be secure by current standards:

[one time, when running the encryption]

  1. input a password (any length)

[next steps are repeated for each file]

  1. generate a secureRandom salt (32 bytes)
  2. compute a 16 byte password+salt hash using PBKDF2WithHmacSHA512 (1000 iterations)
  3. generate a secureRandom IV (16 bytes)
  4. ZIP the single file (this is toggleable as it's useless for images)
  5. AES encrypt the file using AES/CBC/PKCS7Padding

I know that this will not conceal the name, nature and size of my files, (contrary to what Cryptomator tries to do, for example, but webdav is a pain when trying to detect file changes), but that should be fine by me unless it enables cracking of the whole encryption somehow.

Now I need to store the salt and the IV, and currently I have decided to store them in a metadata JSON file in the same place where I will store the encrypted file. I have read and understood that the IV must be random but doesn't need to be secret, correct me if I'm wrong, but what about the hash salt? Can I store it with the IV and the encrypted file without threatening any part of the encryption?

  • Why are you using the password? – Limit Jan 02 '17 at 16:09
  • Should I switch to something like a random generated keyfile with a lot of securerandom bytes in that? I think I can do that, it should be trivial, just use a file input instead of a console input when i read the password. what about the salt and IV anyway? is that ok? – francesco paolo schiavone Jan 02 '17 at 18:04
  • somehow i always fear that i can delete the keyfile by mistake while messing around with my pc. I like very long phrase passwords better, even if i can understand the limit in the entropy – francesco paolo schiavone Jan 02 '17 at 18:27
  • What if you change your password, before you can start using your new password, all your files will need to be re encrypted, right? – Limit Jan 03 '17 at 17:12
  • The way I see this, your entire security is dependent on your password. If an attacker has access to your directory, they can access both your salt and IV. The thing that they don't have for decryption is your password. – Limit Jan 03 '17 at 17:29
  • @Limit how can I make it so that I don't have to re-encrypt everything if I change password? I should make the current password a keyfile, then use my password to encrypt the keyfile, so that if I change the password i just have to decrypt and re-encrypt the keyfile. did I get it right? but how do i make it so that I don't need the password when decrypting but just the encrypted keyfile? – francesco paolo schiavone Jan 05 '17 at 14:42
  • So you used your password to decrypt a master password. This master password is used in place of your password in your algorithms. So when you change the password, you just have re encrypt the master password. – Limit Jan 06 '17 at 07:14
  • IV need not to be random, they need to be unique. Same as salt. – Stephane Mar 08 '18 at 12:02

2 Answers2

1

As @Limit commented,

your entire security is dependent on your password. If an attacker has access to your directory, they can access both your salt and IV.

So it should not be a problem storing these.

Your password is going to be the most important item you need to protect :-)

Rory Alsop
  • 61,474
  • 12
  • 117
  • 321
0

Neither the IV nor the salt are secrets so you're okay to store them in the meta data.

What each property is used for

forest
  • 65,613
  • 20
  • 208
  • 262
McMatty
  • 3,232
  • 1
  • 8
  • 16