What attacks do key signing parties make harder?

What the web says

Obviously before trying to come up with my own solution to these problems, I searched the web to see what other people had written. I did manage to find one page which gave some little scenarios, but I felt they didn’t justify every facet of the process. For consistency with my own scenarios, I will present here these scenarios I found, but in my own style.

• Alice and Bob meet for the first time
• Alice and Bob want to talk securely in future
• Alice and Bob exchange keyslips
• Alice and Bob later sign each others’ keys
• Alice and Bob meet Cathy, but Cathy doesn’t have a keyslip with her
• Cathy tells Alice and Bob that she will email both of them her key later
• Alice creates an email account and generates a key with Cathy’s name and the new email address in it
• Cathy creates an email account and generates a key with Cathy’s name and the new email address in it
• Alice and Cathy send emails to Bob containing their new keys which he hasn’t seen before
• Bob doesn’t know which key is really from Cathy

Implicit in this scenario is that there is alternative situation in which Bob could work out, with some confidence, which key was Cathy’s. What is necessary is for Cathy to have previously taken part in other key signing parties where people checked that the name on her keyslip was the one she used to introduce herself. Cathy’s key would then have lots of signatures on it, attesting to the fact that it belonged to someone called Cathy, which is the name she had given when she met Bob. Alice’s fake key, however, would not have these signatures, unless she had spent some time using a fake identity of “Cathy” at key signing parties to get signatures on her fake Cathy key. In this precise situation, where Alice only meets Cathy at the same time as Cathy meets Bob, it is unlikely that Alice would be able to construct such a seemingly trustworthy key in time to fool Bob.

Taking this scenario one hypothetical step further, there is the potential problem of stalker Alice going around calling herself Cathy (having previously met and become obsessed with Cathy) and building up a key that has lots of signatures on it, so that when Cathy introduces herself to Bob, Alice can overhear his email address and send him her fake key at the same time as Cathy. Perhaps Alice can even block Cathy’s out-going email, without Cathy’s knowledge, in which case Bob would have a difficult time realising that anything was wrong. However, if “Cathy” was Cathy’s legal name (or perhaps a name suitably connected to her legal name), then by demanding that some form of legal identification was presented before a signature is given, it would be that much harder for Alice to generate a believable fake key. Of course, Alice could get her legal name changed, but this might make people suspicious and make it easier for her to get caught.

The second scenario given on the web page I found went like this:

• Alice and Bob have met, exchanged keyslips, and signed each others’ keys
• Cathy knows Alice and Bob’s email addresses
• Cathy generates a new key containing Alice’s name and email address
• Cathy forges an email to Bob from Alice, containing this new key and claiming that this is Alice’s new key
• Bob does not trust this “new” key because it has not been signed by anyone else

It is true that Bob could reject the fake key based on the fact that it hasn’t been signed by anyone, just like in the previous example where he rejected the key that Alice made which was supposedly Cathy’s. However, if Alice actually did want to send a “here is my new key” message then regardless of which email address she used and how many signatures it had, as long as it was signed by her old key, then Bob should trust it. This scenario, then, is perhaps less helpful for understanding the issues involved.

What I say

To understand some of the cases which the above scenarios don’t deal with, I have come up with some scenarios of my own which I present and analyse below.

• Bob and Carol meet in person
• Carol and Bob exchange names and email addresses (Alice sees this)
• (Assume that emails between the two can be intercepted and blocked by Alice, and that she can forge unencrypted emails from either of them)
• Carol tries to send an unsigned email to Bob with her key attached, but it is blocked by Alice
• Alice forges an email from Carol’s address, uses Carol’s name and attaches a fake key
• Alice receives emails sent to Carol’s address and blocks them

This is effectively the Man in the Middle attack for emails, and shows that a key should not be trusted just because it arrives from someone whose name and email address you recognise. The first thing to point out here is that if Bob and Carol had exchanged keyslips when they exchanged names, then they would not have had to send keys to each other using email. Alternatively they could have looked up each others’ keys on a keyserver using the names and email addresses they knew as search terms. This is vulnerable to the same attacks as mentioned before, in terms of Alice impersonating Carol in various ways.

• Bob and Carol meet in person
• Carol introduces herself to Bob using her nickname (which doesn’t appear in her key and isn’t based on her name)
• Optionally Carol also gives Bob her email address
• Alice sees the whole conversation between Bob and Carol
• Alice performs the same attack as in the last example, except she can say “I told you my nickname, but my real name is Alice”

Although the technology of the attack is the same as last time, social aspects are easier if Carol uses a nickname. Assuming there is no government-issued ID for nicknames, Carol cannot prove (and so Alice does not need to prove) that the key she generates is associated with Carol’s nickname. Alice’s key may have been signed by hundreds of people who have checked that her legal name really is Alice, but Bob would have to ignore all those signatures on Alice’s key when working out whether the email he received was from Carol (whose real name he doesn’t know). As such, the signatures on Carol’s key, even if it reached Bob in an email, would be worthless, and so key signing parties would have been pointless for Carol. If instead of a nickname Carol had given Bob a keyslip, then the key signing parties Carol had attended would again have been pointless, as Bob wouldn’t need to check the signatures to trust the key he was given effectively by hand.

What GPG says

It is perhaps useful at this point to see how the technology was designed to be used by the people who implemented it. The gpg program contains instructions to help you when you are recording how carefully you have checked the identity of the person whose key you are signing, and those instructions, with the various options you can choose, are below:

Your selection? (enter `?’ for more information): ?

If you don’t know what the right answer is, answer “0”.

The fact that each individual user of the program has to decide what the numbers 2 and 3 mean would suggest that they are of little practical value, but presumably they are useful at least among certain groups of users who share a common policy. Perhaps one day the software will become easier to use, and the ideas will become easier to explain, so that casual users can at least get some of the privacy benefit available to more advanced users.

That just leaves one question. What do you do when a stranger stops you in the street and gives you a keyslip, and then leaves before you can ask any questions?