So I’m running the Warsaw Cryptoparty for a few months. one of the most important parts of each such meeting is, of course, explaining GPG/PGP. Which, as should be obvious to anybody who ever tried explaining it to non-tech users, is a highly non-trivial task.

Once you start digging into private and public keys, need to spread public keys but keep private ones, well, private; keysigning; and all the rest of highly technical and often counter-intuitive issues around it, the user either slumps into slumber, or loses track (and therefore intrest) entirely.

There must be a better way, right?¶

Well, how about we completely invert the way we explain GPG/PGP. Instead of starting off in technicalities and moving towards the user-space, as we used to do – maybe we should start with something familiar, something that offers users an easy and intuitive graps of the basics, and then, step by step, move towards the technicalities when and if needed?

So, we need an easy-to-grasp, yet fitting metaphore that would allow us to hook-into users’ existing intuitions and at the same time not cause them to pick up bad crypto habits.

It’s all just numbers, right?¶

This is my GPG/PGP key fingerprint:
07FD 0DA1 72D3 FC66 B910 341C 5337 E3B7 60DE C17F

I have it printed on my business card, for example. This is enough to download my public key from a keyserver, verify it, verify an e-mail signature, and to get my e-mail address or jabber ID from therein. But I don’t want to explain all this to a user that just got my business card.

Instead, I can just say:
Think about it as if it was my Information Account Number. You can use this number to send an encrypted, secure message to me, via any channel you wish (for example, e-mail). Also, if you see a message signed by this key, you can be certain it is from me.

This instantly rings a bell with anybody who used a bank account number to move around money. And it works. Think about it:

• Whose account number you need to transfer them some money? The addressee’s.
• Whose account number you check to be sure where the transfer came from? The sender’s.

And in GPG/PGP:

• Whose fingerprint (and hence, public key) you need to encrypt message to somebody? The addressee’s.
• Whose fingerprint you check to verify the origin of a signed message? The sender’s.

Additionally, the user can then use any GPG/PGP supporting software (e-mail client, jabber/XMPP client, some newfangled Facebook interface even) to send me an encrypted message and read an encrypted message that I would send to them. From users’ perspective the channel is not that relevant really, or at least doesn’t have to be.

All the technicalities and complication can be now effectively hidden by the software.

Ah, software, so that’s the catch!¶

Well, not really. The only things software (e.g. an e-mail client) needs to implement for this metaphore to work flawlessly is:

• allowing the user to easily generate their own “information account number” (so, under the hood, a GPG/PGP keypair);
• accepting the key fingerprint in the addressee field.

In the e-mail world, which I would wager a bet is most important here, the former is already handled decently by Thunderbird with Enigmail – keypair generation is dead easy. Minor enhancements could be made with the language being used to be a bit less technical, but as far as I’m concerned, we’re home here.

The latter is more or less trivial: a handler that recognizes a properly formatted fingerprint and does all the work (downloading the public key, giving the user a chance to choose an identity if several are provided with the key, encrypting the e-mail, etc) under the hood. Actually, a proof-of-concept already exists, too (you can use it to send me encrypted e-mail right now).

Caveats¶

The bank account intuitions seem to work to our advantage here but there might be something I don’t see. If there is, do contact me or comment in this Diaspora thread.

There are also (simple enough, IMHO, but still) changes that are needed to be done to software (good candidates are MailPile and Enigmail) for that metaphore to work all the time. Still, I think it offers a good deal of simplification without being oversimplified. Ate the very least I hope it will spark a discussion on how to efficiently pass the knowledge to users without scaring them, hopefully by hooking into their pre-existing intuitions.