Keysigning party/Background

A web of trust

A keysigning party is an event where we build the so-called Web of Trust.

Suppose you want to communicate securely with Bob. You download Bob's public key. This presents a problem: how do you know this is really the public key of Bob? Maybe somebody is pretending to be Bob. But after you downloaded the public key of Bob, you notice it has been signed by Alice. Hey, you know Alice! You know Alice is a conscientious person. If Alice is saying that yes, this is Bobs key, you are willing to trust Alice in that and decide to use Bobs key. You've sufficiently proven to yourself that you have the correct key, because you trust Alice.

This is the Web of Trust. Because you trust Alice, you have ascertained the identity of Bob.

Why is it a web? Because if you subsequently trust Bob, knowing you can believe him if he says "I've checked this", you're getting one layer deeper in the webbing of certifications out there.

You tell GnuPG which people you trust, through the ownertrust. You could indicate to GnuPG that you trust Alice and Bob. This is not signing their key, which would indicate you know the key is valid. Rather, ownertrust says that if the key is valid, its signatures can make other keys valid as well. So in my example you would have signed Alice's key, a fact I glossed over. But the fact that you assigned full ownertrust to Alice means that Bob's key becomes valid through Alice's signature. You don't need to sign Bob's key yourself. But since Bob's key is now valid through Alice, the trust assigned to Bob means that Bob's signature can make even more keys valid. A whole bunch of keys can become valid, even though you only signed Alice's key yourself. The web spreads out.

A party to identify other parties

At a keysigning party, people come together and show each other what they think proves their identity. If someone is indeed convinced, they will issue a public statement saying "Yes, this person is indeed who they say they are".

This is not a statement of trust. It does not say "I trust this person to make good decisions". It says "I've seen Alice's proofs of identity, and yes, this is indeed Alice".

Everybody decides for themselves which identities they consider proven and want to sign. Usually, people require one or even more forms of official legal identification. Passports are usually appreciated, and there are people who learn to look for proofs of authenticity for the various models of passports that are out there. Others might not go to such lengths and simply look if the passport seems legit. Usually there is some peering intently at faces with a shy smile, trying to make sure that the person matches the photograph in the passport. They could be boldly trying to present you with someone else's passport!

Taking fingerprints

Deciding whether someone convinced you of their identity is a problem of personal policy. This is in addition to the technical problem of verifying authenticity of their identity papers.

But there is another technical problem of verifying authenticity, and it's one that can be solved by a computer. It's the problem of reliably communicating which key we're talking about anyway. To this end, every OpenPGP public key can be uniquely identified by its fingerprint. This is a 40-digit hexadecimal string; the underlying system is a secure hashing algorithm.

The easiest way of solving this is through keyslips. Everybody prints a whole lot of pieces of paper at home, and hands one of these pieces to each other participant. An example looks like this:

pub  rsa2048/DE500B3E 2009-11-12 [expires: 2017-10-19]             [ESCA]
     Key fingerprint = 8FA9 4E79 AD6A B56E E38C  E5CB AC46 EFE6 DE50 0B3E

uid  Peter Lebbing <peter@digitalbrains.com>

When you are convinced of my identity and wish to share that with the world, you take this paper slip, my keyslip, from me and add it to your stack. Once you get home, you download my key from a keyserver, you manually verify that the 40 digits of fingerprint are correct, and you sign the key.

Some people have all needed information printed on their business card, so they only have to bring their business cards.

This all works fine and dandy, and is all that is needed. However, we can improve one step further. We could create a document that is both human- and computer-readable, holding all fingerprints. This document has a hash of its own, and instead of checking every fingerprint, we mainly just check the hash of the document and then some.

This is all well established and known. However, there is a problem with what is well established and known. To explain, allow me to complain.

A perverse incentive

The method where there is a human- and computer-readable document with everybody's keys requires everybody to submit their key to the organizer before the event. Even worse, it usually requires the list to be sent back to every participant before the congress even starts, so they can print it at home. This is not due to a lack of printers at the congress, but due to a lack of trusted printers. If somebody maliciously alters the printout, this can have dire consequences if not properly accounted for.

But not everybody who wishes to attend the keysigning will have signed up before the congress.

I claim that people who are not on the list can still be full participants without issues. However, this is not what happens in practice. In practice, people who are not on the list are not treated equally to the participants who are.

This is what I say is a perverse incentive brought on by the method with the list. The organizer is incited to treat people not on the list as people not invited to the party.

I want to solve this issue. The easy solution is to forgo the list. But I like that I don't have to verify that many hex digits when I have the list. The keysigning party at the 29C3 had 31 participants. That's 1,240 hex digits to verify! I heard the 30C3 party had 89 participants. 3,560 digits? Argh!

I've proposed a new hybrid form of organizing a keysigning party on the gnupg-users mailing list for feedback. The goal was to get rid of the perverse incentive while retaining the one advantage of the list that I found relevant. I also initially decided to use this hybrid method at the 33C3 keysigning party. However, I got so few signups that I had to forgo this idea and just go with the informal "bring keyslips" method. If you want to read what I had in mind, check the history of these wiki pages and use the versions from before Friday 23 December.

(This text is copyright 2016 Peter Lebbing under the CC-BY-SA 3.0 licence)