Encrypt partition or container file as large as partition?

Elsewhere it is stated that file-based container encryption is somewhat safer for newbies and careless users, compared to full-disk-encryption.

What about using a file-based container versus encrypting a NON-system partition as large as the file-based container? Is it still a little safer to use the container file? Or is there some advantage to encrypting the data partition?

 

File based TC containers are generally safer for the reasons dantz explained in this post (reproduced below):

"Users who wish to use TrueCrypt in the safest possible manner should create only file-hosted containers and should avoid using partition and/or disk encryption entirely. You don't have to worry about Windows screwing up a file-hosted container, since Windows recognizes it as a valid file system object and will protect it as much as possible. You would basically have to delete or overwrite the file yourself in order to screw it up (and yes, this still happens, but at least you can't blame TrueCrypt for it. Can you?)"​

The other side of the coin is that a partition hosted container will operate more efficiently and faster. IMO the big danger with TC partitions is when the TC partition is the first partition on a disk. In that case Windows may decide to add drivers to the first portion of the disk during a Windows install or reinstall, and thereby overwrite the the first part of the TC partition in the process (as Windows doesn't know there is data within the partition). Other TC partitions on same disk are not harmed. This happened to me -- and is the only time I've partially lost TC data. IMO the lessons from that are; (i) multiple partitions serve a protective purpose; and (ii) user should disconnect any disk with first partition constituting a TC container during any Windows installation or reinstallation process.

Whatever you decide to do, be sure to back up all encrypted data, preferably on a different disk, or at least within a different partition.

__

 

I'll try not to get too technical. I inter-act with dan at the "elsewhere" you mention. The key to answer your question is how you define SAFETY in your question. I agree with some of the discussion regarding the simplicity of file based volume safety. If your threat model is not too high perhaps our discussion can stop right here, and likely that is true for most reading here.

BUT --------- from a different perspective on security/safety you have some true considerations when using file based volumes. What are those? A file based volume sets on or is hosted by a filesystem. If you are using windows and the file based container is larger than 4GB than you are almost certainly using NTFS as the host filesystem. When you mount a file based volume that sits on an NTFS filesystem several things change within the journals and logs kept by the filesystem itself. There is NO way around it and the forensic proof is incontrovertible. This is outside of your volume and the scope of TrueCrypt. Again, I am holding back from going on here. So what I am asking you and anyone reading this is to consider if such filesystem marks present a risk to your activities. Those marks are quite identifying of times, names, etc...

And outside of this thread but the "Gorilla in the room" is the uncountable marks in the windows OS as you use the files and data within your volume. The part about whether the volume is device or file based doesn't matter regarding these. I feel my post may have been more than your basic question but sometimes people don't even pause to think about the overall picture. Not trying to be a "buzz kill". LOL!!

 

There's another issue. Maybe it's already been raised.

Sizes of TrueCrypt file containers are fixed. If you create a huge one, moving it will take a long time, and you'll eat up tons of space.

But if you create lots of small ones, the Gorilla in the room becomes very large

Your best bet is encrypting a fresh USB3, and treating it very kindly.

For that, would it help to first create small "buffer partitions" on both ends of the disk, and fill them with random data? If so, how big would they need to be?

 

@mirmir -- The "dummy partition(s)" at the beginning, or beginning and end, of a USB3 TC drive is really a good idea IMO, as various softwares can add USB or flash drive drivers to a USB drive and some anti-malware programs may add malware protection at the beginning of a flash drive when it appears there isn't data that might be harmed.

As to size, 128MB might be a good bet since Microsoft basically adds a "dummy" 128MB partition to a GPT disk to allow for various Windows operations. Similarly, it appears that Apple adds 128MB empty spaces at the ends of partitions to allow for system manipulation.

@Palancar -- You make an excellent point. It's easy to lose sight of the forest when concentrating on trees and vice versa. I should note in this regard that I left out a large portion of dantz's post in order to simplify explanation of data protection and loss possibilities in TC; and in the portion of dantz's post I didn't quote, dantz made the point (corresponding, I think, to your precautionary advice) that efforts to decrease the possibility of TC data loss can have the side effect of harming or eliminating TC's "plausible deniability" protections.

__

 

For the gorilla in the room I have found a solution. It's called Shadow Defender. In a recent version that puts changes in ram and encrypts them for when it runs out of ram and puts them in a hidden area in the partition. It almost makes FDE obsolete.

As long as the first partition is avoided then, what was that statement about a file being protected by windows better than a partition? We're talking about a file as large as the partition so no space for logs or journals. What protection?