1

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 2 '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 2 '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 2 '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 3 '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 3 '17 at 17:29
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 :-)

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

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.