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.
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.
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.
In the interim between submitting my key and FOSDEM I started to learn how to
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.
Participants were contacted through the FOSDEM mailing list on Tuesday 28 January to let us know the following:
gpg --list-keys --fingerprint 4825C90A45758A21in my case)
papsprogram to generate PostScript, and
ps2pdfto turn it to PDF.
paps to generate
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 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.
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
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.
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.
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.
caff configuration file is expected to be
$HOME/.caffrc. I placed
the following in mine:
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
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
ln -s ~/.gnupg/gpg.conf ~/.caff/gnupghome/gpg.conf chmod 700 ~/.caff/gnupghome
It is recommended that the following lines are added to
optimal effectiveness of
personal-digest-preferences SHA512 cert-digest-algo SHA512 default-cert-level 2
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
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
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
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.
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
gpg --keyserver pool.sks-keyservers.net --send-key 4825C90A45758A21
Since the keys I was signing were being loaded into my keyring
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.
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.