This last week I’ve been very interested in encryption. If you missed it you might be interested in my post on encrypting files or emails with GPG. In this tutorial I wanted to outline how to encrypt a local partition or a removable device (like a USB key). The steps used here will work for either type of device although you’ll need to replace your partition name and number for the examples provided here.

Attention: following this tutorial will wipe all data from the partition or device you write it to. You cannot encrypt your file system after-the-fact using this method. Be sure you have backups or don’t care about the data being lost if you follow these steps!!!

Step 1:

The first step in the tutorial is installing the cryptsetup utility, which is part of the cryptsetup package. You can search for this using your favorite package management utility or use this command:

sudo aptitude install cryptsetup

Step 2:

Now that we have the cryptsetup utility installed we’ll need to prepare the device for use. If you have a newly created device or partition you may be able to skip this step, but it also won’t hurt to redo this step anyway.

If you are unsure what the device is listed as, you can use either of these two commands:

sudo fdisk -l

(this will list your current partition table, both on local and removable media.)

dmesg

(this will show kernel messages pertaining to hardware. If you plug in a removable device and wait a few seconds, this will show what you what device the kernel assigned the hardware.)

Once you know what device you want to apply this to you can run the following command on [your device] to create the partition you want to encrypt. I suppose you can also use a graphical utility like gparted, etc. Those tools are outside the scope of this tutorial.

sudo fdisk /dev/[your device]

(ie; if your device showed up as /dev/sdb you would use: sudo fdisk /dev/sdb)

For removable media make a single primary partition using the entire space of the device (or alter for your needs if you know what you’re doing).

Once you have created the partition you’ll want to “w”rite the change in fdisk. Remember, if you don’t “w”rite the changes none will be applied.

Step 3:

To make sure that your kernel is up to date concerning the newly created / altered partition table you may need to run the command:

sudo partprobe

Step 4:

Now we’ll get to encrypting this new partition. There are different options you can use here, and I’ll outline a few of them, but there really isn’t one that is “the best”. It depends on your level of security needs and the time you want to spend on it. If you want it done quickly and want a basic level of fairly-hard-to-break encryption you can use the first option. If you are super paranoid and don’t mind letting this take some time (hours or days on large disks!) to build you can use option three. Somewhere in the middle, option two is probably fine. Anyone have suggestions on other methods?

We’ll write data over the newly created partition to help aid in the encryption process. By writing data to the partition prior to encryption it helps protect against data attacks, finding patterns on the block-level, etc. You can use one of the following three commands:

(this option will write 5 data patterns across your drive and overwrite and verify the data. This is used to check for badblocks, but can also be used to wipe out any existing data)

sudo dd if=/dev/urandom of=/dev/[your device] bs=4K

(this method is considered pretty secure. It is based on the truly random option below but is pseudo-random data--probably a very good option in most cases.)

sudo dd if=/dev/random of=/dev/[your device] bs=4K

(this is considered the most secure but will take a long time. It is also important to generate a lot of random data on your machine. Launch some applications, do some high disc I/O, move the mouse erratically, etc. This may take DAYS!)

Step 5:

At this point the partition is ready to be encrypted. Now there are multiple encryption methods and options to be used within each. This tutorial outlines using the LUKS encryption with my prefered string length, hash and cipher. You may change these if you know what you’re doing. If not, omitting my options will use the defaults (ripemd160 hash). This command will remind you that all data will be lost (although we already lost everything in Step 4. This is also where you’ll be prompted for your passphrase to access the encryption.

sudo cryptsetup luksFormat /dev/[your device] -c aes -s 256 -h sha256

(again, past [your device] are my preferred options)

If you see an error near this point similar to “Failed to setup dm-crypt key mapping. Check kernel for support for the aes-cbc-plain cipher spec and verify that /dev/[your device] contains at least 258 sectors.” you’ll need to run this command:

sudo modprobe dm-crypt

You may want to have this module auto-magically added at boot time by appending this line to your /etc/modules file:

dm-crypt

Step 6:

Now that we’ve created the encryption basic layout on the partition we need to open the encrypted partition for use.

sudo cryptsetup luksOpen /dev/[your device] name

(name can be whatever you like. I use things like secure or vault or encrypt)

Step 7:

Now that we have the device open and added to the dm (dev mapper) system we can actually create a file system on it and use it. One last command and we’ve got ourselves an encrypted, usable filesystem.

sudo mke2fs -j /dev/mapper/name -L label

(where name was applied above and label is the filesystem label. I generally match the two. This also assumes an ext3 file system. If you know you want a different filesystem type I'm assuming you know the right command.)

If you’ve come this far your device is ready to use. A few additional points that you may be interested in.

Additional

First, if this is a local partition and filesystem, such as a /data folder, you may want it to be mounted automagically at boot time. You can add the new partition to your /etc/fstab file to be mounted at boot. Be sure to specify the /dev/mapper/[name] location and not the original partition location. You should note that when your booting system arrives at this device it will prompt you for a passphrase key and halt the boot process until one is provided. An example of a line in the /etc/fstab is:

/dev/mapper/name /data ext3 defaults 0 0

Second, if you are using this on a removable drive such as a usb key the Gnome Desktop (someone verify in KDE?) will recognize the encrypted setup and prompt you for a key visually. A message such as “The storage device contains encrypted data. Enter a password to unlock” will appear. You will be required to know the passphrase (as supplied in Step 5) to access this device again. The desktop system also allows you to “forget immediately“, “remember password until you logout” or “remember forever” the key provided. Those options are up to you and your usage. “Remember forever” should store the key in your gnome keyring.

Third, if you are following this guide for use on a removable disk you may want to change ownership (chown) on the mounted path and set group id (sgid) on the directory so that your user has full permissions. Considering we ran everything with sudo the mounted path and ownership is probably set to the root user. You can use these two commands to set the permissions:

sudo chown -R user.user /media/[name]

(user.user should, of course, be replaced with your username on the system)

sudo chmod g+s /media/[name]

([name] is the mount point that the system auto-mounted the device on. It *should* match whatever you set the label to in step 7.)

There is also an option to create multiple keys to unlock the device. This is helpful if it is a multi-user system and you don’t want to use a shared passphrase. You would add a key to the encrypted device using:

sudo cryptsetup luksAddKey /dev/[your device]

This will prompt you for your current key and then the new key. The new key will have to be entered twice. Also, if you want to remove a key you can use the similar:

sudo cryptsetup luksDelKey /dev/[your device] [slot #]

To find out more information about your encrypted partition / device, and to see things such as assigned key slots, you can also use:

sudo cryptsetup status name

sudo cryptsetup luksDump /dev/[your device]

I would like to expand this soon to include encrypting your entire root filesystem or other variations like bypassing the passphrase but storing the “key” an a usb drive or similar. This way it is similar to a hardware key needed to boot your machine. There are a lot of different ways this could go… until then, I think this has become long enough

Henriette – I have a tutorial in the works now for encrypting more of your working system vs single partitions as laid out in this write up. I suggest waiting for that one.

The current pending method involves encrypting at time of installation, but I may be able to outline transitioning /home to an encrypted partition post-installation. I’ll do some testing to find out for sure.

I’ve been using LUKS / cryptsetup for quite a while now, in all my data partitions and USB keys & disks. The integration with gnome is awesome. Something I’ve been looking for is how *easily* create LUKS-encrypted CDROMS and DVD-ROMs. If you know how to do this, it would be great if you can post a guide. There is a very old guide from the gentoo folks but it is not working in feisty (plus it is way too geeky :)) thanks!

So what happens when you reinstall and can no longer load the encrypted disk or you move to a different computer? I repeated part of step 5 and step 6 and was able to get it working again but it suggests that this setup is somewhat “fragile” in that you could easily be left with a drive which you cannot access. For portable drives, are there any solutions which would allow the drive to auto setup any computer it’s connect to?

Hi, Thanks for the tutorial. It worked! I think you’re missing just one step, which is adding an entry to /etc/crypttab This is what causes the prompting of the password during boot; without this the entry in /etc/fstab cannot do anything.

> the Gnome Desktop (someone verify in KDE?) > will recognize the encrypted setup and > prompt you for a key visually

Of course KDE also do this.

Jim and Rich: you can access your LUKS-encrypted disks from any computer with LUKS and dm-crypt. I have used all my encrypted removable devices in different computers with Ubuntu and OpenSuse (my work desktot, my laptop, my home desktops, friend’s laptops, etc.) and they work without problems.

mjukr: LUKS is so Linux-native it works flawlessly, TrueCrypt is a Windows-centric project which later became multiplatform, maybe that explain why is not so easy to use in Linux.

MrMan: the command shred can only delete data on a filesystem, not directly on the raw device (which is safer). Using dd is therefore far superior to clean a partition before encryption.

I followed this guide but i cannot automount with Gnome the disk. Permissions are ok and via console i can mount that, but as I fill in my passphrase in gnome it gives this error:

it’s not possible to mount encrypted data: DBus error org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

Hmm. Under 10.04, after adding the fstab line, I got a filesystem which root can mount or unmount (without password!), but the user owning the mount point can’t. Adding the “user” option to fstab allowed me (and presumably anyone) to mount it, but still didn’t ask for a password. Is this because I haven’t rebooted yet? (It’s worrisome….)

I haven’t tried Darren’s entry for /etc/crypttab yet — eventually I’ll want a boot-mounted partition, but I’d like to deal with this issue first.

Might it be better to change the ownership of the mapper device and change fstab to use “owner” instead of “user”?

@ Crosshair You don’t need to. “dd” will automatically exit when it runs out of partition (or disk). By the way, you can in fact random-wipe a whole disk (like /dev/sdc), but you’re much better off doing it by partitions (/dev/sdc1). This is especially so when you’re trying to wipe a terabyte or larger drive — split it up into partitions that you can wipe in a mere day or two! I was getting a fairly steady 4MB/s, but I don’t know whether that was pinned by my drive or the USB spec.

Oh yeah — after a reboot, make sure the drive you’re working on is still the *same* device!

@David Harmon Can You kindly advice how to check the progress of dd? I am doing this for two days already with /dev/random on 2 TB partition. Is there anyway to check how much is already done if partition is not mounted? Thanks!