Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
HOWTO: Install truecrypt and encrypt your Firefox/TB files
View unanswered posts
View posts from last 24 hours

Reply to topic    Gentoo Forums Forum Index Documentation, Tips & Tricks
View previous topic :: View next topic  
Author Message
Guenther Brunthaler

Joined: 22 Jul 2006
Posts: 217
Location: Vienna

PostPosted: Thu Sep 07, 2006 7:20 pm    Post subject: HOWTO: Install truecrypt and encrypt your Firefox/TB files Reply with quote

This guide will show you how to

  • Fetch and install the truecrypt package on your box
  • Create a virtual disk inside an encrypted file as a container using truecrypt.
  • Create a "$HOME/p" directory that can be used as a safe place for private or classified data.
  • Move your Thunderbird/Firebird settings/emails into that directory, thus securing them by encryption.

So, here's the guide:

  • Truecrypt needs the "device mapper" to work. If you haven't enabled it in your kernel, please do so now before continuing. The device mapper can be configured as a kernel module as well as directly built into the kernel in order for truecrypt to work. If you are using Genkernel, this should not be an issue as device mapper will be available.
  • Get the newest version of the truecrypt source package from the truecrypt homepage ( As the time of writing this guide, this was version 4.2a.
  • Extract the package contents:
    tar -xvzf <packagename>.tar.gz

    where <packagename>.tar.gz is the name of the archive you downloaded.
  • Use 'cd' to go into the directory created by the extraction, and from there into the Linux subdirectory.
  • Run
    to compile truecrypt.
  • Run
    to install it. The installation script will prompt you for the directories where truecrypt should be installed. I suggest installing it into /usr/local/sbin, as it's not an official part of the Gentoo distribution (yet).
  • That's it for the truecrypt installation. Easy, wasn't it?
  • Now we'll create a truecrypt volume container. This is an encrypted file which will contain the data to be protected by encryption. But first let's create directories for the volume as well for the mount points. You can choose anything you like; I chose the following:
    mkdir -p /var/local/lib/truecrypt/{volumes,mnt}

  • Now let's create the encrypted container file. Any name will do; I chose "":

    cd /var/local/lib/truecrypt/volumes
    truecrypt -c

    Truecrypt will ask you now several questions, such as how large the volume is going to be, what of the available ciphers to use, what password, etc.

    Just answer all of them according to your requirements. It may be a good idea to read the truecrypt manual before answering the questions.

    However, here is what I chose to create a container to be formatted with ReiserFS later:
    • Volume type = normal
    • Filesystem = none (we'll format it later)
    • Hash-algorithm = RIPEMD-160 (it's safer than SHA-1 which is near to be broken)
    • Encryption Algorithm = AES-Twofish-Serpent (Yes, I'm a bit paranoid. I don't trust AES too much. But it may be good enough for warming up the bits for TWOFISH, which I trust much more. But then, I could be wrong, so lets SERPENT encrypt the thing again like a post-processor just to be sure. Triple-Encryption is fun!)

  • Truecrypt will then create the container. Depending on the size you have requested, this may take some time.
  • After truecrypt finishes creating the volume container file, we have to mount it into truecrypt for creating a filesystem inside it:
    truecrypt -N64

    The 64 here is used to force truecrypt to create the device node for the virtual disk as /dev/mapper/truecrypt64. It's an arbitrary choice, and truecrypt would have choosen an unused number by itself if -N64 was not used. But I'm specifying it here explicitly, so that I don't have to figure out which number truecrypt has actually chosen for the next step.
  • Truecrypt will prompt you for the password which you have chosen when creating the container file. Enter it.
  • Now, /dev/mapper/truecrypt64 will be available, presenting us the decrypted data inside the encrypted container file. Which means we can use it like any disk. Let's create a filesystem first:
    mkreiserfs -l "Personal Data" /dev/mapper/truecrypt64

    Of course, you are free to choose any other filesystem or volume label you might prefer instead of this.
  • Let's create a mountpoint directory and mount the freshly created filesystem on it:
    cd ../mnt
    mkdir -m0 private
    chown nobody:nogroup private
    mount /dev/mapper/truecrypt64 private

    (I always assign mountpoint directories to user nobody without any permissions. This way you can see quickly whether something is mounted at the mount point or not when using ls -l, even without looking into the mountpoint directory's contents.)
  • The encrypted volume is now mounted ready to use!
  • Let's create a /home-hierarchy inside the encrypted filesystem now, mirroring the hierarchy of /home in the root filesystem. We'll also create a directory for user "joe" (replace this by your username accordingly):
    cd private
    mkdir -p home/joe
    chown joe home/joe
    chmod 700 home/joe

  • Now let's go to joe's home directory and create a symlink named "p" (for "private") pointing to the "joe" directory on the encrypted filesystem:
    cd /home/joe
    ln -s /var/local/lib/truecrypt/mnt/private/home/joe p

  • Now user joe has a symlink "p" in his home directory, which will work like an encrypted subdirectory. All data within this subdirectory will be transparently encrypted as part of the container file.
  • But user joe will have to know nothing about truecrypt or anything about encryption. For joe, "p" is just another directory, only that he know it's "safe" and accessing it will be a tiny bit slower (because it has to be encrypted/decrypted on the fly in the background as he accesses it).
  • Feel free to create similar subdirectories and symlinks for other users also, just like for joe.
  • Now let's move joe's thunderbird and firefox files (mails, bookmarks, saved password, settings) into that safe directory "p". But be sure that there's enough space in "p" before continuing! Use
    df -h

    in order to see the free space available on the various volumes, including the filesystem mounted in the truecrypt container.
    Then check the size of the combined firefox/thunderbird subdirectories:
    du -hsc .thunderbird/ .mozilla/

    Continue only if the combined size of those directories is less by at least a couple of megabytes than the available space in the encrypted volume!
  • Move the FF and TB files into the p subdirectory. Be sure none of both applications is currently running while you are doing this!
    mv .thunderbird .mozilla p/

  • Finally, let's create symlinks at the old location, so that FF and TB find their files where they expect them to be:

    ln -s p/.thunderbird
    ln -s p/.mozilla

  • You can do the same trick for any other subdirectories you want to be secure as well. Just follow the same pattern: Move them into the p subdirectory, and create a symlink in the old location, pointing to the new location.
  • Hint: Use relative symlinks if you can (relative to "p"). That way, if you ever chose to move the mount point for the truecrypt volume somewhere else, all you have to update will be the "p" symlink. The other symlinks will not need to be changed, because they are relative to "p" no matter where "p" actually points to.
  • Congratulations, you are done! When you will be starting FF or TB, they will using the encrypted volume for all of their data.

There is one problem, though: The encrypted volumes must be unmounted before shutting down the system, or otherwise the contents may be damaged like it is the case for any filesystem that is not unmounted before the system goes down.

For normal volumes, the Gentoo shutdown scripts will take care of this. But as those scripts do not know anything about truecrypt, we can't count on that.

One way is to do it manually:

truecrypt -d 64

This will unmount the filesystem mounted at /var/local/lib/truecrypt/mnt/private/ as well as removing the /dev/mapper/truecrypt64 device node.

Of course, when using encrypted volumes on a daily basis, it will be preferable to write an /etc/init.d script for that. I wrote the following /etc/init.d/truecrypt script for that purpose:



depend() {
   after localmount

start() {
   ebegin "Initializing truecrypt"
   eend ${?}

stop() {
   ebegin "Cleaning up truecrypt"
   if $LSMOD | $CUT -d' ' -f1 | $GREP truecrypt > /dev/null; then
      $TRUECRYPT -d
   eend $?

This script assumes that the device mapper has been compiled as a kernel module. If it's directly linked into the kernel instead, you can remove the LSMOD stuff and just write $TRUECRYPT -d unconditionally (i. e. remove the if/then stuff).

Also be sure to customize the TRUECRYPT= line to refer to where you have the truecrypt executable installed. Then start it, stop it, and restart it to see if it works:


/etc/init.d/truecrypt start
/etc/init.d/truecrypt stop
/etc/init.d/truecrypt start

Note: This will unmount our volume and detach it from the device mapper! See below for a script for easily mounting it again.

By the way, it does not hurt if the script is trying to unmount the truecrypt volumes and no such volumes are currently mounted: In this case, simply nothing happens.

So it's always safe to let this script unmount the volumes at shutdown, even if no truecrypt volumes will actually be mounted then.

In order to have a shutdown or reboot automatically trigger the script's "stop" action, we need to add it to the boot runlevel:
rc-update add truecrypt boot

Finally let's write a helper script tcmount which mounts the encrypted volume when invoked by the administrator:

Script "/usr/local/sbin/tcmount":

truecrypt -N64 /var/local/lib/truecrypt/volumes/ /var/local/lib/truecrypt/mnt/private/

And here's a script for unmounting it immediately (in case you won't want to wait for the /etc/init.d/truecrypt script to do it at system shutdown time):

Script "/usr/local/sbin/tcumount":

truecrypt -d 64

And now a few words why choosing truecrypt among the plethora of available disk encryption solution is actually a good idea in my opinion:

  • It's small and easy to install.
  • Uses state-of-the-art ciphers and chaining modes. It supports not only AES, but also TWOFISH, SERPENT and others. But especially important, it supports the new LRW mode of operation which has especially been designed with the requirements of disk encryption in mind. It's much better suited for this purpose than the usual ECB, CBC or COUNTER modes used by many of the other packages.
  • Supports denyable encryption. This allows to put a fake "FAT"-volume at the beginning of the encrypted volume, containing some innocent files for the event that some 4-letter-organizations raid your home and force you to hand them over your encryption password, suspecting your obviously encrypted volume containing files they consider "illegal". Knowing that the files in your hidden partition are not illegal but only private, there is obviously no requirement for those guys to see your non-illegal private data, because they are only searching for illegal files. So you only give them the password for the fake part of the volume, and they won't find anything you will not want them to find. But in the hidden part of the volume, your private file collection is safely encrypted on its independent ReiserFS partition (or whatever FS you chose), but they cannot prove this (even if they are suspecting). See the truecrypt manual for more about this.
  • Truecrypt is available under Windows as well as under Linux. If you create a truecrypt container which contains a FAT volume on a USB stick, you can mount the contents of that container using either the Windows of the Linux version of truecrypt.
  • Truecrypt can also use raw disk partitions as containers; it is not necessary to use container files for that purpose. This works for Linux as well as for Windows.
  • The truedisk data structures are exactly documented. So, even in the extremely unlikely case that something unexpected or catastrophic happens and some of part of the truecrypt container file gets corrupted by accident, you have at least detailed documentation available and can try to fix it manually using a hex editor. It's certainly better than having nothing.
  • And no, this documentation will not help anyone who doesn't know your passphrases! (There can be two: One for the normal part of the volume, and one for the hidden part of the volume.)
  • Truecrypt containers can be shrunk or expanded easily. That may be escpecially interesting when using an LVM2 logical volume as a truecrypt container. I will demonstrate how to do this in a later guide.
Back to top
View user's profile Send private message

Joined: 11 Jun 2002
Posts: 47
Location: Vienna, Austria

PostPosted: Wed Apr 04, 2007 3:41 pm    Post subject: Reply with quote

Hi Guenther!

Great Howto. I used TrueCrypt on Windows and this information about using it on Gentoo was exactly what I was looking for.
I would very much like to see a sequel about shrinking and expanding when using LVM. As you mentioned at the end of your posting.

Unix _IS_ userfriendly. It's just selective about who it's friends are.
Back to top
View user's profile Send private message
Guenther Brunthaler

Joined: 22 Jul 2006
Posts: 217
Location: Vienna

PostPosted: Thu Apr 05, 2007 5:55 pm    Post subject: Reply with quote

Paidhi wrote:
I would very much like to see a sequel about shrinking and expanding when using LVM. As you mentioned at the end of your posting.

That's quite easy, depending on the file system used. ReiserFS and the EXT filesystems support shrinking and growing, most others only allow an existing filesystem to grow. (Of course it is always possible to format a new volume and copy the data over from the old one, but that requires the two volumes to exist side by side until the copying is finished.)

From my own experience, I can only tell you what I did when resizing ReiserFS partitions.

  • Case 1: Enlarging an existing TrueCrypt enrypted LVM2 ReiserFS Volume:

    • Unmount the volume using TrueCrypt if it is still mounted. Use
      # truecrypt -d <volume_index>
      for that. In order to get an overview over currently mounted volumes, do a[quote]# truecrypt -l[/code]The number in the name after /dev/mapper/truecrypt is the volume index number.
    • Backup the current volume headers of the TrueCrypt volume:
      truecrypt --backup-headers <savefile.hdr> /dev/vg0/<truecrypt-container>
      The saved file contains a copy of the TrueCrypt hidden volume header at the end of the current volume which will be overwritten by extending the volume.
    • Now use lvresize or lvextend in order to extend the TrueCrypt container LVM2 volume to the new desired size. The size increment must be a multiple of the TrueCrypt volume's sector size (currently always 512 bytes, but future versions of TrueCrypt might support different sector sizes also). Before resizing the volume, write down the exact sizes of the LVM2 partition before and also after the resize operation.
    • Fill the new, previously unallocated contents of the enlarged container partition with random numbers. This is done to disclose from an attacker which of the data blocks actually contain data and which are just "unused". By filling them with random data, no-one can tell.

      This also means it is not important from which source those random numbers come as they do not have any significance to TrueCrypt itself - they only represent "uninitialized data".

      I recommend openssl rand for generating the random numbers, as it is much faster than using /dev/urandom as a random number source. Also note that the quality of the random numbers is not of utmost importance, as they are only used as fillers and do not carry any useful information themselves. They must not be easily predictable for an attacker though, thus using a moderately cryptographically secure and appropriately seeded random number generator is mandatory.

      The actual filling operation will then be done by dd, which gets the filler bytes piped from openssl.
    • After the newly added section of the augmented TrueCrypt container volume has been filled with random numbers that way, truecrypt --restore-header must be used to restore the hidden volume header block, which will be written to the end of the new volume container.
    • Now the TrueCrypt volume should be mounted, but only as a block device in /dev/mapper/, and not yet as a filesystem.
    • Now
      resize_reiserfs /dev/mapper/truecrypt<indexnumber>
      must be run in order to also grow the filesystem to its new extended bounds.
    • Finally, the enlarged filesystem can be mounted from /dev/mapper/truecrypt<indexnumber>.

  • Case 2: Shrinking an existing TrueCrypt enrypted LVM2 ReiserFS Volume:
    • Decide exactly how many bytes to shrink the volume. Must be a multiple of the TrueCrypt volume's sector size (always 512 bytes for now).
    • Mount the TrueCrypt volume, but umount the actual filesystem, leaving /dev/mapper/truecrypt<indexnumber> as the block-device which will encrypt/decrypt the encrypted contents of the LVM2 container volume on the fly.
    • Use resize_reiserfs on /dev/mapper/truecrypt<indexnumber> in order to reduce it by the number of bytes you have decided.
    • Unmount /dev/mapper/truecrypt<indexnumber> by running
      truecrypt -d <indexnumber>
        Make a backup of the TrueCrypt volume's current hidden volume header using truecrypt --backup-headers.
      • Use lvresize or lvreduce in order to shrink the LVM2 container volume by the number of bytes you have decided in the first step.
      • Run truecrypt --restore-header in order to restore the hidden volume header to the end of the shrunk volume.

Hmmm... ok. In review, perhaps it's actually not that easy. ;-)

But I hope you got the general idea:

  • When extending, the newly allocates space should be filled with random bytes.
  • The last couple of sectors of any TrueCrypt container contain the "hidden volume header". In order to keep it where it belongs (at the end of the volume), the --backup-headers and --restore-header options of truecrypt can be used.
  • The --backup-headers and --restore-header options do not change the contents of either TrueCrypt volume headers, they just copy them around.
  • Neither the normal nor the hidden volume headers of a TrueCrypt volume contains any information about the size of the TrueCrypt volume. The size is always inferred from the size of the TrueCrypt container volume. Which means we do not need to change anything within the volume headers themselves when resizing TrueCrypt volumes. It must only be taken care not to overwrite them when growing or not to cut them off when shrinking.

I will post an example of the above procedures when I have more time left.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Documentation, Tips & Tricks All times are GMT
Page 1 of 1

Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum