Archive

Posts Tagged ‘truecrypt’

How to migrate from TrueCrypt to LUKS file containers

June 15th, 2014 No comments

With the recent questions surrounding the security of TrueCrypt there has been a big push to move away from that program and switch to alternatives. One such alternative, on Linux anyway, is the Linux Unified Key Setup (or LUKS) which allows you to encrypt disk volumes. This guide will show you how to create encrypted file volumes, just like you could using TrueCrypt.

The Differences

There are a number of major differences between TrueCrypt and LUKS that you may want to be aware of:

  • TrueCrypt supported the concept of hidden volumes, LUKS does not.
  • TrueCrypt allowed you to encrypt a volume in-place, without losing data, LUKS does not.
  • TrueCrypt supports cipher cascades where the data is encrypted using multiple different algorithms just in case one of them is broken at some point in the future. As I understand it this is being talked about for the LUKS 2.0 spec but is currently not a feature.

If you are familiar with the terminology in TrueCrypt you can think of LUKS as offering both full disk encryption and standard file containers.

How to create an encrypted LUKS file container

The following steps borrow heavily from a previous post so you should go read that if you want more details on some of the commands below. Also note that while LUKS offers a lot of options in terms of cipher/digest/key size/etc, this guide will try to keep it simple and just use the defaults.

Step 1: Create a file to house your encrypted volume

The easiest way is to run the following commands which will create the file and then fill it with random noise:

# fallocate -l <size> <file to create>
# dd if=/dev/urandom of=<file to create> bs=1M count=<size>

For example let’s say you wanted a 500MiB file container called MySecrets.img, just run this command:

# fallocate -l 500M MySecrets.img
# dd if=/dev/urandom of=MySecrets.img bs=1M count=500

Here is a handy script that you can use to slightly automate this process:

#!/bin/bash
NUM_ARGS=$#

if [ $NUM_ARGS -ne 2 ] ; then
    echo Wrong number of arguments.
    echo Usage: [size in MiB] [file to create]

else

    SIZE=$1
    FILE=$2

    echo Creating $FILE with a size of ${SIZE}MB

    # create file
    fallocate -l ${SIZE}M $FILE

    #randomize file contents
    dd if=/dev/urandom of=$FILE bs=1M count=$SIZE

fi

Just save the above script to a file, say “create-randomized-file-volume.sh”, mark it as executable and run it like this:

# ./create-randomized-file-volume.sh 500 MySecrets.img

Step 2: Format the file using LUKS + ext4

There are ways to do this in the terminal but for the purpose of this guide I’ll be showing how to do it all within gnome-disk-utility. From the menu in Disks, select Disks -> Attach Disk Image and browse to your newly created file (i.e. MySecrets.img).

Don't forget to uncheck the box!

Don’t forget to uncheck the box!

Be sure to uncheck “Set up read-only loop device”. If you leave this checked you won’t be able to format or write anything to the volume. Select the file and click Attach.

This will attach the file, as if it were a real hard drive, to your computer:

attachedindisksNext we need to format the volume. Press the little button with two gears right below the attached volume and click Format. Make sure you do this for the correct ‘drive’ so that you don’t accidentally format your real hard drive!

Please use a better password

Please use a better password

From this popup you can select the filesystem type and even name the drive. In the image above the settings will format the drive to LUKS and then create an ext4 filesystem within the encrypted LUKS one. Click Format, confirm the action and you’re done. Disks will format the file and even auto-mount it for you. You can now copy files to your mounted virtual drive. When you’re done simply eject the drive like normal or (with the LUKS partition highlighted) press the lock button in Disks. To use that same volume again in the future just re-attach the disk image using the steps above, enter your password to unlock the encrypted partition and you’re all set.

But I don’t even trust TrueCrypt enough to unlock my already encrypted files!

If you’re just using TrueCrypt to open an existing file container so that you can copy your files out of there and into your newly created LUKS container I think you’ll be OK. That said there is a way for you to still use your existing TrueCrypt file containers without actually using the TrueCrypt application.

First install an application called tc-play. This program works with the TrueCrypt format but doesn’t share any of its code. To install it simply run:

# sudo apt-get install tcplay

Next we need to mount your existing TrueCrypt file container. For the sake of this example we’ll assume your file container is called TOPSECRET.tc.

We need to use a loop device but before doing that we need to first find a free one. Running the following command

# sudo losetup -f

should return the first free loop device. For example it may print out

/dev/loop0

Next you want to associate the loop device with your TrueCrypt file container. You can do this by running the following command (sub in your loop device if it differs from mine):

# sudo losetup /dev/loop0 TOPSECRET.tc

Now that our loop device is associated we need to actually unlock the TrueCrypt container:

# sudo tcplay -m TOPSECRET.tc -d /dev/loop0

Finally we need to mount the unlocked TrueCrypt container to a directory so we can actually use it. Let’s say you wanted to mount the TrueCrypt container to a folder in the current directory called SecretStuff:

# sudo mount -o nosuid,uid=1000,gid=100 /dev/mapper/TOPSECRET.tc SecretStuff/

Note that you should swap your own uid and gid in the above command if they aren’t 1000 and 100 respectively. You should now be able to view your TrueCrypt files in your SecretStuff directory. For completeness sake here is how you unmount and re-lock the same TrueCrypt file container when you are done:

# sudo umount SecretStuff/
# sudo dmsetup remove TOPSECRET.tc
# sudo losetup -d /dev/loop0

This post originally appeared on my personal website here.




I am currently running a variety of distributions, primarily Ubuntu 14.04.
Previously I was running KDE 4.3.3 on top of Fedora 11 (for the first experiment) and KDE 4.6.5 on top of Gentoo (for the second experiment).
Check out my profile for more information.

Create a virtual hard drive volume within a file in Linux

June 15th, 2014 No comments

If you are not familiar with the concept of virtual hard drive volumes, sometimes called file containers, they are basically regular looking files that can be used by your computer as if they were real hard drives. So for example you could have a file called MyDrive.img on your computer and with a few quick actions it would appear as though you had just plugged in an external USB stick or hard drive into your computer. It acts just like a normal, physical, drive but whenever you copy anything to that location the copied files are actually being written to the MyDrive.img file behind the scenes. This is not unlike the dmg files you would find on a Mac or even something akin to TrueCrypt file containers.

Why would I want this?

There are a number of reasons why you may be interested in creating virtual volumes. From adding additional swap space to your computer (i.e. something similar to a page file on Windows without needing to create a new hard drive partition) to creating portable virtual disk drives to back up files to, or even just doing it because this is Linux and it’s kind of a neat thing to do.

What are the steps to creating a file container?

The process seems a bit strange but it’s actually really straight forward.

  1. Create a new file to hold the virtual drive volume
      (Optional) Initialize it by filling it with data
  2. Format the volume
  3. Mount the volume and use it

Create a new file to hold the virtual drive volume

There are probably a million different ways to do this but I think the most simple way is to run the following command from a terminal:

fallocate -l <size> <file to create>

So let’s say you wanted to create a virtual volume in a file called MyDrive.img in the current directory with a size of 500MiB. You would simply run the following command:

fallocate -l 500M MyDrive.img

You may notice that this command finishes almost instantly. That’s because while the system created a 500MiB file it didn’t actually write 500MiB worth of data to the file.

This is where the optional step of ‘initializing’ the file comes into play. To be clear you do not need to do this step at all but it can be good practice if you want to clean out the contents of the allocated space. For instance if you wanted to prevent someone from easily noticing when you write data to that file you may pre-fill the space with random data to make it more difficult to see or you may simply want to zero out that part of the hard drive first.

Anyway if you choose to pre-fill the file with data the easiest method is to use the dd command. PLEASE BE CAREFUL – dd is often nicknamed disk destroyer because it will happily overwrite any data you tell it to, including the stuff you wanted to keep if you make a mistake typing the command!

To fill the file with all zeros simply run this command:

dd if=/dev/zero of=<your file> bs=1M count=<your file size in MiB>

So for the above file you would run:

dd if=/dev/zero of=MyDrive.img bs=1M count=500

If you want to fill it with random data instead just swap /dev/zero for /dev/urandom or /dev/random in the command:

dd if=/dev/urandom of=MyDrive.img bs=1M count=500

Format and mount the virtual volume

Next up we need to give the volume a filesystem. You can either do this via the command line or using a graphical tool. I’ll show you an example of both.

From the terminal you would run the appropriate mkfs command on the file. As an example this will format the file above using the ext3 filesystem:

mkfs -t ext3 MyDrive.img

You may get a warning that looks like this

MyDrive.img is not a block special device.
Proceed anyway? (y,n)

Simply type the letter ‘y’ and press Enter. With any luck you’ll see a bunch of text telling you exactly what happened and you now have a file that is formatted with ext3!

If you would rather do things the graphical way you could use a tool like Disks (gnome-disk-utility) to format the file.

From the menu in Disks, select Disks -> Attach Disk Image and browse to your newly created file (i.e. MyDrive.img).

Don't forget to uncheck the box!

Don’t forget to uncheck the box!

Be sure to uncheck “Set up read-only loop device”. If you leave this checked you won’t be able to format or write anything to the volume. Select the file and click Attach.

This will attach the file, as if it were a real hard drive, to your computer:

MyDriveAttached

Next we need to format the volume. Press the little button with two gears right below the attached volume and click Format. Make sure you do this for the correct ‘drive’ so that you don’t accidentally format your real hard drive!

Make sure you're formatting the correct drive!

Make sure you’re formatting the correct drive!

From this popup you can select the filesystem type and even name the drive. You may also use the “Erase” option to write zeros to the file if you wanted to do it here instead of via the terminal as shown previously. In the image above the settings will format the drive using the ext4 filesystem. Click Format, confirm the action and you’re done. Disks will format the file and even auto-mount it for you. You can now copy files to your mounted virtual drive. When you’re done simply eject the drive like normal or press the square Stop button in Disks. To use that same volume again in the future just re-attach the disk image using the steps above.

To mount the formatted file from the terminal you will need to first create a folder to mount it to. Let’s say we wanted to mount it to the folder /media/MyDrive. First create the folder there:

sudo mkdir /media/MyDrive

Next mount the file to the folder:

sudo mount -t auto -o loop MyDrive.img /media/MyDrive/

Now you can copy files to the drive just like before. When you’re finished unmount the volume by running this command:

sudo umount /media/MyDrive/

And there you have it. Now you know how to create virtual volume files that you can use for just about anything and easily move from computer to computer.

This post originally appeared on my personal website here.




I am currently running a variety of distributions, primarily Ubuntu 14.04.
Previously I was running KDE 4.3.3 on top of Fedora 11 (for the first experiment) and KDE 4.6.5 on top of Gentoo (for the second experiment).
Check out my profile for more information.

TrueCrypt, kernel compilation and where’d /boot go?

October 5th, 2009 1 comment

Since I’ve installed Gentoo, I haven’t had access to my other drives. One of them is an NTFS-formatted WD Raptor, and the other is a generic Seagate 300GB drive that contains my documents, pictures and Communist propaganda inside a TrueCrypt partition. Getting the Raptor to work was fairly simple (as far as Gentoo goes) – I added the entry to my /etc/fstab file and then manually mounted the partition:

/dev/sdb1               /mnt/raptor     ntfs-3g         noatime         0 0

The TrueCrypt drive proved to be more of an issue. After installing the software and attempting to mount the partition, I encountered an error:

device-mapper: reload ioctl failed: Invalid argument 
Command failed

A quick Bing and the Gentoo Wiki described this problem exactly, with the caveat that I had to recompile my kernel to add support for LRW and XTS support. Into the kernel configuration I went – the only difference I noticed is that LRW and XTS are considered “EXPERIMENTAL” but aren’t noted as such on the requirements page:

Kernel configuration options

(This may come down to an x64 vs. x86 issue, but I haven’t run into any issues with these options enabled (yet!))

Of course, then came the make && make modules_install commands, which didn’t take too long to complete. The question then became, how do I install the new kernel? Looking in my /boot partition, I only had a few template files – and not the kernel itself or any grub settings. Essentially, /boot had nothing in it but the system still launches properly!

I then tried mounting /dev/sda1 manually, and the kernel and grub.conf showed up properly in the mountpoint. Something is obviously wrong with the way my system remounts /boot during the startup process, but at least now I’m able to install the new kernel. After copying /arch/x86_64/boot/bzImage to the newly available directory, I rebooted and the new kernel was picked up properly. TrueCrypt now lets me open, create and delete files from /media/truecrypt1, and automatically uses ntfs-3g support to accomplish this.

Overall, I’m pretty pleased at how easily I can recompile a kernel, and installation was seamless once I figured out that /boot wasn’t pointing to the right location. I expect I’ll try and manually remove the directory from /dev/sda3 and see if that makes a difference.




I am currently running various *BSD variants for this Experiment.
I currently run a mix of Windows, OS X and Linux systems for both work and personal use.
For Linux, I prefer Ubuntu LTS releases without Unity and still keep Windows 7 around for gaming.
Check out my profile for more information.