Chris' blog

SOPA blackout tool

All websites that I control will be displaying a protest about SOPA instead of their usual content from 00:00 UTC+1 tonight until the same time tomorrow. There are a few WordPress plugins available to do the job, but most of my websites don’t use WordPress, so a better way is needed. I’ve put a simple htaccess and php script on my GitHub, which does the job nicely.

Getting intel driver to work on some pcspecialist laptops

A while ago I ordered a PC for my mother from pcspecialist, a company I’ve ordered laptops from a few times and been pleased in each instance. I have tended to have them running Arch, but since this case would require my mother maintaining her own computer with little intervention (and she is not proficient with computers in general, never mind Linux), I decided to go with Debian. The installation was fine, but after entering GDM I noticed a problem — the display mode was completely wrong. Instead of using the intel driver, X would fall back to vesa and output in 1024×768. Trying to use intel resulted in “no devices detected”. This turns out to be because of lacking support for the graphics chipset in the current squeeze kernel provided by the linux-image-2.6-686 metapackage. I do not know at which point the driver for this chipset is included in the kernel, but at the present time an appropriate driver is in backports. Just enable backports in your sources if you haven’t already and issue aptitude -t squeeze-backports install linux-{image,headers}-2.6-686.

Securely erasing flash media

Working with a coworker this afternoon, I noticed him attempting to overwrite a USB flash disk with NULs using /dev/zero. After asking him about what he was hoping to achieve with this, he stated that he was attempting to securely erase the disk. It appears to be a common misconception that zero is the erase state for USB flash devices — in fact, one is the erase state. It seems like tr would be a potential candidate to solve this issue:

tr \\000 \\377 < /dev/zero > /dev/sdX

This is fine until you encounter the huge overhead from tr. On my AAO, it almost triples the time it takes to produce the same size of output (the use of cat here is necessary to make it a fair test, that is, that we include the pipeline both times):

$ time tr \\000 \\377 < /dev/zero | head -c 1000000000 > /dev/null

real    0m12.396s
user    0m10.243s
sys     0m5.613s
$ time cat /dev/zero | head -c 1000000000 > /dev/null

real    0m4.506s
user    0m0.777s
sys     0m5.200s

Some C is probably the best method:

#include <string.h>
#include <unistd.h>

int main() {
    char buf[4096];
    memset((void *)&buf, '\377', sizeof(buf));
    while(true)
        write(1, buf, sizeof(buf));
}

$ time ./ones | head -c 1000000000 > /dev/null

real    0m4.103s
user    0m0.752s
sys     0m5.003s

Here’s one with better error checking, but it is slower as a consequence:

#include <string.h>
#include <unistd.h>

int main() {
    char buf[4096];
    memset((void *)&buf, '\377', sizeof(buf));
    while(write(1, buf, sizeof(buf)) == sizeof(buf));
    return 1;
}

Unifying PGP/SSH keys

In a moment of boredom today, I decided to unify my PGP/SSH keys. You should do this all in a ramdisk or encrypted filesystem to avoid saving the unencrypted key to disk, I prefer to just do it in a completely clean environment — I use Tails. Here are the steps I took:

Firstly, we need to get monkeysphere, a suite of programs dedicated to increasing the reach of PGP. This suite contains a script called openpgp2ssh, which is what we will need to do the conversion. Annoyingly, it doesn’t understand how to decrypt a key and then reencrypt with the same information, so you have to do it manually.

Now, export your secret key.

key=2A7D4D74
gpg --export-secret-key "$key" > id_rsa.bak

This will mean that we can quickly reimport it once we’re done (as we have to remove the encryption and passphrase).

Now issue gpg --edit-key, run passwd, remove the password, and then quit, saving the changes. This will remove the encryption from your key.

Now convert the keys and store them in the standard files in ~/.ssh.

gpg --export "$key" | openpgp2ssh "$key" > ~/.ssh/id_rsa.pub
gpg --export-secret-key "$key" | openpgp2ssh "$key" > ~/.ssh/id_rsa

We now change the password to the SSH secret key:

ssh-keygen -f ~/.ssh/id_rsa -p

Now reimport the original key (deletion is required or for some reason it fails to reimport as encrypted):

gpg --delete-secret-key "$key"
gpg --import < id_rsa.bak
rm id_rsa.bak

bug.n tiling window manager

For the rare occasions that I need to use Windows for something (namely: to play videogames) I feel pretty lost without a tiled WM. After using dwm all these years, Windows’ native “click at stuff” method feels vastly inferior and imprecise. bug.n fills that gap, as a dwm-like tiling WM for Windows.

I’m mostly just noting this here to avoid the inevitability of forgetting what it’s called when I have to reinstall this terrible operating system.

Creating an encrypted file container with LUKS

It’s relatively convienient to have a file container for groups of files that you’d might move about. A few people were asking about this today on ##linux, so I figured I’d write a quick blog post on the concept and execution.

Firstly, let’s create the container. Have no delusions — LUKS does not provide plausible deniability by any means, however, for situations where that isn’t an issue, it is still a good idea to make it difficult for an attacker to determine where your encrypted data begins and ends. We can do this by filling the drive with garbage data from a (P)RNG, in this case, I will use /dev/urandom. You could also use /dev/random, but you will need to keep on giving it entropy to make it output at a decent rate.

dd if=/dev/urandom of=container bs=1M count=20

This will create a 20M container filled with PRNG output. Now, associate a loop device with the container.

losetup /dev/loop0 container

The container is now mounted on /dev/loop0, and can be addressed in a similar manner to any other block device. Now, let’s format the container using luksFormat. This will set up the container in such a way that LUKS can address it.

cryptsetup luksFormat /dev/loop0

Now enter a strong password for the volume. Once done, you can mount the LUKS volume by using luksOpen.

cryptsetup luksOpen /dev/loop0 container

This will decrypt/encrypt the data to and from the loop device by using the map device at /dev/mapper/container. At this point, the encrypted container still has no filesystem, so create one:

mkfs.ext4 /dev/mapper/container

Now you can mount this to any appropriate mountpoint.

mount /dev/mapper/container /mnt/container

To unmount the map device, unmap the map device from the loop device and disassociate the loopdevice from the container, issue the following commands:

umount /mnt/container
cryptsetup luksClose /dev/mapper/container
losetup -d /dev/loop0

Using SSL certificates with rtorrent

A tracker I recently joined requires using an SSL tracker. This is a good step, but rtorrent requires some configuration to get it to work.

Assuming that the SSL port is 443 (it should be), use the following commands append the cert to to /etc/ssl/certs/ca-certificates.crt:

_tracker=[your tracker url]
_tracker="${_tracker#*//}"
openssl s_client -connect "${_tracker%%/*}":443 2>/dev/null < /dev/null | sed -n '/BEGIN CERTIFICATE/,/END CERTIFICATE/p' >> /etc/ssl/certs/ca-certificates.crt

Now rehash the certs as root:

SSL_CERT_DIR=/etc/ssl/certs c_rehash

Now go into your .rtorrent.rc, and add the following if it doesn’t already exist:

http_capath = /etc/ssl/certs

Now start rtorrent however you normally do, and it should successfully authenticate.