Ubuntu Full Disk Encryption with aes-xts-plain64

Insecure encryption with ECB

Illustration of a watermarking attack on poorly-implemented ECB

If your laptop was stolen (seized, confiscated, accessed surreptitiously etc.) right now, what would the attacker have access to? Boot and login passwords provide a very limited degree of security, and can be bypassed easily by even an unsophisticated attacker.

Unlike passwords, full disk encryption (FDE) can make the contents of a drive inaccessible to a powerful attacker who has possession of your computer. FDE provides the opportunity to protect your data with military grade encryption that can’t be compromised on a reasonable timeframe. At least, not by any currently known means. The only way to access the data protected by encryption is to obtain the encryption key.

AES-XTS provides the most secure mode of full disk encryption. Unfortunately, it’s not available by default in many Linux installation packages. Ubuntu’s “alternate” installation image provides other implementations like AES-CBC, but not aes-xts-plain or aes-xts-plain64. If aes-cbc is good enough for you, it’s been available in the Ubuntu alternate installer for quite some time. A thorough but dated guide outlining the process is available here.

By downloading an Ubuntu desktop installation image and doing a little initial setup, you can use aes-xts-plain64 on your system. Aes-xts-plain and aes-xts-plain64 both provide the same mode of operation, but you’ll need to use aes-xts-plain64 if you want to format a partition larger than 2TB. It’s also important to note that using very large block sizes for XTS mode could lead to security issues. Using 512-byte block sizes mitigates this issue.

How to install Ubuntu with aes-xts-plain64 (summary here)

  1. Download the Ubuntu desktop installation image and boot into a live desktop.
  2. Install a few necessary packages.
  3. Encrypt your destination disk with aes-xts-plain64 and mount it with LUKS
  4. Install ubuntu onto the encrypted disk
  5. Set up an encrypted swap partition
  6. Initialize the system so it can boot to the encrypted disk
  7. Reboot into your new installation

This process can be applied to other Linux distributions with minimal modification. The same basic method should work on most systems. I used a similar process to implement full disk encryption on Arch Linux.

Expert instructions/Quickstart summary

If you feel confident using an abbreviated guide, this contains an outline with all the commands.

Download the Ubuntu Desktop installer and boot into live mode

Get the current desktop installation image from Ubuntu and instead of going straight into installation, select the “try without installing” option to boot into a live desktop. After Canonical’s Gnome 3/Unity disaster, I switched to xfce (so did Linus Torvalds), so this guide describes the process of installing Xubuntu.

Once in the live desktop, open gparted and set up your partitions. I set up mine like this:

aes-xts-plain xubuntu gparted

My disk layout

In my case, I created a 200 megabyte ext4 partition for /boot. /boot needs to be unencrypted in order for your computer to start! I’ll use the second, 2GB partition as swap space. The remainder of the disk will hold the root partition. You don’t need to format anything but the /boot partition right now.

I was installing to a blank (virtual) disk, so I went to Device > create partition table to set up the disk.

Install necessary packages for aes-xts-plain64

Once the partition layout is complete, close gparted, open a terminal and install lvm2. Other guides to full disk encryption in Linux use LVM on top of physical partitions. For me, this would only add extra complexity and overhead. I prefer to use plain partitions.

 Encrypt the destination disk with aes-xts-plain and mount it

Use cryptsetup luksFormat to encrypt your disk and mount it with luksOpen:

#cryptsetup luksOpen /dev/sda3/ crypt
will mount the newly-created container to /dev/mapper/crypt. You can choose whatever name you prefer. This will be the location of the root partition.
# mkfs.ext4 /dev/mapper/crypt
will format the drive to ext4, while
#mkswap /dev/sda2
creates a temporary, unencrypted swap space.

Install Ubuntu on to the disk

Once formatting is complete, go to the desktop and click the installer icon. When it asks if you want to use the whole disk, click “do something else” and specify your partitions manually. Here is what mine looked like:

aes-xts-plain64 xubuntu

Right click the partitions to specify mount points. I put /boot into the 200 megabyte /dev/sda1 partition and / onto /dev/mapper/crypt.

Important: During some installations, Ubuntu will choose the USB as the destination device for boot loader installation. Be sure the correct hard disk is selected for bootloader installation!

Once the disk is set up, proceed with installation as normal. When installation is complete, don’t reboot! Click “continue testing!”

Initialize the system so it can boot to the encrypted drive

Open a terminal and mount your newly-installed root partition to a directory so we can make some changes:

This mounts the newly-created / and /boot partitions to /mnt/root and /mnt/root/boot respectively. Now, chroot into your root partition:

Now the new system has all the packages it needs to work with its encrypted partitions (Note: make sure you install cryptsetup! Otherwise you’ll get the “cryptsetup: evms_activate is not available” error). Open a new terminal and type:
sudo blkid
This will list the system’s partitions, their UUIDs and their types.

Take the UUID of /dev/sda3 (or whatever drive you luksFormatted. It will have Type=”crypto_LUKS” next to it in the blkid output) and paste it into the bottom line of your new system’s /etc/crypttab in the following format:
crypt UUID=[the UUID of /dev/sda3 from blkid] none luks
When /etc/crypttab has been changed, update your initramfs so it can boot to the encrypted root partition:

Set up an encrypted swap partition

Turn off your swap and initialize it with cryptsetup by issuing the following commands:

When mkswap is complete, add the following line to /etc/crypttab:
cryptswap /dev/sda2 /dev/urandom swap
This will encrypt your swap with a random key on each boot. Encrypting your swap like this will break hibernation, but I never use hibernation anyway. If you still want to use hibernation, check out this guide.

The completed /etc/crypttab on my new installation looked like this:

Now, open your new system’s /etc/fstab and change it to look like this:

Verify that the root filesystem is /dev/mapper/crypt (or whatever you named your encrypted root partition). Alter the swap partition’s line to reflect the changes you made in /etc/crypttab. Before editing, the last line of my fstab read
/dev/sda2 none swap sw 0 0
and I changed it to
/dev/mapper/cryptswap none swap sw 0 0
After you’ve double-checked that the values in /etc/fstab match the values in /etc/crypttab, your system is ready to reboot! If everything went well, you should be greeted with an “Enter passphrase” prompt after startup:

Login screen on an Ubuntu system using full disk encryption

If you chose a secure passphrase and you can’t remember it now, you’ll need to reinstall the system. That’s the beauty of well-implemented encryption: there is no way around it (for now). Other than the passphrase prompt at boot, full disk encryption is completely transparent. It doesn’t feel any different from working on an unencrypted system. Once your system boots and you log in, verify that your swap is encrypted by viewing /proc/swaps:

ubuntu encrypted swap

/proc/swaps shows that my swap partition is on /dev/dm-1

If /proc/swaps shows that your swap is on a mapped drive, it’s encrypted. If it says your swap is on a physical partition like “/dev/sda2,” something is wrong.

Assuming everything worked, if your hard drive falls in to the wrong hands, you won’t end up like these people:

Compelling cases for full disk encryption:

If you’re a journalist who works with confidential sources, or you know any journalists who do, please look at this article: The spy who came in from the code. Sean McAllister was covering Syria and his carelessness with data led to his sources being outed, captured and possibly killed.

List of UK government data losses

A Pepperdine study titled “The Cost of Lost Data” showed that a significant amount of data loss results from theft.

Lost hard drive and other government data blunders

UBC computer with sensitive data recovered

One in 10 secondhand hard drives in U.K. contain personal data

The full list of data losses that could have been prevented by full disk encryption is staggering, and stories continue to crop up in the news about organizations and governments losing computers that should have been encrypted.

Further Reading

EncryptedFilesystemHowto – Community Ubuntu Documentation
cryptsetup – Frequently Asked Questions
System Encryption with LUKS – ArchWiki
Cipher benchmark for dm-crypt / LUKS

Incoming search terms:

15 thoughts on “Ubuntu Full Disk Encryption with aes-xts-plain64

  1. This is extremely helpful – thanks. I look forward to trying this. I am running Ubuntu 12.04 from the alternate install with FDE and am very happy with it (esp. happy now that I’ve installed Xfce in place of the horrid Unity). But can you elaborate on what you say is the superior security of AES-XTS over, say, AES-CBC?

    I notice from here –


    that “XTS mode is the most common if you are encoding a random accessible data (like a hard disk or RAM).”

    That same page also says “CBC, OFB and CFB are identical, however OFB/CFB is better because you only need encryption and not decryption, which can save code space.”

    Why doesn’t Ubuntu natively support XTS mode used if it is better? And how can I find out what mode of AES my default install uses?

    My installation followed the procedure illustrated here:


    Again, many thanks for this useful post.

    • By default, Ubuntu used to use aes-cbc-essiv:sha256, but I’m not sure if that’s still the case. CBC is still a good option, but CBC is vulnerable to watermarking attacks like the one illustrated by the picture at the top of the article. It can also be less efficient in parallel operation. These two shortcomings are both addressed by XTS mode.

  2. Thanks for these great instructions! ( And extra thanks for the abbreviated plain text version too :) ) I’m getting ready to implement this on a system. I have a question for you on how aes-xts interacts with newer Intel CPU’s that have the AES-NI instruction set? Is it supported by the Instruction set, and on Linux 3.2 and higher? I know that in the past for example, certain benchmarks demonstrated that there was virtually no advantage to using the aes-ni-intel kernel module vs the generic with Linux 3.0.x. (it was actually slower in some tests) I’m curious to know what kind of performance you have seen with aes-xts. (especially on SSD’s with ext4 and no journal)

    • Hey Chris,
      Glad it was helpful. According to Phoronix, it seems like AES-NI improves performance in most cases. A key exception seems to be LVM, which I don’t use, and some minor performance hits in a few specific file access tests. Otherwise, the AES-NI kernel module seems to have performance benefits across the board. I just started using it recently and tbh, I haven’t noticed a difference. Performance was excellent before.

  3. Awesome, awesome, awesome guide. Works on BT5 r3. Just two small notes, BT5 already has lvm2 installed and when you are all done, don’t panic at the dragon splash screen, it’s waiting for your luks passphrase, there’s just no prompt. Thanks!

  4. Thanks for this great tutorial! It really shortened the time to put up a hardened linux system.

  5. Thank you very much for the information, it was extremely useful to me!

    I’ve successfully applied these instructions to encrypt a standard Ubuntu 12.04 system with Unity, and it worked perfectly. A small note to others who prefer the standard Ubuntu with Unity: the first time you boot into your new system the boot process will halt in a black screen, but all you have to do is to press ESC and then you’ll see the prompt asking for your encryption phrase.

    I had used before another procedure that included LVM in the recipe. That only confused me, and I’m glad to know that I can get away without it. This procedure is much clearer and straighforward to me.

    Since the boot partition has to be unencrypted, I prefer to install it in a pendrive along with the bootloader, so that I can take it away with me.

  6. hi!

    thanks for your excellent manual! it seems quite simple to follow, even for a non-geek.

    only in my scenatio i’d like to have root and home on a diferent partition to be able to reinstall ubuntu later if needed and leave home partition untouched. it seems to me that this would not complicate things too much and would be very grateful if i can get an advice from you.



    • I usually install Windows on my machine before installing Ubuntu. As long as you leave your Windows partition alone or change its size and location carefully before adding your Linux partitions, Ubuntu will recognize your Windows partitions and automatically add Windows to your Grub menu. I tend to reinstall Linux every few few months on my computers and it’s never caused any problems with my Windows installations.

  7. i forgot to tell you that i’d like also to have a windows partition on the same deive (at the first position). from other manuals that i read it seems that it’s no problem and that nothing should be changed specially because of this. am i right?



    • That’s correct. Just be sure you know which partitions hold what so you don’t hose your Windows installation.