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.

James Bradbury
  • 2,017
  • 19
  • 27
  • James, please see some of the comments on the accepted (but dangerously incorrect) answer. – forest May 22 '18 at 04: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 May 23 '18 at 05:44

4 Answers4

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.

Adi
  • 43,808
  • 16
  • 135
  • 167
  • 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 Nov 12 '13 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. Dec 23 '15 at 02: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 Dec 23 '15 at 02: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 May 22 '18 at 04: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.
pwnd
  • 103
  • 5
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.

M. Maier
  • 21
  • 1
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.

WiringHarness
  • 111
  • 1
  • 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 Feb 25 '14 at 01: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 Feb 26 '14 at 03:34