Is my data written to a TrueCrypt volume only when it's dismounted?

August 17, 2013 11:50 PM

I'm very interested in TrueCrypt, and am experimenting with moving some of my files (especially stuff I keep in my Dropbox) into TrueCrypt containers. But there's one possible scenario that concerns me, and about which I can't find any solid information -- not on TrueCrypt's site, not via Google, and not here on the green: What happens to my newly generated data if my computer crashes before the TrueCrypt volume I'm working in is dismounted?

Let's say I mount a TrueCrypt volume, and open up a Photoshop file inside it. Then I spend several hours working on that file, saving regularly as I go. Obviously, if I close the file and dismount the volume properly, I know all my work will be there next time I mount the volume. But what if my system hangs or the power goes out before I dismount the volume? Is all the work I've done since mounting the volume lost? Or will it be there when I boot up and remount the volume?

Another way of asking this is: Does TrueCrypt continuously write my data to the container while it's mounted? Or does that data live purely in RAM while I'm working on it, and get written to the container only at the time of dismount?

(I do understand, of course, that a mounted TrueCrypt volume in the local copy of my Dropbox is not synced to the cloud until dismount.)

posted by Artifice_Eternity to Computers & Internet (7 answers total)

Best answer: It must write in real time, because otherwise either:

1. There would be a memory cost - all unencrypted "saved" files get saved in memory until unmount.
2. or, Files are saved somewhere unencrypted, which is a rather huge security hole.
3. In addition, all the encryption and writing would occur at unmount, which would cause a potentially very long delay between issuing the command and actual unmount.

I haven't used TrueCrypt very much, but every other "transparent" filesystem encryption method I've used writes to both encrypted partitions and encrypted disk images ("file containers", "virtual disks") on the fly. If there's a crash, the filesystem is just as intact as if it were not encrypted and had crashed.
posted by WasabiFlux at 12:01 AM on August 18, 2013 [1 favorite]

Note that even normal filesystems don't write stuff to disk instantly. The usual metric is that stuff is committed to physical storage "fairly soon", perhaps within a minute or two but potentially much longer. Part of the unmounting process is forcing any lingering data to be written. This is why it is important to unmount disks before you unplug them.
posted by ryanrs at 12:07 AM on August 18, 2013 [2 favorites]

Best answer: The Pipelining section in the TrueCrypt documentation implies that thigs are as WasabiFlux says: encryption/decryption is done on the fly, and data hits the disk as soon as your application/OS decides to flush to disk - no intermediate caching is involved. In other words, you run the same risk of data corruption as if TrueCrypt was not involved, i.e. very little.

You still need to unmount the volume, but that is not a TC issue - it's because your application/OS may not have flushed data to the TC volume yet, just as it would do with a regular disk.
posted by Dr Dracator at 12:12 AM on August 18, 2013 [2 favorites]

Response by poster: Thanks, Dr Dracator... I just now found that page on pipelining myself. It's reassuring. And it makes sense, given your point number 3, WasabiFlux; I've already observed that TrueCrypt volumes seem to dismount instantly, even if multiple gigabytes of data have been moved into or out of them since mounting.
posted by Artifice_Eternity at 12:16 AM on August 18, 2013

does that data live purely in RAM while I'm working on it, and get written to the container only at the time of dismount?

Mounting and unmounting are not even close to being the same thing as loading and saving. If you think of your TrueCrypt container file as logically equivalent to a USB thumb drive, then mounting is the equivalent of plugging it in, and unmounting is safely unplugging it.

The Dropbox sync behaviour makes sense if you assume that a "plugged-in" container gets locked for exclusive use by the TrueCrypt driver, meaning that the Dropbox process is denied access to it. Locking of in-use files is pretty much the norm for Windows.
posted by flabdablet at 11:35 AM on August 18, 2013

If you just want to encrypt files rather than a disk, wouldn't it be easier to use a file encryption app (such as AxCrypt), or to replace Dropbox with a similar service that has client side encryption such as Logmein's Cubby product, or to use a product such as SafeMonk that automatically encrypts files before they are sent to Dropbox?
posted by Dansaman at 9:50 PM on August 18, 2013

Response by poster: Dansaman, I haven't heard of any of those programs. Thanks for the suggestions, but at this point I've got the TrueCrypt + Dropbox solution working very nicely.
posted by Artifice_Eternity at 11:45 AM on August 22, 2013