bk99.de entertain the web since 1997

bk99.de
Own project · SecurityOwn post

Encrypting a disk in 2006: dm-crypt instead of cryptoloop

Summary

In September 2006 I switched my home partition from cryptoloop to dm-crypt, which came with the device mapper in kernel 2.6. The partition was set up with cryptsetup in plain mode without a header, unlocked either by passphrase or by a key file on a USB stick, and an init script mounted it at boot. This post from my old blog shows the procedure of the time, the measured performance loss and why LUKS2 is used today.

Why switch

Until 2006 my data lived in partitions encrypted with cryptoloop, i.e. via a loop device with built-in encryption. Kernel 2.6 brought a cleaner way with the device mapper and its crypt target: dm-crypt puts an encrypted layer between partition and file system without the detour through loop devices.

There was also a security reason. In 2004 weaknesses in how initialisation vectors were computed became known (CVE-2004-2135 for cryptoloop, CVE-2004-2136 for dm-crypt): with predictable vectors an attacker can use specially prepared files, so-called watermarks, to prove that certain data is on the disk without knowing the key. dm-crypt offered ESSIV, which derives the vectors from the key and thus makes them unpredictable. That is exactly what I used.

Kernel and tools

I did everything on Gentoo. In the kernel, device mapper support, the crypt target and AES had to be enabled:

Device Drivers -> Multi-device support (RAID and LVM)
  [*] Multiple devices driver support (RAID and LVM)
  <*>   Device mapper support
  <*>     Crypt target support
Cryptographic options
  <*>   AES cipher algorithms (i586)

On top came cryptsetup and, for the key file, sharutils. Before encrypting I overwrote the partition once with random data so that used and free areas cannot be told apart later:

emerge sys-fs/cryptsetup app-arch/sharutils
shred --verbose --iterations=1 /dev/sda9

Passphrase or key file

There were two sensible ways in. Combining passphrase and key file seemed redundant to me at the time: if nobody can get at the file, it needs no extra passphrase, and a chain is only as strong as its weakest link. Commands and comments are shown as in the original, in German.

# mit Kennwort
cryptsetup -c aes-cbc-essiv:sha256 -s 256 -y create home /dev/sda9

# mit Schlüsseldatei auf dem USB-Stick
cryptsetup -c aes-cbc-essiv:sha256 -s 256 \
  -d /mnt/usbstick/crypt_keys/rechnername_partition.key create home /dev/sda9

# Dateisystem anlegen und mounten
mkreiserfs /dev/mapper/home
mount /dev/mapper/home /home

So that the partition did not have to be set up by hand after every reboot, I wrote a Gentoo init script that ran cryptsetup and mount at boot and unmounted the partition and removed the mapping at shutdown. rc-update add mount_crypt default put it into the default runlevel.

What it cost

On my SATA disk throughput dropped from 47.18 MB/s on the unencrypted to 21.89 MB/s on the encrypted partition, so by more than half. The processors of 2006 still computed AES entirely in software. Anyone who wanted to do it properly also had to think of swap and /tmp: data lands there in plain text too unless they are encrypted.

What has changed since

The command cryptsetup create sets up a mapping in so-called plain mode: there is no header on the disk, only encrypted data. That has drawbacks. A wrong passphrase goes unnoticed, the result is simply garbage; the passphrase cannot be changed without re-encrypting everything; and there cannot be multiple keys.

That is exactly why LUKS, the Linux Unified Key Setup, was created, co-developed by Clemens Fruhwirth, one of the authors of dm-crypt. LUKS puts a header with key slots in front of the data. Since cryptsetup 2.1 from 2019, LUKS2 is the default, with aes-xts-plain64 as the cipher and Argon2id as the function that derives the key from the passphrase and makes guessing expensive. XTS has replaced CBC with ESSIV for disks.

The rest is history too: cryptoloop was removed from the kernel in late 2021 for Linux 5.16, ReiserFS with Linux 6.13 in late 2024. Processors with AES instructions now encrypt so fast that the loss is hardly measurable on normal disks; cryptsetup benchmark shows the figures for your own machine. And shred does not reliably overwrite all data on SSDs because of their internal block management; there the only remedy is to encrypt from the start.

Numbers at a glance

  • Measured throughput in 2006: 47.18 MB/s unencrypted, 21.89 MB/s with dm-crypt (AES-256, CBC-ESSIV).
  • CVE-2004-2135 and CVE-2004-2136 describe the watermarking weakness of predictable initialisation vectors.
  • LUKS2 has been the default format since cryptsetup 2.1 (2019).
  • cryptoloop was removed for Linux 5.16, ReiserFS with Linux 6.13.

References

Remarks

  • This post was originally published on 13 September 2006 in my old Plone blog. In 2026 I retrieved it from the Web Archive, revised the wording and added today’s state. Commands and measurements are those of the time.
  • Please do not copy it for new installations: today encrypted partitions are created with cryptsetup luksFormat, or directly in the distribution’s installer.

Original post in the Web Archive

Own project · 2026

SYN-ACK reflection: when your own web server works for someone else’s attack

In October 2026 the firewall log of my home network suddenly showed hundreds of connection attempts to my reverse proxy, all from two networks of a Polish provider. The analysis revealed crafted SYN packets whose replies nobody ever answered, so most likely not an attack on me but on the network of the supposed senders. This post shows how to recognise SYN-ACK reflection, why my country block did not apply and how I drop the packets in OPNsense for a limited time.

Own project · 2007

SSH brute force in 2007: hashlimit against script attacks

In early 2007, automated scripts tried up to 15,000 passwords a day against my SSH access, and in one night more than 1,500 login attempts against the POP3 server came on top. Instead of the usual recipes with limit or recent, I used the iptables module hashlimit, which limits new connections per source address without locking myself out. This post from my old blog shows the rules of the time and what nftables, fail2ban and OpenSSH bring along on their own today.

fefe · 2014

Signify instead of GnuPG for LibreSSL releases

In 2014 the OpenBSD team signed the releases of its new OpenSSL fork LibreSSL not with GnuPG but with signify, a tool of its own. The reasoning: signify comprised only around 1,300 lines of C code, and there was not enough energy to clean up two poorly written crypto code bases. Felix von Leitner then ported signify to Linux and pointed out a weakness: the public key was on the same server as the signed files.