assorted pieces of random gobbledygook

Of course I couldn’t keep my trap shut when Jacob Appelbaum recently dissed Rubberhose in a recent talk at the 22C3. So I decided to do some research into the current state of disk encryption myself. I haven’t been really following that topic since about the 2000 or 2001. I’m currently using FileVault, LUKS and GBDE on my boxen, but to be honest - even though I’m a cryptologist, I haven’t had time to research their security yet - save some failed attempts at reverse-engineering the DiskImages framework of MacOS X to figure out what exactly Apple is up to with FileVault.

The following links are without meant to be notes to self for future research.

Research papers:

I. Damgård and K. Dupont:

Universially Composable Disk Encryption Schemes (IACR ePrint, PDF)

K. Gjøsteen:

Security notions for disk encryption (IACR ePrint, PDF)

M.J. Saarinen:

Encrypted Watermarks and Linux Laptop Security (WISA 2004 proceedings, backup can be here)

Implementation reports:

Dowdeswell and Ioannidis: The CryptoGraphic Disk Driver (NetBSD)

P.H. Kamp: GBDE - Geom Based Disk Encryption (FreeBSD)

C. Fruhwirt: LUKS On-Disk Format Specification Version 1.0 (Linux, dm-crypt based)

Deniable encryption:

Phonebook (Linux)

Rubberhose (NetBSD/Linux) mirror only

TrueCrypt (Windows XP/2000/2003, Linux)

Being a frequent OpenVPN/TunnelBlick user these days, I want to change my DNS resolver configuration after having established a tunnel. Until very recently I was under the impression any decent Un*x-like OS has its resolver configuration in /etc/resolv.conf. Well, this doesn’t apply for OSX. The resolv.conf in /etc is only a read-only mirror of the resolver configuration; changes in this file will not be propagated back to the resolver. No, this setting needs to be manipulated in a “dynamic store maintainted by configd(8)” [AFP548: Using scutil to set DNS server]. Thank you very much, Apple.

UPDATE: The above apparently only applies to Tiger; the issue has been discussed in several other places before

I updated our OpenVPN gateway - it’s running on a sparc64 box -  from FreeBSD 5.3 to 5.4 yesterday. Since we had problems with the bridge(4) code in 5.3, I tried to give if_bridge(4) a shot but ran into a different error here. Running the following commands

ifconfig bridge0 create
ifconfig bridge0 addm hme0 addm tap0 up

on the gateway creates a bridge alright. However what it also does: it also causes FreeBSD to corrupt the  checksums of all outgoing TCP packets on hme0. Not good. Reverted back to the old bridge(4) code. Since FreeBSD 5.4 is an intermediary step for this box anyway - I’m upgrading to 6.0 - I will not investigate this problem further at this stage. The ethernet address flip-flop problems that occured under FreeBSD 5.3 with bridge(4) when having tap interfaces in the bridge seems to be resolved in FreeBSD 5.4 however.

Reading Bruce Schneier’s notes on the NIST Hash function Workshop I came across a real gem in the comments section: A student of Lars Knudsen, Søren Steffen Thomsen, has released working C code for generating MD5 collisions using Wang’s method. Very useful, indeed. I will have to reread Magnus’s paper on finding differentials (I can’t find that online right now, but it should be contained in his thesis) one of these days to find out whether it’s feasible to obtain a differential with good probability that has a non-zero value at position 1.

Back when I first looked at JustePort and raop_play, the Apple Lossless encoding was missing. Having stumbled across the reverse-engineered ALAC decoder again this weekend I decided to have another look how difficult it is to make my Airport Express play nicely with Linux.

Oh joy! JustePort 0.2 and raop_play from version 0.4 on already have an ALAC encoder built in. Yay! So I cobbled together an ebuild for my desktop box (an AOpen EA65 II) and pondered my next move. Obviously I was going to need a decent audio player on my system, having been spoiled by iTunes. Being mostly desktop environment agnostic, I had two choices here: rythmbox and amaroK. Flipping a coin, amaroK it was. Fortunately amaroK can be built with gstreamer support, which enabled the following crude hack:

gstreamer provides an output sink called tcpclientsink which can be made to connect to an arbitrary host and port. By default it connects to localhost:4953 and sends all of it output data there (44100Hz, 16-bit stereo in my case). For each song played in amaroK, however, a new connection is opened. raop_play by default calls external programs to decode mp3, aac and ogg files. These output the decoded data to stdout.

So I placed the following minimalistic glue scripts in my $HOME/bin/ape-hack directory:

mpg321:
#!/bin/sh
socat -s TCP4-LISTEN:4953,fork -

ape-gstreamer:
#!/bin/sh
PATH=$HOME/bin/ape-hack:$PATH \
exec raop_play <airport express ip> dummy.mp3


Socat is a nifty little universal connector; if you think of netcat as your typical Swiss Army Knife, socat is the Victorinox CyberTool with a built-in kitchen sink. After having configured gstreamer using gconf-editor (system->gstreamer->0.8->default->audiosink) I was set to go.

All of the above of course ain’t pretty, but amaroK now plays tunes on my APE. Regrettably the transition between songs isn’t smooth yet… I guess somebody has to write a gst-apesink soon Of course, nothing of the above is really Linux specific.