Linux contains the necessary tools to create an encrypted filesystem either directly onto a device or separately in a file. Sadly, most distributions do not include the necessary modules (intentionally?) in order to achieve this and the procedures requires a recompilation of the kernel. We will run through the basic steps of creating a device or a file and refer you to the Debian kernel re-compilation tutorial in case you use Debian. Otherwise, follow the usual procedure of downloading the linux kernel from kernel.org and proceed with the rest of the tutorial.

In case you are planning to encrypt a device that is essential to booting, it is a good idea to compile these options in the kernel rather than compile them as modules (although they may be included in initrd image):

1. The CONFIG_BLK_DEV_CRYPTOLOOP along with its dependencies is the required setting and can usually be found under Device Drivers → Block Devices → Loopback device support and enable Cryptoloop support.
2. Go to "Cryptographic options" from the main menu and enable encryption the algorithms you trust. Popular choices include are usually AES or Blowfish cyphers. Careful with being exotic here.

Once you are done, recompile the kernel and install it (along with modules, if you opted for modules). In case you compiled cryptoloop as a module, then before we proceed, load the module:

modprobe cryptoloop

You have two options here:

• Either set-up the encrypted filesystem on a physical drive, in which case you would run dd:

dd if=/dev/urandom of=/dev/zgz1 bs=1M

and wait till the drive /dev/zgz1 fills-up with random bytes (in chunks of 1M).

• Or set-up the encrypted filesystem as a file:

dd if=/dev/urandom of=space.enc bs=1k count=5242880

which creates a 5GB file ().

Depending on whether you have initialised the free space on a device (/dev/zgz1, in this example), you would run:

losetup -e aes-256 /dev/loop0 /dev/zgz1

or, if you set-up a file (space.enc, in this example) using AES-256 encryption, you would run:

losetup -e aes-256 /dev/loop0 space.enc

losetup will prompt you for a password and then set-up the device. In case losetup fails with an INVALID ARGUMENT error, then there is a problem with util-linux and it has not been properly patched to support encrypted loopback devices.

Now you can create a filesystem on /dev/loop0 which will either have the device /dev/zgz1 attached or space.enc:

mkfs.ext2 /dev/loop0

and, after losetup completes, you can mount /dev/loop0:

mount -t ext2 /dev/loop0 /mnt/crypto

Then unmount:

umount /mnt/crypto

and detach the loopback device:

losetup -d /dev/loop0

First, make sure that the necessary modules are loaded (cryptoloop and the encryption modules) and issue:

mount -t ext2 -o encryption=aes-256 /dev/zgz1 /dev/loop0 /mnt/crypto

in case you set-up a device, otherwise, if you set-up a file, following the example, you would run:

mount -t ext2 -o encryption=aes-256 space.enc /dev/loop0 /mnt/crypto

You will be prompted for the password, after which you can write files to /mnt/crypto and they will be transparently encrypted. When you are done, you can unmount the device:

umount /mnt/crypto

and detach the loopback device:

losetup -d /dev/loop0 

Since mounting the device would require you to enter a password, you can omit the auto flag from /etc/fstab and use the following line instead:

/dev/zgz1    /mnt/crypto    ext3    noauto,encryption=aes-256    0    0

or, if you used a file:

/path/to/space.enc    /mnt/crypto    ext3    noauto,loop,encryption=aes-256    0    0

Then whenever you would issue:

mount /mnt/crypto

you will be prompted for the password.

To boot from an encrypted filesystem, you could wrap the mount procedures in a script and ask for the password during boot.

• Filling up a device or file with random bits from /dev/urandom may be a bit of a problem if you do not trust the hardware or software sources. For example, there is some dispute / distrust about trusting random number generators. Whether you pick haveged (which is seriously disputed) and trust a software algorithm to increase entropy or install rng-tools and trust your hardware (let alone a TPM…) are your few choices. In case the random-number generator is predictable (perhaps intentionally so), you are susceptible to some rather perverse attacks…
• You could add several layers of encryption in case you create a file inside the device or a file inside a file and use two (or more) sets of passwords with different cyphers.