Set terminal title (reset terminal title after it was scrambled by accidentally printing a binary file)

echo -ne "\033]0;SOME TITLE HERE\007"

Encrypted backup disk on Linux

Problem: I would like to store a backup disk in a different physical place every now and then, just to be sure in case of severe incident like a fire etc. Different physical place means to give up the control where the disk goes: It might be stolen, or it might simply be lost, or it might be sold on ebay by accident. Ok, I totally made the ebay thing up. :-)

Solution: Keep the backup disk encrypted.

Whole disk encryption is not as secure as it sounds, due to the limitations of sector-wise access, but it is _way_ better than not encrypting the disk at all, and it usually provides solid confidentiality (meaning an attacker cannot read any information from the disk).

(There are nasty attacks on whole disk encryption, but they are all around an attacker writing stuff to the disk, modifying it contents in various ways. But if the encryption is done properly all of these attacks leave random garbage in the decrypted view of the disk.)

I am using 'plain dm-crypt' instead of LUKS since I do not need any of the LUKS features and it is very easy to set up and very easy to understand what happens.

I am also using the entire disk as one big partition, without a partition table. Encrypted partition tables do not make much sense in my opinion, and I only want one partition anyway.

If there was already (plain) data on the disk (e.g. an unencrypted backup) it is wise to erase that by overwriting the disk with random garbage:

shred -n 1 /dev/sdX

Create encrypted layer of the disk:

cryptsetup --cipher=aes-cbc-essiv:sha256 --key-size 128 --key-file=key.bin open --type plain /dev/sdX enc

(I am using aes-cbc-essiv:sha256 with just a 128 bit key since it seems sufficient for my purpose. If you are concerned that somebody might modify the contents of the disk you are better off with using aes-xts-essiv:sha256 with a 512 bit key, but I was not happy with the performance penalty for very little benefit (if any).)

The file key.bin contains the 16 byte (128 bit) binary AES key. I created it using:

head -c 16 /dev/random > key.bin

I keep the key.bin file in plain on my server since I am not nervous of it getting lost. People with access to the server are unlikely to want to decrypt the backup disk of the server since they have full access to the data (even full access to the data on the encrypted disk!) anyway. Of course it is necessary to keep a backup of this key in another physical place, e.g. printed on paper etc. Otherwise the backup disk is useless.

The plain view of the encrypted disk image is now available under /dev/mapper/enc.


Creating an ext4 filesystem on the encrypted disk:

mke2fs -m 0 -t ext4 /dev/mapper/enc

Mount encrypted disk:

mount /dev/mapper/enc /backup_disk

Now you can create a backup on /backup_disk.

When done, umount the disk and stop the encryption (which might flush a few sectors to the disk):

umount /backup_disk
cryptsetup close enc

Useful links:
https://wiki.archlinux.org/index.php/Dm-crypt/Device_encryption
https://sockpuppet.org/blog/2014/04/30/you-dont-want-xts/

Monitor dd progress on Linux with old binutils

I recent was on an Ubuntu 14.04 machine, started a long running dd to clear a disk, and then wanted to monitor progress of this command to get an indication how long it would take.

In found that my binutils (dd) were too old for the dd status=progress feature.

Sending signal USR1 to dd prints its progress:

killall -USR1 dd

Alternatively you can just look at the write file descriptor of the dd process, e.g.:

grep pos /proc/4609/fdinfo/1