Willkommen bei bytebang » The blog about all and nothing » How a keysigning party builds a web of trust

How a keysigning party builds a web of trust

Mai 17 2016

The Problem

Last month I attended a key-signing party at the Linuxtage in Graz. While I was pretty aware that key-signing is a great tool to prove your own identity against unknown third parties, I was not prepared what comes after the party. Here is a short write up, of what to expect from such an event and what has to be done after it. I try to keep it in a simple language, without too many technical details to give everybody the chance to understand what this is all about.


So lets start with the ingredients. The keys that we are talking about are used to encrypt or sign data. There is a variety of software which serves exactly this purpose, but within this article I am focusing on GPG (Gnu Privacy Guard) which "allows to encrypt and sign your data and communication, features a versatile key management system as well as access modules for all kinds of public key directories". It is available for nearly every operating system and it is a building block of Enigmail "which is a seamlessly integrated security add-on for Mozilla Thunderbird." It allows you to use OpenPGP to encrypt and digitally sign your emails and to decrypt and verify messages you receive.

Crypto 101

The keys that we are talking about are used to encrypt or sign data. Encryption means that you somehow "scramble" plain text (which can be read by everyone) into cipher text - which can only be read if you are able to "unscramble" the cipher text. Lets have a look at an example:

echo "Hello bytebang" | gpg --encrypt -r 42F9628A --armor
Version: GnuPG v1


WTF happened here ? ... I piped the string "Hello bytebang" into gpg. The parameters are telling the tool to encrypt it with a key named 42F9628A, and to print in in a way that only contains ASCII characters (and not unprintable ones which can not be printed etc.)

And what does that mean ? ... The output of the tool (everything starting from the BEGIN PGP MESSAGE till the end) is actually the scrambled cipher text. So if you hand that text over to me then I can decode it into "Hello bytebang" again.

What prevents others of descrambling (decrypting) my message ? ... This is where all the fancy crypto stuff jumps in. I don't want to explain that in depth, because it would not fit into one article (others are writing books that are covering only this topic) - but to give you an idea: In the end it boils down to the fact that while it is easy to calculate the product of two large prime numbers (particularly with the help of a computer) it is, for all practical purposes, impossible to find the factors of a large number if it has only very large prime factors. This is because all methods of finding such factors would take many many thousands of years by even the fastest modern computers.


However. Lets have a closer look at the things needed to perform encryption. It is important to understand that there are two types of keys which are somehow (cryptographically) connected to each other. You can imagine them as a key pair which can lock and unlock the same padlock. Both keys are not physical keys as such, but long colons of numbers which are somehow related.

The public key is a publicly available key which allows the users only to create encrypted files - like i did in the example above, with my public key 42F9628A. The private key is the opposite of it: It can only decrypt messages, and has therefore be to keept private - where private is an expandable term which ranges from USB sticks up to specialised crypto devices or smart cards.

So if you create your own private / public keypair then it is important to keep the private key as private and protected as possible (so that only you know where to find it, and therefore only you are able to decrypt messages) and to spread out the public key into the internet to enable other users to create encrypted messages for you.In general you want to upload you public key onto a key server which can be seen as a kind of "phonebook for public keys". 

Asymetric encryption

Lets visualize that once again:


Bob wants to send Alice an encrypted message "Hello Alice". Therefore it encrypts this message with her public key (which he most probably fetched from a key server). Doing so enables only Alice to decrypt it. The encrypted message (6EB69...) can then be sent over any potentially insecure medium like email, chat or whatever. As soon as Alice gets the message she pulls out her private key to encrypt the message. That's it!

Web of trust

The alert listener might ask: "Ok, but from where does Bob know that the key that he found on the internet is really the public key from Alice, and not the public key of somebody who pretends to be Alice ?" ... The short answer is: He can't know it. All he has is the public key from a key-server. He can not tell from the key itself, that this is not a key which is made by Mallory (the evil sister of Alice, who wants to steal her encrypted messages by uploading keys to key servers which look like Alice's keys, but who's only purpose it is to trick people to use the wrong public key for encryption). This is exactly where key signing or crypto parties come into the game.

Lets assume that Person A knows Person B and B knows C. Then we can say that A indirectly knows C. If we think a step further that C might know other persons as well then we can say that A can trust on the fact the the friends of C are really existing persons. This is called a web of trust. Everybody inside this web can trust the others either directly (because he has meet them on a key signing party) or indirectly (because one of the people he met on the key signing party knows them directly or indirectly).


Party hard !

At key signing parties the attending people are are verifying, that their public key belongs to them. Therefore the attendees have to bring (a) their public key and (b) a kind of legitimation like a id card, a driver license or a passport. This acts as a proof that the person who shows you the key is really the person that owns the key. The exact perquisites are often listed on the hosts web page.

Here is how it ran down at Linuxtage 2016:

  1. Everybody meets in a quiet corner of the building, equipped with his own public key and a passport, driver license or whatever should be used as legitimation.
  2. The ceremony master introduces himself and explains what to do. He hands out a bunch of papers where the fingerprints of the attendees public keys are written on. Lets call it a 'key-list'. This list eliminates the step to write down each others public key.
  3. Since the ceremony master *might* be evil and therefore he *might* try to hand out different copies of the key-list, everybody had to read out his own public key fingerprint loud to all the others. The others where verifying the read key with the one on their key-list.

Now we ended up with a list of all the public keys of the attendees. The next step was to verify the identity of each other:


While the right side of the column is showing their id card, the others where taking notes on their key-list to keep track of the id's they have seen and verified.In the end everybody went home with a list of public keys that have been verified, and that's it. As I arrived at home I asked myself: But what do I have to do next ?

The homework

I knew that I somehow had to sign these keys from my key-list. After a short research I developed a short script that exactly does this:

gpg --recv-keys $1
gpg --fingerprint $1
gpg --sign-key $1
gpg --send-key $1

As parameter it takes the public key fingerprint from the list. Then it downloads the key, fingerprints it (which gives you the chance to verify the key again), it signs it with you public key and finally it uploads the key to the key server again.

Not every user wants his keys to be uploaded to a public key server. So please respect this and comment the last line for these users out and send them the resulting key per mail.

This worked really well, but I did not know if the other attendees have already signed my key. This can be visualized by a small script found here. It visualizes you personal graph as image like this:


It requires that gpg, sig2dot.pl, and neato (part of graphviz) be in your path, and that you have a keyserver set in your ~/.gnupg/options file. If you don't want to do this, then you can still use pages like the PGP pathfinder.


Attending a key signing party is really an interesting event - especially if it is your first one. Instead of drinks and snacks you find a lot of other people mumbling endless columns of hex-numbers  which ultimately leads to the point where they show each others id cards before they are going home again. All that in the name of trust! I have been to a lot of party events, but this one was for sure the most complicated to explain to my parents ;-)

If you join such a party then you can "sign" the public key of other persons with your private key. A signed key means "I know this person - or I have seen at least one valid document that acted as proof that the key belongs to this person.". At the moment where you have signed the key you express that you are trusting the other person, and at the moment where you upload the signed public key to the key-server again you are telling the other users of the GPG ecosystem that you are trusting this person.

It can be the case that you are trusting a person, but he/she does not trust you - which is also OK, but in general you want that all your persons to trust you, because it makes you a valuable member in the web of trust. Don't be forced to trust everybody you see. If there is something suspicious then it is better not to sign the public key of the other person.

I hope that this article was (at least a little) useful for all the following crypto users !

Get Social

(c) 2019, by bytebang e.U. - Impressum - Datenschutz / Nutzungsbedingungen