security

My GPG key transition to a 4096-bit key

This is long overdue, so here goes:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1,SHA512

I'm transitioning my GPG key from an old 1024D key to a new 4096R key.

The old key will continue to be valid for some time, but I prefer
all new correspondance to be encrypted to the new key, and will be making
all signatures going forward with the new key.

This transition document is signed with both keys to validate the transition.

If you have signed my old key, I would appreciate signatures on my new
key as well, provided that your signing policy permits that without
re-authenticating me.

Old key:

pub   1024D/0x5DD5685778D621B4 2000-03-07
      Key fingerprint = 0F3C 34D1 E4A3 8FC6 435C  01BA 5DD5 6857 78D6 21B4

New key:

pub   4096R/0x1D661A372FED8F94 2013-12-30
      Key fingerprint = 9A17 578F 8646 055C E19D  E309 1D66 1A37 2FED 8F94

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAlSwEaIACgkQXdVoV3jWIbQW5QCgoFHVU/D4fKSbvmGv3nNy3MAW
S2UAn075ztmxQ8Y9/22crbUug1sEjfh5iQIcBAEBCgAGBQJUsBGiAAoJEB1mGjcv
7Y+U9PgP/29jPvrNcdWsLI8YK9U6+JzS+TMXNyfp6CQXc8O/+zJwqvvxNpqY3rLM
5otRLIEJ2EVdiF8sCWTDGusS9NkMePzumR0AFAR0iltIkekO5O0HbHhK0sXJQv0s
EipDpFRO9k4/CBpJEy6Pkkxwd3ndtmwrL1/oKeVmM4E62PJd9ofMpQb/gMUsrA8u
F8xoOXY8Os82Rrd759PypSxNecjd6SYaVJTHgFbZ0QIMJkdKaufifzARdw+v5jwg
8Q11BhpYxvUSugZgiciKA6RjRK5bfRnT8VQPFd0zneilsIW13zz/jub9df/vtM5L
vY/6jHvXczYXSG8EGpHJQCD3KtQJPWZ0Nz9rAm4emEPmR2qav6KGARatYAm0RBqZ
Y81YUEuiWzGli6DH1m9SQe8bqM/J94vQAAX9VqUn2gz0Z0Ey25kVQE7NOGsbbGVS
vD/E74FSk1At9/RGpstrfEjsDKPRman2xk/oZe+08sRB22CJl40N4tZV9AkCJNom
HHGZKp+VEKaCEiLUIRjKTHt2HTThg39zmxl+OnoTSFYvloxrDJyi9SxZgCAmBhbD
7kLkaSDmdUj6CmoilGU+gd2zmQl2D+RHinYZBxOUf1vi1MDLWNcLIMgrz4mRXgzE
YKkG0newf9UbyJw42sXe2ukNQBIqBcL/DmAhG7V+r0RD7MQnMEYy
=09bN
-----END PGP SIGNATURE-----

The new key is available from keyservers, e.g. pgp.mit.edu or others.

In other news: Yes, I've not been blogging much recently, will try to do updates more often. In the mean time, you can also refer to my Twitter account for random stuff or the new sigrok Twitter account for sigrok-related posts.

How to setup an encrypted USB-disk software-RAID-1 on Debian GNU/Linux using mdadm and cryptsetup

This is what I set up for backups recently using a cheap USB-enclosure which can house 2 SATA disks and shows them as 2 USB mass-storage devices to my system (using only one USB cable). Without any further introduction, here goes the HOWTO:

First, create one big partition on each of the two disks (/dev/sdc and /dev/sdd in my case) of the exact same size. The cfdisk details are omitted here.

  $ cfdisk /dev/sdc
  $ cfdisk /dev/sdd

Then, create a new RAID array using the mdadm utility:

  $ mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sdc1 /dev/sdd1

The array is named md0, consists of the two devices (--raid-devices=2) /dev/sdc1 and /dev/sdd1, and it's a RAID-1 array, i.e. data is simply mirrored on both disks so if one of them fails you don't lose data (--level=1). After this has been done the array will be synchronized so that both disks contain the same data (this process will take a long time). You can watch the current status via:

  $ cat /proc/mdstat
  Personalities : [raid1]
  md0 : active raid1 sdd1[1] sdc1[0]
        1465135869 blocks super 1.1 [2/2] [UU]
        [>....................]  resync =  0.0% (70016/1465135869) finish=2440.6min speed=10002K/sec
  unused devices: 

Some more info is also available from mdadm:

  $ mdadm --detail --scan
  ARRAY /dev/md0 metadata=1.01 name=foobar:0 UUID=1234578:1234578:1234578:1234578

  $ mdadm --detail /dev/md0
  /dev/md0:
          Version : 1.01
    Creation Time : Sat Feb  6 23:58:51 2010
       Raid Level : raid1
       Array Size : 1465135869 (1397.26 GiB 1500.30 GB)
    Used Dev Size : 1465135869 (1397.26 GiB 1500.30 GB)
     Raid Devices : 2
    Total Devices : 2
      Persistence : Superblock is persistent
      Update Time : Sun Feb  7 00:03:21 2010
            State : active, resyncing
   Active Devices : 2
  Working Devices : 2
   Failed Devices : 0
    Spare Devices : 0
   Rebuild Status : 0% complete
             Name : foobar:0  (local to host foobar)
             UUID : 1234578:1234578:1234578:1234578
           Events : 1
      Number   Major   Minor   RaidDevice State
         0       8       33        0      active sync   /dev/sdc1
         1       8       49        1      active sync   /dev/sdd1

Next, you'll want to create a big partition on the RAID device (cfdisk details omitted)...

  $ cfdisk /dev/md0

...and then encrypt all the (future) data on the device using dm-crypt+LUKS and cryptsetup:

  $ cryptsetup --verbose --verify-passphrase luksFormat /dev/md0p1
  Enter your desired pasphrase here (twice)
  $ cryptsetup luksOpen /dev/md0p1 myraid

After opening the encrypted container with cryptsetup luksOpen you can create a filesystem on it (ext3 in my case):

  $ mkfs.ext3 -j -m 0 /dev/mapper/myraid

That's about it. In future you can access the RAID data by using the steps below.

Starting the RAID and mouting the drive:

  $ mdadm --assemble /dev/md0 /dev/sdc1 /dev/sdd1
  $ cryptsetup luksOpen /dev/md0p1 myraid
  $ mount -t ext3 /dev/mapper/myraid /mnt

Shutting down the RAID:

  $ umount /mnt
  $ cryptsetup luksClose myraid
  $ mdadm --stop /dev/md0

That's all. Performance is shitty due to all the data being shoved out over one USB cable (and USB itself being too slow for these amounts of data), but I don't care too much about that as this setup is meant for backups, not performance-critical stuff.

Update 04/2011: Thanks to Bohdan Zograf there's a Belorussian translation of this article now!

Note to self: Missing lvm2 and cryptsetup packages lead to non-working initrd very, very soon

I recently almost died from a heart attack because after a really horrible crash (don't ask), Debian unstable on my laptop wouldn't boot anymore. The system hung at "Waiting for root filesystem...", and I was in panic mode as I feared I lost all my data (and as usual my backups were waaay too old).

At first I was suspecting that something actually got erased or mangled due to the crash, either at the dm-crypt layer, or the LVM layer, or the ext3 filesystem on top of those. After various hours of messing with live CDs, cryptsetup, lvm commands (such as pvscan, pvs, vgchange, vgs, vgck) and finally fsck I still had not managed to successfully boot my laptop.

I finally was able to boot by changing the initrd from initrd.img-2.6.30-2-686 to initrd.img-2.6.30-2-686.bak in the GRUB2 menu (at boot-time), at which point it was clear that something was wrong with my current initrd. A bit of debugging and some initrd comparisons revealed the cause:

Both, the cryptsetup and lvm2 packages were no longer installed on my laptop, which made all update-initramfs invokations (e.g. upon kernel package updates) create initrds which did not contain the proper dm-crypt and lvm functionality support. Hence, no booting for me. I only noticed because of the crash, as I usually do not reboot the laptop very often (two or three times per year maybe).

Now, as to why those packages were removed I have absolutely no idea. I did not remove them knowingly, so I suspect some dist-upgrade did it and I didn't notice (but I do carefully check which packages dist-upgrade tries to remove, usually)...

Google Tech Talks: coreboot (aka LinuxBIOS): The Free/Open-Source x86 Firmware

coreboot Google Tech Talk 2

Here's a nice opportunity for everyone to learn more about coreboot, a Free Software / Open Source firmware/BIOS for x86 PCs.

Ron Minnich, founder of the LinuxBIOS (now called coreboot) project, Peter Stuge of Stuge Konsult, and Stefan Reinauer of coresystems GmbH have given a presentation for the Google Tech Talks series recently. The topic was (of course) coreboot, its history, goals, features and technical details, surrounding tools and libraries such as flashrom and libpayload, as well as an automated test system for running a hardware test-suite upon every checkin in the coreboot repository.

coreboot Google Tech Talk 1

A video of the talk, aptly named coreboot (aka LinuxBIOS): The Free/Open-Source x86 Firmware (134 MB), is available from Youtube, get it for instance via:

  $ apt-get install youtube-dl
  $ youtube-dl http://www.youtube.com/watch?v=X72LgcMpM9k

The talk includes various demos of coreboot and various payloads you can use with coreboot. One nice example is the TINT payload, a Tetris-like game for Linux (apt-get install tint for the curious), which has been reworked to be usable as a coreboot payload.

coreboot Google Tech Talk 3

So, yes, you can now put Tetris in your BIOS ROM chip and play it from there (no hard drive required).

Other demos included some cluster nodes with coreboot, and a "normal" x86 desktop board booting coreboot + Linux in a very few seconds (much room left for optimizing there though, if you really want to get into fast booting).

Check out the full talk for more infos, and if you're willing to give it a try (see the list of currently supported boards), contact us on the mailing list or join the #coreboot IRC channel on Freenode.

Falling on your back for fun and profit -- human airbag device

Fun stuff I just stumbled over: a personal/human airbag from Japan, supposedly meant for elderly people who might fall and injure themselves.

Watch a video of the airbag in action on Youtube (no need for crappy Flash player, you can use youtube-dl for instance). Such a device could be a lot of fun I imagine; make it cheap enough and lots of people will buy it just for fun falling-on-your-back experiments :-)

Syndicate content