two weeks ago, i received my first smartphone ever: the fairphone. (which now makes me one of two fairphone owners i personally know of.) unpacking it was quite an experience, as the fairphone team paid a lot of attention to small details:

while unpacking i was accompanied by some of the cats, though they didn’t seem to have any interest in the phone itself:

well, the phone’s protective film told me to open it up, and so i did. after all, i own that phone. everything important is labelled:

exchaning the battery or adding up to two sim cards is easily possible. after re-inserting the battery and turning the phone on, i was greeted with a nice introductionary video. (video playback works fine, apparently.) the main home screen greets me with a large button to “enjoy some peace”, a nice mode disabling all network capabilities for an interval which can be set, allowing you to get away from emails, phone calls and other messages. there aren’t too many apps installed; in particular, all google apps (play store, maps, …) are missing, but can be installed by clicking a button. well, i thought about it for some time, but then decided against it, at least for now. there’s no need to start spilling my data around the world…
one of the first things i enabled, though, was the phone encryption – something like a hard disk encryption, i guess. by password. obviously, since typing in passwords on a phone is quite painful in the beginning, the password is not optimal yet, but that will change as soon as my typing capabilities got better :) (let’s see if they use something like luks, which would allow me to just type in a new password, or whether the whole thing has to be re-encrypted…)
anyway, since smartphones are quite low-security products, i’m not sure yet for what exactly i will use it after all… but it definitely won’t get full access to my server and other computers’ data, which probably should include email as well.

today i was in bad säckingen to give a talk at the kinderuni (children university) hochrhein, a eu-funded joint project between the two cities bad säckingen in germany and stein (ag) in switzerland. in the talk, i tried to explain kids, age 8 to 12, a bit about cryptography.

starting with caesar-type ciphers and more general substitution ciphers, i then continued to explained how to crack such ciphers using frequency analysis. this included a live demonstration, which was quite fun thanks to all the contributions from the audience. after shortly giving hints on how to improve on ciphers, i quickly presented the advanced encryption standard before continuing with the second part of the presentation: public key cryptography.

i began by explaining the situation: two cats want to communicate / exchange something (like cat food :-) ), while a third cat is watching / able to intercept (eat). after mentioning diffie and hellman, i continued with a more practical example: a simple massey-omura three-pass protocol type exchange using a box and two padlocks. this was another great thing, asking the kids how they think this could work after presenting the box and the padlocks. and the sudden murmur of understanding when the second lock got added to the box and the box was sent back.
afterwards i asked the kids how they think this system could be attacked, and they both came up with the bruteforce (crack the box open) and the more tricky (man-in-the-middle attack) variant. great!

the last slides on factoring-based crypto and elliptic curves were quite hard to comprehend, as i knew beforehand, but at least they now know that there’s more out there for which they have to learn more about mathematics :-)

if you’re interested, you can download the slides here.

recently, there was a pratical attack against linux encrypted hard disks (with linux unified key setup (luks)) which use some form of cipher block chaining (cbc) mode. since this mode was the default some time ago, and i did use it in the past, and also had some other not-so-great setups especially on older backup disks (like using sha1 instead of sha2), i thought about re-encrypting some of my backup disks.
the usual re-encrypt step with luks goes as follows: get another harddisk with enough space, copy the data over there, re-create the luks encrypted disk, and copy the data back. takes a lot of time and space. in theory, it should be no problem of re-encrypting a disk on the fly (in theory, even while using it), but i didn’t like the idea of investing quite some time to implement that. fortunately, after searching around the web a bit, i found out that someone already did it. (offline only, though, but that’s completely fine for backup disks.) in fact, it is part of the official cryptsetup distribution form version 1.5.0 on. unfortunately, the cryptsetup coming with my installed linux mints is 1.4.3, but then, since re-encryption does not require kernel support, i could just compile the new cryptsetup and use the compiled version’s cryptsetup-reencrypt command line tool. well, and so i did.
since the process can be a bit more complicated, i wanted to document it, and since i didn’t find too much on cryptsetup-reencrypt on the net, i thought writing a blog post about it is a good idea :-)

simple resizing.

warning: if you experience power loss or your machine crashes during re-encryption, the whole encrypted harddisk might be unusable! so only do this for data you already have backuped. in case you want to re-encrypt your only backup disk, take this as an opportunity to buy a second backup disk, encrypt it with the correct settings, copy the data there as well, and only then re-encrypt your old backup harddisk.

well, you have been warned. so now let’s get it done.

so let us assume we want to re-encrypt partition /dev/sdx1. namely, we want to use aes in xex-based tweaked-codebook mode with ciphertext stealing (xts) with a key size of 512 bits (that is, we use aes-256) with hash function sha-2 with 256 bits. moreover, the hash function should be iterated often enough to obtain a time of around 2 seconds. for this, we can simply run
cryptsetup-reencrypt -c aes-xts-plain64 -s 512 -h sha256 -i=2000 /dev/sdx1
to improve performance, we can set a higher buffer size (like 32 megabytes with -B 32) or use direct i/o (with –use-directio). the command line will then be:
cryptsetup-reencrypt -c aes-xts-plain64 -s 512 -h sha256 -i=2000 -B 32 --use-directio /dev/sdx1
for some setups, this will start running, take ages, and eventually finish with a happily re-encrypted harddisk. (note that you need to enter all keys, not just one – if you don’t know one, remove it before calling!) to check out the result, run:
cryptsetup luksDump /dev/sdx1
everything is fine when you see the following in the output:

1...
2Cipher name:      aes
3Cipher mode:      xts-plain64
4Hash spec:        sha256
5...
6MK bits:          512
7...

resizing necessary.

warning: if you screw this up, you can destroy your filesystem.

the whole task gets slightly more complicated when cryptsetup-reencrypt tells you something along the lines of
Data offset for detached LUKS header must be either 0 or higher than header size (4036 sectors).
that simply means that there isn’t enough space for the (larger) luks header; so you need to make some space.
assuming you encrypted an ext2/3/4 filesystem, you can work around this as follows, assuming that you still have enough free space left on that device: first unlock the luks partition, then resize the ext2/3/4 filesystem, and finally re-encrypt with moving the data backwards (cryptsetup-reencrypt has an option specifically for this). first, run e2fsck on the filesystem (we assume it is unlocked to /dev/mapper/yourfilesystem)
e2fsck -D -p -v -t /dev/mapper/yourfilesystem
(add -f to force a complete check, and remove -p if you don’t want automatic repair in case of errors.)
if that ran through, observe the output:
disklabel: clean, 12345/123456789 files, 98765/987654321 blocks
since blocks have size 4 kilobytes (verify this by running dumpe2fs -h /dev/mapper/yourfilesystem and look for “block size”!), we can shrink the disk size by 512 blocks to obtain 2 megabytes of free space at the end of the encrypted partition – that should be enough space for the larger luks headers. to compute the new size, we take the maximal block number (987654321) and subtract 512 from it: in this case, we obtain 987653809. so now we can resize the ext2/3/4 partition to these many blocks:
resize2fs -p /dev/mapper/yourfilesystem 987653809
this also takes some time (though much less than cryptsetup-reencrypt). when it is done, we can run e2fsck another time if we want, and then lock the container:
cryptsetup luksClose yourfilesystem
then we can start re-encryption with data movement. for this, we add –reduce-device-size 2M, which moves the partition data by 2 megabytes to the back (note that cryptsetup-reencrypt uses base 1024, so 2 megabytes equals 2097152 bytes and not 2000000 bytes as in si units) – throwing away the last 2 megabytes of the encrypted filesystem. (since we resized our file system, we don’t use these anymore, so everything should be fine.) so we run:
cryptsetup-reencrypt -c aes-xts-plain64 -s 512 -h sha256 -i=2000 --reduce-device-size 2M -B 32 --use-directio /dev/sdx1
this runs for ages, and after it’s done, you can check the parameters with cryptsetup luksDump /dev/sdx1. afterwards, it isn’t a too bad idea to unlock the filesystem and run e2fsck again.

more complex settings.

everything get’s more complicated if you didn’t just encrypt a single filesystem, but say for example a whole set of partitions (using lvm, linux’ logical volume manager). in that case, you have to shrink its “physical volume”. fortunately, lvm has some support for shrinking and extending logical and physical volumes (see pvresize, lvresize and friends). if/when i’m actually trying this out, i might add some more details here (or in a new post) on how to do it.

we were in brand for a second time. this time, we went for skiing, relaxing and taking photos.

well, unfortunately, there wasn’t much snow around when we were there, especially in the valley. many ski tracks were closed, but for beginners as me, this didn’t really matter. (except on one day, when due to upcoming storm they had to close some of the beginner’s tracks as well. :-) ) it was only on the day before we left that it began to snow, and on the day we left suddenly even the valley was covered in a winterly white, which we could watch from inside the bus…

anyway, what i’m doing on skis is now closer to what people would call skiing, and i’ve been able to practice almost every day – so it wasn’t bad after all. unfortunatly, the “taking photos” part of our trip suffered due to that and the small amount of snow. still, here are a couple of nice photos i took:

(on the second photo, you can see the lünersee dam.)