Need to sync arbitrary files within two TrueCrypt containers; one container is a backup, the other the one actively used by me, both are local during the transaction.

Current concern security wise is that there would be "data leaks" that would result from the sync tool being used; for example, the sync tool producing indexes that when be stored unencrypted on disk.

Any suggestions, or insights into the possible attack vectors that might result from using a sync tool as described?

UPDATE: I've removed the reference to "on Windows", since while the answers, and question they addressed deal with Windows, these answers (putting aside the sync tools used) apply to Windows, Linux, OSX, etc -- and I would not want the person reading the title of the question to believe the question only applies to Windows, since it does not, and given the importance of securely executing backups of encrypted data, I thought it best to make the question as accessible as possible.

  • 2
    Just to clarify: You want to sync files from inside one tcc to another? Or do you want to sync arbitrary files to two tcc? Both would mean that you have to mount both container at the same time.
    – twobeers
    Apr 27, 2012 at 8:59
  • I'm confused why you think my answer is off topic. You state "Need to sync arbitrary files within two TrueCrypt container". So you are talking about syncing files within mounted containers. I talked about a security issue about backups on truecrypt container AND reference a page on the truecrypt site. I don't know how it doesn't answer your question. You asked about leaks and i told you about seeing which part of the sector change and that it could be used as an attack.
    – user5575
    May 5, 2012 at 5:07
  • Oh you're not asking about security issues when making backups via sync, you're asking about security leaks from sync tools when making backups. I'll make a quit edit. (edit 2)
    – user5575
    May 5, 2012 at 7:34
  • why did you -1 me anyways?
    – user5575
    May 9, 2012 at 20:34
  • @acidzombie24: The current -1 on your answer is not from me, I removed my -1 and the related comment about your answer not being an answer after your edit, though within a short time after someone else gave it a -1. Just gave your answer a +1 to counter the -1.
    – blunders
    May 9, 2012 at 23:04

3 Answers 3


Current concern security wise is that there would be "data leaks" that would result from the sync tool being used; for example, the sync tool producing indexes that when be stored unencrypted on disk.

You are correct to believe there is a risk of data leaking as a result of indexes. How much of a risk that is depends on what exactly is indexed.

A while ago, I lead a project to build something a little like dropbox. To compare directories across runs, we used the path name, a sha256 hash of the contents if not already computed, various timestamp information etc.

Clearly, if a sync tool were to store this information about files stored in an encrypted container, the attacker would also have access to them. The exact risk of that really depends on your given scenario.

I suspect, however, there are bigger risks in play than you think. Let's assume, for example, that on opening a file, your innocent piece of software creates a copy so as to not corrupt the individual - however, you've mounted the file system read-only, so it handily creates a copy of the file in your temp folder. Great, except - it just copied your data from an encrypted partition to an unencrypted one, thereby leaking it.

The same could be true of sync tools. This would be a fairly bad way to build one - but it is conceivable the tool could copy files to a temporary location in progress. Again, you have a leak problem.

To be a bit more realistic - let's assume the sync tool copies the files in memory by mmaping them and copying between them. What if you experience a system crash during this update and your app happens to be core dumped? Heck, what happens if the truecrypt drivers' memory is core dumped too? It might well contain unencrypted file data.

The fact of the matter is you're unlikely to be able to deduce the contents of entire files from any of these scenarios - but like getting damp in your house, something will leak, somewhere. The only way to be totally sure you have everything wrapped up is to do the obvious: encrypt the whole lot. Swap, disk, everything.

So to answer the question you asked: an attacker can clean whatever the sync tool stores. Have a look. Grab Process Monitor, see where it is storing data and then look at what's in it. That'll tell you exactly what data is being leaked.

To answer the question you didn't ask: there's no way to be absolutely certain you are not going to leak something using a truecrypt container on an unencrypted system.


The question is now "how can I do file level synchronization between two open TrueCrypt containers on a single host without any local leakage of data from the sync tool?".

The answer is you probably can't - certainly none of the well established file sync tools (unison, rsync, SyncToy, etc.) promise not to have such leaks. Their focus is purely on being efficient and reliable.

This is presumably because doing so would involve a lot of very hard work to support an obscure use case. Firstly, if someone can get close enough to your machine to take advantage of this sort of leakage, then you have worse problems. And secondly, if you really need to control for this vulnerability, then there are a couple of steps you can take that work regardless of the sync tool used:

  • use full disk encryption so any leaks are also encrypted.
  • sync closed volumes, eliminating all sync tool leakage at the cost of performance.

Note: I specify sync-tool leakage here since there are other sorts of leaks: differential analysis of the containers, or leaks from the tools you use to manipulate the contents of container once open. But again, if the attacker has compromised the machine enough to perform these attacks, then you have worse problems. Why do a difficult differential analysis of container changes when you can just replace the TrueCrypt binary with something that emails the contents of the container to you?

(One last point: there are many good open source tools for file syncing, so a third alternative is to fork them into your own super-secure version.)

  • 1
    Main thing thing I want to point out is the question is really about if SyncToy would have data leaks that would make the TrueCrypt container, and if so, if there's anyway to prevent them. Mainly the issue that came to mind is that SyncToy works by creating indexes that might contain among other info: filenames, change-timestamps, etc. Make sense? Again, thanks!
    – blunders
    Apr 26, 2012 at 13:56
  • 1
    @blunders If you're just using SyncToy to copy the container files, then you have practically no risk of leakage. If you're actually opening the containers, and using SyncToy to copy data between them, then you would stand the risk of leakage like the ones you are suggesting. Whether SyncToy actually handles data in the manner you're suggesting (indexes, etc) may be a better question for Super User.
    – Iszi
    Apr 26, 2012 at 16:06
  • 1
    @blunders The only 100% secure & reliable way would be a sync of the container files themselves. However, this presumes that only one of the containers has any newer data, and it's not going to be any faster than a manual copy of the entire container file. Any other solution is likely to be as insecure as SyncToy when handling opened containers unless there is some software that specifically makes a point to securely destroy its indexing data after each sync.
    – Iszi
    Apr 26, 2012 at 16:48
  • 1
    @blunders And, again, whether or not indexing or other metadata is actually generated or left behind by SyncToy (or others) is probably something that should be asked elsewhere - although it is important to know in evaluating the security of the tool.
    – Iszi
    Apr 26, 2012 at 16:49
  • 1
    We use DFS-R to sync files at rest, as a container file is a file at rest. A quick search for "sharing violation" errors in the DFS-R log reveals nothing. Due to the way file containers work (can only be mounted in one location, I believe), you will not run into replicating the file as on the receiver, the file will not be in use; unless it is in fact, in use. But then you have another "thread safe" like issue to solve with your "shared" file containers.
    – brandeded
    Apr 26, 2012 at 19:58

IMO the easiest and fastest way to sync is mounting two containers and using your favorite tool to sync them (i kind of like robocopy). When you have a backup use a DIFFERENT container. If one container is a copy of another than someone who gets access to both can look at the sectors that change and use that information.

If you make two containers than that wont be an issue because everything would be different regardless if the same files in the same places are in there.

I don't know which 'sync tool' you may use but if it isn't storing temporary information (say your local temp area) while syncing you should be fine. Some people think you should disable virtual memory when using encryption but IMO that isn't required and just paranoia.

-edit- If your backup can be accessed by someone repeatedly (instead of just the current and backup the above assumes) you may consider making a new container each time and copying all the data as recommended by truecrypt http://www.truecrypt.org/docs/?s=how-to-back-up-securely

-edit2- It now appears you are asking about leaks when using tools. You didn't mention any tools so i can't comment much. As long as the tool doesn't make temporary files when copying or has a db/information outside of the container (sometime it is in the users app data directory) than you should be fine. As i mention above i like robocopy which is simply an advance command like file copy program. See http://ss64.com/nt/robocopy.html I personally don't copy attibute data nor want files deleted in the remote volume. I think i normally use robocopy srcDriveOrFolder dst /S /W:1 /R:1


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .