13

The TrueCrypt website has some detailed information on how to backup (TrueCrypt non-system volumes) securely, summarised below:

  1. Create a new TrueCrypt volume
  2. Mount the main volume.
  3. Copy all files from the mounted main volume directly to the mounted backup volume.

My question is: Why is this necessary? Why not simply copy the encrypted TrueCrypt container file to your backup service/device? According to step 5 of the TrueCrypt tutorial, this container is a normal file that can be copied, moved, etc.

Surely copying this encrypted file to a possibly insecure backup medium is the simplest and most secure way to backup?

What advantages could there be to the method mentioned on the TrueCrypt website? It mentions at the start about files in the volume possibly becoming corrupted - is that relevant? In this case I'm not interested in hidden volumes or plausible deniability.

Improve this question
2
  • James, please see some of the comments on the accepted (but dangerously incorrect) answer.
    – forest
    Commented May 22, 2018 at 4:50
  • Thanks, I've seen your comment. You may be right, I'm not qualified to say - which is why I asked this question in the first place. Unless there's a consensus of opinion such as a well up-voted alternative answer, I'm not going to change my accepted answer.
    – James Bradbury
    Commented May 23, 2018 at 5:44

4 Answers 4

Reset to default
17

Backing up the TrueCrypt container means that you'll end with a timeline of your encrypted volume, and all of those versions share the same key. Having different versions of the container with the same key gives the adversary two advantages:

  • Information leakage: The adversary will know which sectors of the volume changed.
  • and, as a consequence, a compromise of the plausible deniability in case you have a hidden volume inside that volume.

In the real world, however, the case is quite different. If you don't have a hidden volume or you don't care about the adversary knowing about your hidden volume, then having some backups of the volume isn't really an issue. The cryptographic concerns (cryptanalysis) are, so far, only theoretical.

Improve this answer
4
  • Thanks. It's good to know that TrueCrypt are so thorough with their advice and thinking ahead about potential attacks. I think in this case copying the encrypted file seems reasonable.
    – James Bradbury
    Commented Nov 12, 2013 at 11:43
  • I remember reading that having multiple versions of an encrypted container with the same key would give rise to possible cryptanalysis attacks. Was this any true ?
    – Wadih M.
    Commented Dec 23, 2015 at 2:04
  • 1
    @WadihM. It's not that easy to answer, really. TrueCrypt uses XTS mode for the block ciphers. You see, XTS is pretty much ECB in that each block is independently encrypted (but with some "tweaks"). Patterns of empty space are quite easy to spot with XTS, and with enough backup samples it's possible to detect more patterns. There isn't much public work done on this, so it's hard to say. My original answer still applies; yes, it's possible, but there's nothing tangible yet.. it's only "pre-theoretical".
    – Adi
    Commented Dec 23, 2015 at 2:38
  • -1 because this is incorrect and dangerous advice. It does not just risk revealing a hidden volume, it also reduces security to that of ECB mode. XTS is very, very dangerous when used this way. It is not "just theoretical", much less "pre-theoretical". A basic understanding of XTS or XEX makes it obvious how bad it is if you have access to the changes to a single sector over time.
    – forest
    Commented May 22, 2018 at 4:49
1

According to TrueCrypt security requirements, there are 2 main concerns regarding volume clones/copies:

  1. Original volume and backups (copies) would use the same key set.
  2. Ability to observe the changes between the backups might aid cryptanalysis if the attacker has access to the backups.
Improve this answer
1

Another way to address this issue would be to copy the container file and encrypt it eg. with openssl before backing it up. For subsequent backups you should use different keys/passwords for backup encryption.

It would be fairly easy to develop a scheme for rule-based key/password generation. Thus, you would rely on a recording passwords. This would make the revovery process much safer.

In my view, this would be easier/more comfortable then the approach the trueCrypt manual outlines.

Improve this answer
1

Another considerable advantage is speed. If you have a large TrueCrypt container that is not full, your backup only needs to copy the bytes in use rather than the whole container. Standard tools like rsync or Windows robocopy will only copy files which have been changed, which is typically just a small fraction of your files. If you copy the container, you have to transfer every byte, and you generally have to dismount the drive so you have no access to your files at that time. On my eSATA drive, copying a 25GB container takes 15 minutes, which seems short enough until you start waiting for it.

If you have access separate computer on which to mount the backup container, rsync will transfer the changes securely via ssh, so you could roll your own remote backups.

Improve this answer
2
  • How do you account for the time to create the new backup Truecrypt container, when following the "Create a new TC, mount both, copy files" advice?
    – Anti-weakpasswords
    Commented Feb 25, 2014 at 1:41
  • Personally I would re-use my containers, but even with a fresh volume every time, it all depends on the link speed and the % of the volume used. Creating a TC on a remote computer with a bus connection to its hard drive is much faster than transferring a complete volume over typical wifi or 100BaseT Ethernet.
    – WiringHarness
    Commented Feb 26, 2014 at 3:34

You must log in to answer this question.

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