Storing volume in multiple physical files

Topics: Feature Requests, Users Discussion
Oct 15, 2015 at 8:18 PM
Having big (10s or 100s of Gigas) file will probably draw suspicion to being a disk volume, and this compromises the criteria of plausible deniability

I recommend providing an option of splitting the logical volume into multiple files, preferably with different sizes and names, will possibly reduce suspicion of having something hidden inside

My thinking is:
  1. Adding a logical layer over the physical storage
  2. Having some user friendly way to consolidate the randomly (or selectively) named files into a volume, for example, an encrypted header in the first file pointing to other files, or whatever
  3. Providing options to select name(s), size(s) and path(s) of the files
What do you think about that?
Oct 15, 2015 at 8:36 PM
I think, in theory, this is not a bad idea. In reality however, this would be a overkill.... If one goes for such large container files, he would be much better off creating multiple volumes rather than working with one volume of ie 500GB. If that is the case, then he would better encrypt the whole partition. Also, if your idea is to be implemented, there will be a performance issue due to the fragmentation of the container etc.....

As to the idea of plausible deniability, i am not a big fan of it.... i think in the not so distant future, the laws will be adapted in such a way, that you will be forced to reveal both your hidden and visible volume. If you open only one volume (the outer one), it will be deemed you have not provided the correct password and will be held liable....
and dont tell me this can not work as not everybody makes a hidden volume..... i will tell you then that it is not that everybody encrypts his data in the first place and there may be random files in everybody's computers so forcing one to reveal his password doesnt really defer much from forcing you to reveal 2 passwords....
Oct 16, 2015 at 2:06 AM
Thank you for sharing your thoughts @Alex512

That's an interesting argument, so let me tell you my thoughts. Yes, if you're working with some tech savvy entities that have the power to force you to reveal the hidden volume, then you're in a situation. But why be in such situation in the first place? The whole scenario you propose starts at the point where your container got exposed. I'm talking one step before that; not even drawing attention to a suspiciously large file

Let's put it that way: I'm an investigator/hijacker/whatever who's searching for anything interesting on a computer, I find even a 60 GB file titled Section14.rxm, or Beauty.mvk but it doesn't render as a movie, or whatever, wouldn't this at least draw my attention? But if the container is scattered between several physical files what may look just like tmp or swap files and left where it's normal to have ill-named files, then no way he'll even think about asking, and if he did it'll be a piece of cake to deny
Oct 16, 2015 at 3:15 PM
x0rchid, I fully understand your point..... however, suppose you have an option to divide the container into smaller parts, how big in GB/MB would you make them? 1GB each? 10MB? Just give me an idea....

If i am investigating your PC and I find a 60GB random file, I dont think it will be more suspicious to me than if I would find 60 files of 1GB each..... or 6000 random files of 10MB each.... dont you think? :)

Dont get me wrong - your idea is worth considering! It is just that in security software (and not only), sometimes overloading the product with options and precautions may leave you open to other vulnerabilities..... The code has to be kept as simple as possible..... the processes as transparent and as clear as they can be.... otherwise you have the situation of TC where you can audit it and still miss serious vulnerabilities.......
Oct 21, 2015 at 12:10 AM
This can be easily accomplished by using hjsplit (a free file splitting / joining utility) on a VeraCrypt container file. In theory you could rename each piece to any name you wanted, as long as you knew how to reverse the file renaming before using hjsplit to rejoin the pieces back into the original VeraCrypt container file.
Oct 22, 2015 at 6:19 PM
Not really commenter8... I think the initial idea is to have the volume split into different files and locations and mounted it AS THEY ARE (as still being split into different files) and working with them while the different parts remain separated.....
Nov 11, 2015 at 5:26 AM