Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

Given a (TrueCrypt) encrypted volume on one device A, what is the more secure way to back it up via a VPN connection to the physically far away device B?

  • Backup the data: Requires the volume to be mounted on both devices, which a physical intruder could abuse to obtain one of them while the container is open, thus rendering the encryption useless. On the other hand, an incremental backup is easy. The transmission itself should of course still be secured...
  • Backup the container: No device requires the containers to remain open. However, unless small file changes only change small portions of the container and these changes are tracked, this quickly involves a lot of unnecessary data traffic
  • Backup individually encrypted files instead (not using TrueCrypt but e.g. encFs): Seems to eliminate the disadvantages of the other two methods. But since the encryption should be bound to one single passphrase/keyfile/... this increases the risk of a known-plaintext attack, should too many trivial files happen to be encrypted.

So, is there the secure backup solution?

share|improve this question
    
All of these can be equally secure - which you choose will not depend on security functionality. What are the constraints you are working within? If the constraint is lowest traffic volume can you update the question accordingly? –  Rory Alsop Oct 3 '12 at 13:00
    
@RoryAlsop I wouldn't say traffic volume is a constraint, but (before Polynomial's answer) a non-diff-based 500GB TrueCrypt container would have been too much... The only "constraint" is that currently our single NAS uses a TrueCrypt container, but that could be changed. –  Tobias Kienzler Oct 3 '12 at 13:19
add comment

2 Answers 2

up vote 4 down vote accepted

Back it up using diff-based copying of the encrypted volume image. TrueCrypt uses XTS as its mode of operation, which means at most you'll alter two encrypted sectors (sector n and sector n+1) per unencrypted sector you modify. Every time you modify a sector (or file) on the disk, it'll just have to upload that sector and the next sector.

Sectors are 4096 bytes by default on NTFS, which means you'll transfer 8kB minimum each time you make a change. However, in most cases writes will be to adjacent sectors, which means that if you write 1MB to disk, you'll actually only have to back up 1MB + 4kB, since the cascading effect means that only one extra sector is altered.

share|improve this answer
    
Thanks for this information. Since @SeanMadden mentioned it, what will happen if I try and backup an unmounted container? Can this yield an inconsitent state corrupting the entire container? –  Tobias Kienzler Oct 3 '12 at 13:57
    
It shouldn't make a difference as to whether the container is mounted or unmounted when you make the backup. The resulting backup should be in exactly the same state as the real original. –  Polynomial Oct 3 '12 at 14:09
    
My comment should actually have been "... backup an mounted container...". What does rsync do when the file it's currently backing up is being changed? And what does this mean for the TrueCrypt volume / the included ext3 filesystem? –  Tobias Kienzler Oct 9 '12 at 14:40
1  
I'm not sure exactly how rsync works internally, but the way I understand it is that a transactional diff is generated on both systems, so the diff on system A is generated, uploaded to system B, then applied. To improve performance, they usually limit the timing on diff generation, so 7 distinct modifications inside a 10 second block will get rolled into a single diff. This helps increase network performance and ensure solid copies. I wouldn't recommend having it open on both sides at the same time, though. –  Polynomial Oct 11 '12 at 18:17
add comment

To expand on @polynomial's answer, the binary-diff method is the correct method to use for an unmounted encrypted container (TrueCrypt, DMCrypt/LUKS, or otherwise).

The fastest (and most efficient) method I've found is to use the 'rsync' command. I'll point you at the wikipedia page that describes the algorithm in detail, suffice to say that it is optimized to handle binary data in almost precisely the way that @polynomial describes.

Cheers.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.