In my previous article about creating a "mountable" disk image in GNU/Linux, I explained how to create a file that effectively mimics the functionality of a disk: I explained how to create a file which will then be used, in turn, to contain directories and files. In this article I will explain how to make the next natural step: encrypt that file.
A summary of the previous article.
My previous article could be summarise like this:
- Make a file with
fallocate -l 512M image.iso
- Create a file system on it with
mkfs.ext4 -j image.isoor
- Mount the file right-clicking on it
This bets for the question: is it possible to change things so that the information on the file is encrypted?
Creating an encrypted container
The first step is to install the dm-crypt tools, which will give you the commands to create an encrypted file. In Ubuntu, just type
sudo apt-get install cryptsetup. Note that
cryptsetup tends to be already installed on CentOs by default.
You will still need to create an empty file:
$ fallocate -l 512M enc.iso
An empty file like this is like an empty shell; rather than putting the file system on top with
mkfs, we will use the
cryptsetup command to put a
LUKS container in it:
$ sudo cryptsetup -y luksFormat enc.iso
You will be asked to enter a password to encrypt the file:
$ sudo cryptsetup -y luksFormat enc.iso [sudo] password for merc: WARNING! ======== This will overwrite data on enc.iso irrevocably. Are you sure? (Type uppercase yes): YES Enter passphrase: Verify passphrase: $
A quick note about the password: the
-y option is there so that
cryptsetup will ask you to confirm the password. You must remember that if you lose that password, there is nothing you can do to get it back; there is no master password, and there is no way to recover it (unless you decide to brute force it, by trying passwords from a dictionary).
After this command, the
enc.iso file will be a "LUKS container". There is no trace of a file system on it yet: it's just en empty, encrypted shell.
Opening the LUKS encypted container
At this point, it's time to create a file system on the container. You cannot simply run
mkfs.ext4 image.iso: if you do, you will overwrite the LUKS container data you just created (and will replace it with a plain, unencrypted file system).
In order to open the LUKS container, you will need to use the
cryptsetup luksOpen command like so:
$ sudo cryptsetup luksOpen enc.iso encVolume
It's the same command as before,
cryptsetup, but with a
luksOpen option rather than
In order to open the LUKS container, you will be asked to enter a password. What you enter will need to match what you set.
The command above will map the file
enc.iso to the volume
encVolume. What this means, is that it will decrypt
enc.iso and will make it available, unencrypted, as the volume
encVolume. The volume
encVolume will be available as
/dev/mapper/encVolumeis the exact same size as
- Changing information in
/dev/mapper/encVolumewill imply that the same information will change in
enc.iso-- however, the information in
- Changing the file
enc.isodirectly will result in immediate, complete data loss as the information on it is completely encrypted
/dev/mapper/encVolumeis only available after opening
cryptsetup lukOpen(and providing the correct password)
Write a file system on the open LUKS volume
While you are free to write anything you like on
/dev/mapper/encVolume, if you think about it for a second, the most useful thing to store on it is... a file system.
This is easily done with:
$ sudo mkfs.ext4 /dev/mapper/encVolume
Once again: this command will write information on
/dev/mapper/encVolume, which is only an "decrypted view" of the file
At this point, you can mount
/dev/mapper/encVolume as you would do.
It's a Linux tool
LUKS stands for Linux Unified Key Setup. As the name says, it is a Linux tool. It's difficult to open volumes encrypted with LUKS in Windows or Mac. So, if your goal is to exchange files, LUKS might not be the best solution.
This is the same reason why it doesn't really make sense to create a file system like
vfat on a LUKS container: the container will most likely be opened by a Linux machine, able to read ext4 file systems.