Episode: 1461
Title: HPR1461: FOSDEM Keysigning Event
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr1461/hpr1461.mp3
Transcribed: 2025-10-18 03:31:19

---

Music
Hello everyone, this is Dave Morris.
Today I wanted to talk to you about an experience I had at the FOSDEM conference in
Brussels, Belgium. That took place on the 1st and 2nd of February 2014 and during the conference
I took part in a key signing event. I wanted to do this partly to see what it was, what it looked
like, how it worked, partly because I knew that the end product would be an improved level of trust
on my GPG key. FOSDEM key signing is a really big event, one of the biggest in Europe, so I thought
it was going to be pretty interesting to attend. I've created a lot of show notes to go along with
this talk in the hopes that it helps to understand what I find, at least to be a pretty complicated
process. I'm maybe not going to cover everything that's in the notes because I was going to end up
reading them to you, which is probably not a good idea. Anyway, let me just explain a little bit
about what a key signing party is. It's an event where a number of people present the details of
their public keys, PGPGPG or whatever, along with the proof of identity, and they do this to
other participants so that they can be checked. Now, actually, signing takes place at this event,
since if people were there signing keys, there would be a terrible temptation for
nasty people to come along and try and hack their machines or very least shoulder serve there.
They're pass phrases, but the participants take away a list of participants and the fact that
they check them and see their IDs and so forth so that they can go home and sign the keys.
The overall purpose is so that the decentralized web of trust, that is one of the consequences
of using these types of keys, is enhanced. I'm not going to go into details of the web
trust. I put a few pointers to further reading on this, and I imagine that a hooker will be
maybe looking at this in the future. So before I set off to FOSDEM, before I got ready for the key
signing, I obviously need to have a GPG key, which I had because I've been using it to sign an
encrypt mail for a while, a few years actually. They're only really messing around with it until
fairly recently. So having got this key, I thought rather than create a new one, I'd just use this one
for the purpose. If you want to know more about how to create your own key, then have a listen to
a hooker's shows which I've indexed from from my notes. I'm sure you'll be able to find them
otherwise. So given that I had a key, the first thing I needed to do was to submit it to the FOSDEM
key server, where all of the participants' keys were being collected, and I've given the command
to do that in my notes. The key submission was available from the point of announcement
in 2013 all the way up until Monday the 27th of January 2014. Since I was learning more about
GPG and keys and stuff, I did end up fiddling around with my key after I'd submitted it.
In particular, I was using KGPG and found that it was easy to add a photo ID to my key,
which I thought was obviously a good thing to do. I thought I did that, and this has a certain
relevance to what happened later on in the story. So close to the time where the event was to take
place, the participants were contacted, and we were asked to do various things. First of all,
there was a list of all the participants available on the FOSDEM website. There were 280 keys in
this in total. That was a larger number than the number of people, because some people submitted
multiple keys. We had to check that our entry in this list, the key fingerprint that was presented
there was correct, and we also had to download and print this list so that we could bring it along
with us to the event. We had to do this in a particular way, which I must admit was a bit new to me,
using a tool called PAPS, perhaps I assume it is, because it contains UTF8 data. Very little
else will do this, apparently. It was possible to go via latech and print out any photo IDs,
but I didn't do this because I wasn't clear that it would actually work for me. I've not managed
to get it to work since actually. We were asked also to generate check sums for the participant file
and write these down on the front of the sheet, and this was so we could check that there'd been no
tampering with the file between us picking your dashboard, being sent from the site or whatever,
and getting to the event, and obviously we had to bring an ID with us and a pen. I decided to bring
my passport with me as my ID. So the key signing event took place on Sunday, the 2nd of February,
2 in the afternoon, and it was a large number of people gathered there, but it transpired later on
that there were a fair number of no-shows, a number of people who submitted but never arrived.
It started by the organizer calling out the check sums for the list file, the participant list,
which we then needed to check. Then we were asked to order ourselves by submission number. There
was a number against our entry in the participant list. We were asked to arrange ourselves in order of
that number, and then the line wrapped around such that number one, face number 140, and so on,
down the line. Then we began the process of checking our opposite numbers, documents, and filling
in the sheet. So in order to carry out a check, we first of all had to find out what the number of
person we were talking to, so we looked them up on the sheet. We had to ask them to confirm that
they were happy that the document check sum matched with what the organizer had read out. We had
to check that they were happy with the key fingerprint in the document, and then we had to look at
their passport or driving license to check against the details on the paper, the name, and so forth,
check that the pictures match, check that they were valid documents as well, I guess.
If everything checked out okay, we ticked the two boxes on the form against that person. In fact,
some cases there were multiple entries, which we also had to check. Then we moved one step to the
right and carried on. So this line was wrapping around at the far end as well. What we were actually
doing here then was collecting details of our verifications so that we could do the real key
signing when we got home, put a couple of pictures of my friend took at the event so you can
get some idea of what it looked like. So it took in the region by coincidence, it took me two hours
to check 100 keys, and everybody else, I guess, the same sort of rate. This didn't fit in with what
was estimated to start with. It should have been one hour per 100 checks, but the actual process
of checking seemed to be a lot slower than perhaps it should have been. Different people seem to be
much quicker or much slower than others. They tended to be big gaps between participants, so we'd
be standing there waiting for somebody to make the way down the line. In some cases people tried
to skip past the slow people who were making these gaps, but then that got really chaotic because
all of a sudden from thinking that you could work your way through the list sequentially,
suddenly had to fumble about and find number 200 and something after you'd just been dealing with
number 50 something, and that got really chaotic. So I think that was one of the, there was
some of the reasons why things went slowly. Some people were very meticulous about doing the
checks one guy, brought a UV torch and spent some time looking through my passport, and
I was surprised the number of people who pointed out that my passport would need renewal in a few
months, so they were obviously reading everything on it. Now I wasn't able to stay to the end of this
because I had a plane to catch, so after two hours I had to leave. I suspect that there were a lot
of other people leaving earlier than was ideal. I don't think everybody signed everybody's key.
So the next thing to do was to do the key signing homework as they called it.
I found that I started receiving emails from people before the conference had even ended on
at 6 p.m. on the Sunday, so at the time I got home the next day I started processing these and
getting ready to do this homework. Again, I don't know why in particular I chose this point to do it,
but I thought having seen how other people had organized their GPG keys that I should reorganize
mine a bit, I'd actually created two keys. There was one I was using for email and another one that
was anticipating another email address I was setting up for myself. I noticed that a lot of people
had just the one key with multiple UIDs and emails on them and I thought well the best thing to do
would be to merge the two together. So I revoked my alternate key and added the email addresses
as a secondary UID to the main key. I won't go into detail about how I did this, though
I can't do if anybody's interested. This was maybe a bad decision at this particular point,
there you go. So the first thing I did was to import the signatures that I started to receive
through the means of email. The messages I got were encrypted messages with a message body
describing that this was a key signing message with some instructions in it and one or more
attachments on email. I used Thunderbird with an e-mail to do my GPG stuff and I found that once I'd
opened the email with my past phrase I could right click an attachment and import the signed key
into my key ring and this went pretty well. There's a picture of what the email looks like,
suitably anonymized. Not sure quite why it needs to be anonymized but I thought it might be
more polite to do that. I found that when there was a single attachment this was a signature against
my main email address, not too surprisingly. Sometimes I received two attachments and the other
one was a signature against my photo ID. So people had actually gone to the trouble of checking
that the photo in my key actually matched me and was signing it. In some cases I received two
email messages and this was because the second signature, the second email address I'd added to the
key was also getting a signature which strictly they shouldn't have done I guess but I think the
tool they were using offers you the choice whether to do it or not and people have maybe thought
oh well why not and they haven't checked against the list to see that that key hadn't that email
address that your ID hadn't been presented at the time. So once I got my head round importing the
keys the signatures that I would that have been the signed keys what I'm trying to say. Then
next thing to do was to try and do my signing for the people I'd checked. So looking at the
various information that the FOSDAM website offered I reckoned that the tool called CAF, C-A-F-F
was probably the way to go. This is part of the signing party package which is available on
Ubuntu and other APT based systems. So I installed this on my Ubuntu system.
CAF is a script that can sign a bunch of keys at a time. It has a configuration file and
requires access to your GPG configuration. It also sends out emails directly through a local MTA
so you need to be running your own mail server. I was but I hadn't configured it to do anything
very much so I had to spend some time configuring post-fix to relay through Gmail. In the show notes
I've shown details of how you set up the .caf, C file which is a necessary prerequisite. I won't
explain that in too much detail now. There's loads of information on the man page and the links that
I've pointed to in the notes. The script also needs a directory to store the keys that it's
working on. You can also, and it's recommended that you do this, set up a copy of the gpg.conf file
and use that as part of the process. One suggestion was that you link it to the actual gpg.conf
which is what I did. It's in the show notes how I did this. There are a bunch of additions
that should be made to the config file to streamline this whole process. There I was with
a hundred keys to sign. I didn't want to be typing these in one at a time so I wanted to automate
this process as much as I could. I created a file with the numbers of the participants whose keys I
checked, whose details I checked, IDs and so on, into this file, one number per line. I then wrote
a little script which, called collect keys, which would look up participant numbers in the list and
return their keys. There's a copy of it in the notes. It's quite trivial. So I was then able to
run this script with the numbers file and generate a list of keys. Then I ran these keys in batches
through the CAF program. Now the reason I did it in batches was because I wanted to check
each key against the list. The easiest thing to do is to take a page's worth however many
there were on a page and simply push this through CAF. So there's some details in the notes about
how I did this. When I'd processed a batch of keys, the example shows seven being processed.
Then I had another little pipeline which added a hash to the front of each key so that I wouldn't
process them again. Remember I'm going to detail them so you'll be able to work out what I was doing
there. It's no, not really a big deal. So the only slight disadvantage to doing them in batches
was that each batch needed me to enter my passphrase unless I was doing them rapidly one after the
other and I didn't do that. It took me two or three days to get through them all. So as a follow-up,
I, first of all, followed the recommendation which was to ensure that my now modified key
from the signatures that have been coming in was going up to a public key server so that people could
check against it and see their signatures on it. I think also the frauds and people want to do
statistics on the uptake of these signatures. I did that and it shows how to do it in my show notes.
So it was, I also found it interesting to monitor the keys that I was signing
after a day or two. There's an example of a command which will refresh these keys
make sure there are copies in my, they're already work copies in my queuing. So it's just refreshing
them and that let me see when the people who received the emails had applied them. I would
start it doing that because I wanted to be 100% certain. What I was doing was actually working
and as soon as I saw somebody was, the first person was actually attaching the signatures then
and knew that at least I'd got something that was working. Occasionally I refreshed my own key
by pulling a copy down off the server and that was because some people were not using care for
an equivalent tool to do it. They were just signing it directly. They'd taken a copy of it,
they'd signed it locally, they'd uploaded it and so if I hadn't done that I would have not noticed
the changes being made. So as of the time I'm recording this, which is now two weeks after
the signing event, 43 of the people, of the 100 people whose keys I signed have signed my key and so
it's pretty good. We've got until I think sometime in June to do them all. So things are going
quite well I think. I'll finish off by just giving a few thoughts and impressions about what
happened. I certainly found this to be a fascinating process. It gave me a much closer understanding
of what was going on here, though I'd certainly go a long way to go to fully understand this.
My key is a high level of trust associated with it and it's also part of the way of trust
as I mentioned before. I thought the logistics of the whole process were generally quite well handled
but with a large number of participants, 200 plus, it's not surprising that things got a little bit
confusing. I wrote to the organiser with a few comments and I'd heard other people making similar
comments and he's obviously taking these on board because he's updated the website with many of
the suggestions he's had in. So a few of the things that were commented about were if you got
everybody to wear a badge of some sort with their number on it, it would save some time. You could
look them up much more rapidly without having to ask them for their number and also if they put
on their responses to the questions about the checks on the document and whether they check
their fingerprint that would speed things up. It would be good if we were told about how the process
would actually happen, how the key signing party would take place as we were completely ignorant of
the process before it started. So that's already happened. He's put more details of that
up on the site and for my own point of view I'd quite have appreciated if we'd been somewhere
where there was some better lighting. It was fairly gloomy in that corridor that we were in and I
certainly found it quite hard to read my printout and some people's ideas various times. Be
tempted to take your head to watch something next time if that doesn't happen. So just one other
thought is that a lot of comments about GPG and similar things recommend that you don't use
the shortened version of the key but the full version is preferable because there could be
collisions with the short form. You could type in a short form key and hit because it's just the
last half of the full thing. You could have a collision with the wrong key. I certainly tried to
use the full key whenever I could but the list that we were given had the short form so it might
be a good idea if the list next year has the long form. So that's it. Thanks. Bye.
You have been listening to Hacker Public Radio at Hacker Public Radio.
We are a community podcast network that releases shows every weekday on day through Friday. Today's
show, like all our shows, was contributed by an HPR listener like yourself. If you ever consider
recording a podcast then visit our website to find out how easy it really is. Hacker Public Radio
was founded by the Digital Dark Pound and the International Computer Club. HPR is funded by
the Binary Revolution at binref.com. All binref projects are crowd-sponsored by linear pages.
From shared hosting to custom private clouds, go to lunarpages.com for all your hosting needs.
Unless otherwise stasis, today's show is released under a creative comments,
attribution, share a life, and it does our license.