Take the 2-minute tour ×
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

Encrypt a single file, chunk-by-chunk, each chunk using different key.
I am a security newbie (only took 2 security courses before)
But currently I am using this encryption method for my Android application, which perform client-side encryption and upload each encrypted chunk into different cloud storage (Dropbox, Box, Google Drive, SkyDrive) {The app is not yet published in google market, and is planned for publish after it is stable}
But somehow I think it seems like it is doing extra works without adding extra level of security.

Steps as below:

  1. Using PBKDF2, I derive 1 master key (Km) and 1 database key (Kd) from two passwords provided by user
  2. Then I further derive multiple partial keys (Ki...Kn) from (Km) using PBKDF2 with random salts. The salts (Si...Sn) are stored in a database encrypted with (Kd)
  3. Then I split a file into multiple chunks (4MB), and encrypt each chunk with different partial key (Ki...Kn)
  4. The information of which salt is associated with which chunk is stored as file metadata in database. (the database is stored in cloud storage too)
  5. The same steps goes for decryption, in reverse way (take 2 passwords from user, derive Km and Kd, decrypt database, retrieve salts from database, derive Ki...Kn from Km + salts, decrypt each file chunk, merge each chunk back to original file.

Initialization vector (iv) is also used when initialize the cipher, but I don't mess anything with it. I follow the original method and I just append it infront of my file chunk as plain text.

As far as I understand the usage of Salt is we don't need to keep it secret. As it simply makes brute force attack slower.
But in my case, I am keeping the salt secret (some people call it pepper, or shared secret)

My main questions are:
1) Is my design flawed?
2) If it is not flawed, does it provide extra security? instead of just slowing down brute force. Or is my design totally pointless and extra?
3) Any else comments are welcomed.

share|improve this question
    
What is the reasoning for distributing a file on multiple cloud services? So is it lost if any of them fails? –  Paŭlo Ebermann May 2 '13 at 19:40
    
@PaŭloEbermann for improved bandwidth utilization, bypassing limited upload size, and some minor security improvement. Yes, if any of them fails, data cannot be reconstructed. But I added erasure coding(RAID5) instead of simple data striping(RAID0), so it protects from several providers fails, depending on my scheme (3+1) (4+2) etc –  tcboy88 May 5 '13 at 13:37
add comment

1 Answer

up vote 4 down vote accepted

Step 1: good job, this is the right way. You can also use bcrypt or scrypt for extra resistance. Make sure you have chosen sufficiently strong parameters, that is, 64-bit salt and 10000 rounds absolute minimum.

Step 2: no! once you have a strong derived master key, you don't need to apply PBKDF2 on any keys derived from this master key. You are just wasting time and effort and it doesn't scale at all. Use HMAC with a random nonce and keyed with the master key.

Step 3: Why not just encrypt the whole file with a single (derived) key? Why would you want to split the file into chunks? If you do have a good reason, ignore this.

Step 4: I.. suppose.

Step 5: Yeah.


Is my design flawed? Well I won't lie to you, it is a bit weird. You don't need to split the file into chunks if you just want to encrypt it. You are making it needlessly complex. Unless you have good reason. Now the real problem is you have no mechanism in place for integrity checking and authentication. That is BAD.

Or is my design totally pointless and extra? Frankly, yes, it is.

Any else comments are welcomed. Do not design your own real world cryptosystem. Either you do it the simple way and have someone competent (or better yet, multiple) look over it before deploying it, or don't do it at all. Mindlessly throwing cryptography at a problem isn't the right approach.

The problem I have with this question is that you have no clear goal in mind. What are you protecting against? What is your threat model? Where is the database stored? Who or what will access it? etc..

Without knowing this, "extra security" doesn't mean anything. More secure than what, against what?


TL;DR: design is flawed and over-engineered, designer should not be designing cryptosystems for real world use (though it's fine to experiment, of course). Best use an existing file encryption scheme (there ought to be millions for Android, but OpenSSL will do fine) and store metadata in a secure database.

share|improve this answer
    
Thanks for the reply! 1) I want to achieve something like a two-pass encryption, thats why I am asking 2 passwords from user. 2) I split the file into chunks, because I am uploading each chunk to different cloud storage (which can benefits from improved bandwidth utilization, and a little bit of security thru obscurity) 3) Another reason for split file is because I am encrypting each chunk in a pipeline method (first 4 chunks are encrypted in parallel), it is faster than encrypt the whole file at once. different key for each chunk is just some add-on, since I have to split file no matter how. –  tcboy88 May 2 '13 at 9:20
    
My idea was, an attacker needs to know many things before he can decrypt my file 1) password for each cloud storage 2) password for file encryption 3) password for database It also protects from bad provider who look at your data For integrity check, I do provide CRC32 or SHA1-256 checksum based on user preference –  tcboy88 May 2 '13 at 9:23
    
oops, forgot to mention that another reason for using pipeline is because each chunk is go through several steps like splitting, erasure-coding, compression, encryption and finally checksum. That's why I will need to process the file chunk-by-chunk in parallel, else it will take a long time. To be honest, the multi-keys encryption is just some add-on to make my school project looks bigger =) If it is really flawed, I will scrap this part out of the project. Needing your further advice. –  tcboy88 May 2 '13 at 10:13
    
@tcboy88 You don't need new keys for every single chunk. You can encrypt with a parallelisable algorithm (say, CTR) with the right IV and with the same key and then simply send that chunk. You'll be able to decrypt it when you get it back (even without other chunks, yes). But you need to store a MAC to make sure the chunk makes it back from the cloud intact (has not been modified by an attacker or simply damaged somehow) –  Thomas May 2 '13 at 10:47
1  
Alternatively to CTR, you can simply use GCM mode which has authentication built-in, not requiring a separate HMAC. You can always send distinct blocks to multiple cloud services for storage, but it does require all of the blocks to decrypt any of them. –  Stephen Touset May 2 '13 at 18:34
show 4 more comments

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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