FOSDEM Keysigning Event

Dave Morriss
2014-02-17

Introduction

I attended FOSDEM 2014 in Brussels, Belgium on the first and second of February 2014, and during the conference I took part in the key signing event.

I wanted to do this partly to see what such an event looked like, and partly to enhance the level of trust associated with my key.

The FOSDEM key signing is billed as one of the largest, so I thought it must be worth seeing.

Purpose

A key signing party is an event where a number of people present details of their PGP or GPG public keys along with a proof identity to other participants for checking. No actual signing is carried out at the party since this would be a great attraction to nefarious people who wanted to attack the equipment being used or steal passphrases, but the key information allows participants to complete the signing process when they are back home.

The purpose of the key signing party is to assist with the building of a de-centralised web of trust.

Preparation

Submitting my key

I had created a GPG key some time ago and had been using it to sign and encrypt email, so I decided to use this one for the key signing party.

If you want to know how to do this listen to Ahuka's shows on the subject: Generating Keys on the Command Line and Creating a Key Pair - GUI Client.

In order to participate in the key signing I needed to submit my key to the FOSDEM key server at ksp.fosdem.org. This was done with the command:

  gpg --keyserver ksp.fosdem.org --send-key 4825C90A45758A21

Key submission was closed on Monday, 27 January 2014 in preparation for the event.

Doing things to my key

In the interim between submitting my key and FOSDEM I started to learn how to use the gpg command and the KDE GUI tool KGpg. In this I found the ability to add a photo id to my key, and so I enhanced my key with this feature. This is slightly relevant later in my story.

Preparing the list of participants

Participants were contacted through the FOSDEM mailing list on Tuesday 28 January to let us know the following:

Running paps to generate ksp-fosdem2014.pdf:

  paps --header --landscape --columns=2 --font="Courier 7" --top-margin=25 --bottom-margin=18 ksp-fosdem2014.txt > ksp-fosdem2014.ps
  ps2pdf ksp-fosdem2014.ps

The Keysigning Party

The key signing event took place at 14:00 on the Sunday. A large number of people gathered in the designated area. It transpired that of the 280 key IDs in the list (which didn't directly correspond to people since some had submitted multiple keys), there were several people who did not show up.

To start with, the organiser (Niels Laukens) called out the two checksums for the participant list file, which we had been asked to compute in advance. We all needed to be sure that we agreed on these sequences before trusting the list.

Then we were asked to order ourselves by submission number, and the line then folded so that number 1 faced number 140 and so on. We then proceeded to check the identification documents of the people we were facing and move one person to our right.

The check consisted of the following steps:

If everything checked out we marked the paper appropriately and moved on. There was no actual signing during the event. What we were doing was collecting details of our verifications so that we could complete the process at home.

Images courtesy of Tom Kane

It took me in the region of two hours to check 100 keys. This did not fit with the organiser's estimate of one hour per 100 checks. The actual process was a lot slower - possibly due to the differential speed of the participants. There tended to be some large delays between participants at some points. Some people tried to skip past the slower ones, but this led to chaos as the sequence was broken, making it more difficult to find the right page.

I was impressed that one guy had brought a UV torch and spent some time hunting through my passport for a watermark! I was also impressed that several people pointed out that my passport needed renewal in a few months - many were obviously checking very meticulously!

I had a plane to catch in the evening, so I felt I could not stay to the end and left after two hours. It seemed that a lot of other people left before the end as well.

Keysigning Homework

Before the FOSDEM conference had ended at 6pm on the Sunday evening I started to receive emails from people who had begun the actual key signing process.

The next day after I had arrived home I began to set things up to do my homework.

Before doing this I decided to do some further key management. At this point I had two GPG keys. However, I had only submitted one for the key signing party. Having seen that many people had multiple UIDs and email addresses associated with one key I decided to revoke my other key and add the email address as a secondary UID to my main key. I did this using the gpg command.

Importing Signatures

Since I had already received emails from people who had signed my key I first found out how to incorporate these signatures.

The messages I received were encrypted and consisted of a message body describing that this was a key signing message, with one or more attachments.

I use Thunderbird as my mail client and have installed the Enigmail plug-in. I found that I could right-click an attachment and select the menu option Import OpenPGP Key.

When there was a single attachment this was a signature against my main email address. In the cases where I received two attachments the other one was a signature against my photo id.

In some cases I received two email messages. This was because a second signature was being generated against additional email address I had recently added to the key. I had not expected this when I added this UID to the key.

Signing Keys

Next I needed to sign the keys I had checked.

I noticed from the emails I had received and from hints on the FOSDEM mailing list and website that the caff tool was probably the way to go. I installed the signing-party package on my Kubuntu system.

Setting up caff

caff is a script that can sign one or more keys at a time. It uses a configuration file of its own and requires access to your gpg configuration file. It sends out mail messages through a local MTA so it is necessary to be running your own mail server.

I set up the Postfix MTA that was running on my system to use smtp.gmail.com as a mail relay.

The caff configuration file is expected to be $HOME/.caffrc. I placed the following in mine:

1
2
3
4
5
6
7
# .caffrc -- vim:ft=perl:
# # This file is in perl(1) format - see caff(1) for details.

$CONFIG{'owner'} = q{Dave Morriss};
$CONFIG{'email'} = q{Dave.Morriss@gmail.com};
$CONFIG{'keyid'} = [ qw{4825C90A45758A21} ];
$CONFIG{'gpg-sign-args'} = 'save';

See the caff manpage for details.

The script also requires a place to store the keys it has worked on, and so on:

  $HOME/.caff/keys/yyyy-mm-dd/  -  processed keys
  $HOME/.caff/gnupghome/  -  caff's working dir for gpg
  $HOME/.caff/gnupghome/gpg.conf  -  gpg configuration

The gpg.conf file is best replaced with a link to the gpg configuration as shown below, making sure that the gnupghome directory is set to the correct permissions:

  ln -s ~/.gnupg/gpg.conf ~/.caff/gnupghome/gpg.conf
  chmod 700 ~/.caff/gnupghome

It is recommended that the following lines are added to gpg.conf for optimal effectiveness of caff (and gpg):

  personal-digest-preferences SHA512
  cert-digest-algo SHA512
  default-cert-level 2

Running caff

Given that I had 100 keys to sign, I wanted to automate this process as much as possible. I created a file numbers.txt, one number per line, containing the numbers of the participants in the list ksp-fosdem2014.txt whose credentials I had checked.

I wrote a script which I called collect_keys which would look up participant numbers in the list and return their keys id. This script is shown below:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
#!/bin/bash - 
#===============================================================================
#
#         FILE: collect_keys
#
#        USAGE: ./collect_keys 
#
#  DESCRIPTION: Collects GPG keys from the FOSDEM keysigning file and writes
#               them to STDOUT
#
#      OPTIONS: ---
# REQUIREMENTS: ---
#         BUGS: ---
#        NOTES: ---
#       AUTHOR: Dave Morriss (djm), Dave.Morriss@gmail.com
#      CREATED: 2014-02-05 16:12:30
#     REVISION: 2014-02-06 17:58:38
#
#===============================================================================

set -o nounset                              # Treat unset variables as an error

BASEDIR="$HOME/GPG"
KSPFILE="$BASEDIR/ksp-fosdem2014.txt"

while read TARGET
do
    if [[ $TARGET == "" ]]; then
        break
    fi

    SKEY=$(egrep -A1 "^$(printf "%03d" $TARGET)" $KSPFILE | tail -1 |\
        cut -f2 -d'/' | cut -f1 -d' ')

    echo $SKEY
done

exit

# vim: syntax=sh:ts=8:sw=4:ai:et:tw=78:fo=tcrqn21

I could then run the script to generate a file of key IDs thus:

  ./collect_keys < numbers.txt > keylist.txt

Batches of key IDs were processed (one printout page's worth at a time to simplify checking). I decided to mark the key IDs that had been processed in keylist.txt with a # in front, so therefore the key IDs for processing didn't have this mark. The chosen key IDs were saved in the file keys-signed.txt. The list was reversed since caff seems to go through its argument list in reverse.

The example below takes the next 7 unprocessed key IDs and runs them through caff. The script is run with the -m yes option which causes caff to send mail to each uid associated with the key:

  caff -m yes $(grep -v "^#" keylist.txt | head -7 | tee keys-signed.txt | tac)

Each batch of key IDs, held in keys-signed.txt was used to add # marks to the keylist.txt file so that they would not be processed in the next batch.

  for k in $(cat keys-signed.txt); do sed -i.BAK -e "s/^$k/#$k/" keylist.txt; done

Running caff with batches of key IDs allowed me to check each one on the printout as it was signed. For each batch gpg required me to enter my passphrase, which could be seen as a disadvantage. However, I preferred to be cautious about what I was doing.

Follow-up

I used KGpg to look at my key so I could check the new signatures I had added. I also ensured that I uploaded my key when it changed with the following command:

  gpg --keyserver pool.sks-keyservers.net --send-key 4825C90A45758A21

Since the keys I was signing were being loaded into my keyring KGpg also showed these. I found it interesting to refresh these keys so I could see when the owners added my signature to them.

I did this by running the following command about once a day:

  gpg --refresh-keys $(grep '^#' keylist.txt | sed -e 's/#//')

I did it this way because I ran the signing batches fairly infrequently over the course of three days and did not want to refresh the keys I had not signed.

I also occasionally refreshed my own key:

  gpg --refresh-keys 4825C90A45758A21

Apparently, some of the people signing my key did not use caff or an equivalent but signed a copy of my key directly and uploaded it.

As of the time of recording (two weeks after the signing event) 43 of the participants have signed my key by whatever means.

Thoughts and Impressions

This was a fascinating and worthwhile process. I have wanted to be involved in key signing ever since I found out about the idea. The exercise has helped me understand more about the whole subject and I now have a more trusted key and my key is part of the web of trust.

The logistics of the process were generally well handled, but with such a large number of participants it's not surprising that things went slowly.

I wrote to the organiser with a few comments, which I am sure were echoed by others. He has updated the website with many of these suggestions.

I think the key signing party could have been improved by:

As I have read more about the use of Gnu Privacy Guard and related tools I have received the impression that using the shortened version of a key ID is potentially more error-prone that the full version. There is more likelihood of a collision with the short form.

Perhaps the participant list for next year's event should use the long-form key ID.

Links