I got this idea from somebody's post in the thread about the guy with cp, about having a program to encrypt 2 files with separate passwords in the same encrypted file(Although the concept would work well for a whole fs.). As input, you provide a number of files and passwords. It then gets the total size of all the files, and rounds up to the next power of 4(So as to have plausible deniability of extra size.). It then uses random(or pseudo-random) numbers to fill the entire buffer. The files are encrypted with an encryption algorithm(Which is unimportant to my scheme, as long as it gets rid of noticeable patterns, like those used in picture/video/music formats.). Then it creates a list of how to distribute chunks(of whatever size, it's unimportant in the big picture) of the files using random numbers, and stores the encrypted list at the offset, in the encrypted file, determined by a hash of the password. Any conflict between lists and file blocks is resolved by picking a new random offset that works for the block. Any conflict between lists is resolved by failing and returning and error.

To decrypt, you enter the password, which is hashed to get the offset of the encrypted block list. The block list is then decrypted, reviling the offsets and order of the blocks of the encrypted file. The blocks are assembled into a single encrypted file, and the file is then decrypted.

The distinction between random and pseudo-random is unimportant. Pseudo-random would work fine, considering there are many algorithms for them, and there would be no feasible way to determine which was used in order to reverse it.

Please point out holes in this scheme, and give possible solutions if available.

Tyler: I doubt there are any encryption experts on this forum, and even if there were they would not take to time to analyse your scheme because this problem (deniable encryption) has already been examined and the current best solutions from the current best cryptographers are already published and used in various freely available programs.

If you are really serious about encrypting something where exposure could ruin your life then I would strongly suggest that you don't go and invent your own scheme to do it. Since there is so much at stake (your future freedom) then it is wise to use methods and procedures that expert cryptographers have designed and tested. Do you really feel comfortable with entrusting your future freedom to an untried and unproven scheme of your own devising?

So many people in the past have invented their own special encryption schemes thinking that is was wonderful and whatnot, but then later discover to their horror that methods to break it are trivial and simple to apply.

I have nothing worth encrypting, so I'm okay, for now;this is just a thought experiment, that I may materialise into code if no unfixable holes are pointed out. The bit about it being risky can be countered by the fact that it builds on other, already proven, methods of encryption. The best part is that it can contain as many files as you want, although the user must use common sense. Saying a 100GB encrypted file just contains one decoy video would never work, obviously. A possible solution to the size problem would be to allow the user to enter the size of the encrypted file(which would cause an error to be raised if it is too small). This is good for 2 reasons. 1) The bigger the encrypted files, the more meaningless bloat there is. 2) The extra size of, say, a video, is easily explainable by saying you told the program to make a huge file so as to hide the data in it.

BTW, it's completely plausible that you would use this program to encrypt a single file, which would eliminate the possibility of guilt by association. Meaning that they can't say that you're using an encryption algo that has to contain many files, and that you aren't revealing them all.

Did you read it? If it's so easy to break, what hole did you find?

Tyler: Just building upon and already proven scheme does not give you automatic proof that your new scheme also is secure. Really, this is a known problem with encryption, you can't simply take AES do some manipulation and expect it to always still be secure. There are so many pitfalls and subtle things that can expose details. Certain patterns might be present that reveal something.

Plus, your challenge here for us to point out mistakes is useless to you. 1) No one here is an expert (not that they have admitted anyhow). 2) Even if someone does spot something they might not tell you. 3) Even if someone does tell you of a problem, there can still be more problems. 4) Even if told a problem and you "fix" it, maybe the "fix" creates another problem. 5) Even if everyone here is perfectly honest and points out everything they see and you fix all of those things and the fixes are good. You still won't know if there are more problems. It could be that a real expert comes along later and says "Hey, there is an obvious error here. Wow were you really using that scheme? Ugh!".

Basically you will never now if your scheme is good or not. Without proper exposure and peer review and many years of study and examining there is absolutely no way anyone can say your algo is good enough.

Here is my suggestion: Just use TrueCrypt and make sure you follow all the rules and procedures for using the deniable encryption mode.

And if you really have nothing to encrypt then, well, I guess it doesn't matter what you decide, since you won't be using it anyway.

And, no, I didn't even read you scheme. I've seen so many schemes like this all over the Internet that I don't have time to analyse them anymore. Most of them have far too many problems to even try to fix them. Not that I am saying your scheme is bad, I don't know, it might be perfect, but it is impossible to know either way.

Can you provide the algorithm in outline form - I have difficulty following your prose? Are you implying the random buffer is a type of OTP? Is there some kind of mixing between files?

Here is my method.

Is that any better than my "prose"? [/list]

Basically, it's an encrypted file system within an encrypted file, that uses different encrypted metadata depending on the password you use to access it.