redundant data in TrueCrypt

Hello!

I've got 40GB of data and I need to copy it to USB hard disc drive. I'd like to encrypt it with the use of TrueCrypt so that nobody can see content of those directories, files and so on. This file is big so I guess it may require some redundant data - what if little piece of this data would be corrupted... How to create, let's say 1% of container size, to keep this redundant data? (Something similar can be done in WinZip or WinRar).

Greetings!

 

If both the main header and the embedded backup header of your TrueCrypt container file happen to become damaged then all of your data will be completely inaccessible, so for maximal safety the most important thing you can do is to manually back up the headers (only 128KB) and store them in a separate location. It also wouldn't hurt to make several copies of the backup headers.

As for the rest, are you referring to simple CRC (cyclic redundancy checks) or data redundancy such as parity archive files?

As far as creating parity archive files goes, I don't think this would be the most effective way to protect the contents of a TrueCrypt volume, as it contains an entire filesystem, not merely a collection of files and their associated folder names. The archive files would probably be able to rebuild damaged files and folder names, but I doubt if they would be able to rebuild a damaged filesystem.

However, if you really want to go this route then I suggest you use the data-redundancy software directly on your stored files and folders rather than on the unmounted TrueCrypt container file (which is just a large block of random data and doesn't offer any opportunities for making small, efficient redundancy backups). Perhaps your data could first be zipped using winrar's recovery folders and files, and then you could copy the zipped files into a TrueCrypt container. You might want to place an extra copy of the recovery files into a separate container for added redundancy. However, none of this would protect your filesystem, which would also be at risk due to a dataloss event.

Most people just back up their encrypted data in its entirety, and I strongly recommend this approach. Encryption can definitely put an extra roadblock in the way of data recovery, so making good backups becomes extra important. However, if your headers are good (or can be restored from a backup) then you will always be able to decrypt your data, even if some of it becomes damaged due to various circumstances. Losing a few chunks out of a TrueCrypt container does not mean total data loss. The worst that can happen is that you will lose the specific blocks that were damaged or corrupted. This can affect individual files, or (if you're unlucky) it can knock out your volume's entire filesystem, in which case you will have to use data-recovery software to try to recover your files. If the files are unfragmented then you stand the best chance at recovery. (If you have a complete backup copy of your data sitting in another container file then you have no problem at all, of course.)

The most common backup technique is to create and mount another container file and then copy all of your data into it. An even quicker approach would be to merely copy the entire unmounted container file and use that as your backup. This second method will cause a slight theoretical reduction in security, but based on your security requirements this might not matter.

 

Dantz, how does the backup of a file used to hold an encrypted container reduce the security of the content within the container?

Thank you.

 

A comparison of the two container files would show some differences, of course, and one would would normally assume that the changes have occurred in the original volume which is still in use, whereas the backup has probably not changed. Thus, if the user was making use of a hidden volume then this might be revealed or at least strongly implied by examining the locations of the changes.

You would immediately be able to spot any changes to the hidden volume's header, of course, if the user chose to back up restore his hidden header or change his hidden password.

Worse, if the user were forced to decrypt his main volume then one could look at the exact locations of his data, and if these locations were not fully reflected in the locations of the observed changes between the two containers then the presence of a hidden volume would become rather obvious.

A separate security issue that I am aware of is that two cloned containers with some changed data would theoretically be more susceptible to certain types of crytanalysis, especially if the nature of the changed data was known. I don't think this is a serious threat, but we must think in terms of probabilities, and it does allow some attacks that wouldn't otherwise be possible. Personally, I think that all they would really be able to say is "Look - his data has changed! Aha, I knew that this was encrypted data and not just the product of a pseudo-random wipe."

edit: fixed a mistake