Part 2: TrueCrypt on Fedora 20

In Part 1 of this article, I went over my decision to encrypt my local backups. In this part of the article, I will be going over some of the decisions I’ve made for my setup.

This is going to be a long post, but I think it’s an important one. The design of this setup should be thought out carefully now, because making any changes in the future will be difficult. I believe Ben Franklin said it best,  “If you fail to plan, you are planning to fail”.


Hard drive selection

I’m a Western Digital kind of guy. I tried a Seagate once and it didn’t work out, so I never went back.

Currently, I’m using a 1TB WD Elements USB 3.0 drive. No complaints so far.

My backup strategy up to this point has been using rsync to copy some data (Desktop, Dropbox, Music, etc…) into a folder with the current date. I do this about once a month. As such, these are not differential backups and take up about 70GB each. Most of it is data that doesn’t change and doesn’t need to be duplicated on each backup (pictures, old college documents, music, etc…). Not the greatest plan, I know.

Instead of encrypting my existing HDD in place, I decided to purchase a new drive. I plan on encrypting both drives, and keeping the same data on them. I’ll use the new drive as my primary backup drive, and store the 1TB drive off-site.

Again, WD FTW 🙂 This time, I went with a 2TB My Passport Ultra USB 3.0 drive.

Some benchmarks on the drive if you’re interested. This is with 10MB files:

20140322_001 20140322_002

And this is with 100MB files:

20140322_003 20140322_004


Hard drive prep

I wanted to make sure there were no bad blocks on the drive, so I ran badblocks in Fedora. It works by overwriting every block with a pattern (0xaa,  0x55,  0xff, or 0x00), reading every block, then comparing the results. I had only recently heard of this, so this was my first time using it. I wasn’t at my laptop to see when it finished, but it took between 36-40 hours over a USB 3.0 connection.

logan@fedora20 ~$ sudo badblocks -svw -o /home/logan/Desktop/bb.txt /dev/sdb
[sudo] password for logan: 
Checking for bad blocks in read-write mode
From block 0 to 1953481727
Testing with pattern 0xaa: done                                                 
Reading and comparing: done                                                 
Testing with pattern 0x55: done                                                 
Reading and comparing: done                                                 
Testing with pattern 0xff: done                                                 
Reading and comparing: done                                                 
Testing with pattern 0x00: done                                                 
Reading and comparing: done                                                 
Pass completed, 0 bad blocks found. (0/0/0 errors)
logan@fedora20 ~$

Just so you’re aware, this was a destructive write test of the drive. It erased everything on the drive!
-w = do a destructive write test
-s = show progress-bar
-v = be verbose and output bad sectors detected to stderr

The Arch Linux Wiki has a great article on badblocks. It can also be used to tell the filesystem which blocks are bad so they can be ignored upon filesystem creation. I had no bad blocks, so I used GParted to create my filesystem.

The partition table is MSDOS (Master Boot Record). I chose this over GPT (GUID Partition Table) for two reasons:

  1. I’ve always used MBR and I know it works. I’m not going throw another variable into this equation.
  2. I don’t think TrueCrypt fully suports GPT yet.


TrueCrypt design

This is the part I spent the most time thinking about. There are multiple ways to setup TrueCrypt, and I have yet to see a side-by-side explanation of each, so I’m going to try my best here. Please let me know if any of this is incorrect 🙂

Container vs Partition

The first decision to make is what type of TrueCrypt volume to use: a container or a partition/device.

Container Partition/Device
  • Acts like a file (can be moved/copied/deleted, etc…)
  • Can be shared (via Dropbox, NAS, etc…)
  • If one container is corrupted, all other containers are unaffected (i.e., don’t put all your eggs in one basket)
  • Better performance
  • Less prone to corruption (depends on filesystem used)
  • Harder to accidentally delete/remove
  • Fixed size, can’t change once created
  • Susceptible to weaknesses in filesystem (e.g., fragmentation in NTFS)
  • Unconfirmed reports of very large containers being more susceptible to corruption
  • Slower
  • Risk of OS (Windows) trying to format/initialize disk
  • Risk of changing partition settings and losing all data (i.e., all your eggs are in one basket)


In the example below (ignore my terrible drawings), a setup for an encrypted container would look like the following:

  • /dev/sdb is the hard drive
  • /dev/sdb1 is the only partition on the drive and can be formatted with any filesystem (ext3, ext4, NTFS, etc…)
  • The TrueCrypt container can be any size, and sits on /dev/sdb1 just like a large file
  • Other files can exist alongside the TrueCrypt container


Below is the same example, but with a larger TrueCrypt container:

For this project, I’m not going to be using an encrypted container because of the following reasons:

  • I don’t plan on sharing the container or making copies of it
  • I don’t want to worry about a fixed container size
  • A container has worse performance than a partition
  • These hard drives are only for TrueCrypt, so I’m not worried about storing other files on them


Now we know that an encrypted container is out. The next decision to make is whether to use an encrypted partition or encrypted device.

Below is an encrypted partition:


  • /dev/sdb is the hard drive
  • /dev/sdb1 is the only partition on the drive and can be formatted with any filesystem (ext3, ext4, NTFS, etc…)
  • the TrueCrypt container is the exact size of the partition
  • no other files can exist alongside the TrueCrypt container


This is an encrypted device:


  • /dev/sdb is the hard drive
  • the TrueCrypt container is the exact size of the hard drive
  • no other files can exist on the drive


I chose encrypting the entire device, instead of a partition, to reduce the risk of data loss due to changes in partition settings/alignment. I think it is best explained here, copied out below:

“For partition encryption, TrueCrypt expects to find the first 512-bytes of the volume header in the first sector of the partition. If, however, the user alters or overwrites their partition table, whether by accident or on purpose, then the partition’s starting offset is changed (although the data often stays put) and as a result TrueCrypt cannot find its header. Many users end up breaking their encrypted partitions in this manner. The simplest solution is to re-create the original partition structure exactly as it was, but most users don’t store backup copies of their partition tables, so it’s not always that easy.

The same methodology applies to the embedded backup header. For partition encryption, TrueCrypt goes to the ending offset of the partition and looks backwards a specified distance in order to “find” the embedded backup header. Of course, this attempt will fail if the partition’s ending offset is changed, as sometimes happens.

Thus, partition encryption relies on the partition table and the partition boundaries remaining intact and unchanged. For whatever reasons, many users can’t seem to stop themselves from screwing these things up, resulting in the loss of vast amounts of encrypted data. Partition encryption is especially dangerous for that reason.

“Entire device” encryption is much simpler. The volume header is located at the very beginning of the physical drive, and that’s where TrueCrypt looks for it. This is a physical location that can’t be altered or screwed up by the user, so TrueCrypt will always look in the correct location. The embedded backup header is similarly located, as it is located a specified distance back from the actual end of the physical drive. Thus, the headers can’t get “lost”. They can be overwritten, and this sometimes happens, but as long as you keep header backups you can just restore them to the drive and regain access to the volume.”

To me, it seems much simpler to not have any partitions on the device. The entire drive is encrypted, start to finish.


When I created the partition table, I had also created the partition /dev/sdb1, which is now no longer necessary.



In fact, I discovered that if you have a partition on the drive, you’ll get an error if you try to encrypt the entire drive. You’re forced to either select a partition to use, or remove all partitions. I chose the latter. However, I’m not sure if deleting the partition deletes the MBR as well. That’s something to look into…




In Part 3 of this article, I’ll be encrypting the drive.


Leave a Comment