GnuPG is the premier open source public key encryption software. It’s compatible with Pretty Good Privacy, but has mostly supplanted PGP’s use by those who care about encryption.
It includes key management, encryption and digital signature facilities. For those of us with a healthy distrust of government — you need all of these things.
Introduction to Public Key Cryptography
Here are the rules
- Encrypting is targeted to a particular public key. Therefore you must have a copy of the receiver’s public key before you can communicate securely.
- Decryption is possible only by the owner of the secret key which is the other half of the public-secret key pair. When someone encrypts to your public key, that message can only be decrypted by your secret key. Even the originator of the message cannot decrypt that message (of course we can assume they know what it said).
- Digital signatures are created with a secret key, and verified with a public key. You can sign your messages with your secret key, and anyone with a copy of your public key can be sure that it is from you, and that it has not been tampered with. Public keys cannot be used to create digital signatures.
Installation
Debian users can do this:
$ apt-get install gnupg
Other distributions… you’re on your own. Windows users: there are GUI packages to do all this command line stuff for you. However, the concepts I’ll explain will still be of benefit to you, so don’t give up just because you have a button for every command line switch I’ll cover.
Creating Your Key Pair
The first thing to do is create your key pair. Accept the defaults were you are not sure. Be extremely careful about selecting your passphrase — it is the weakest link in your encryption system. I suggest a long (40+ characters) sequence of randomly chosen words. You will most likely keep this phrase for a long time, so it is worth committing it to memory. Your real name and email are important as well, as they represent the identity you are creating. You can always add and remove identities later, should you wish.
$ gpg --gen-key
gpg (GnuPG) 1.4.10; Copyright (C) 2008 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
gpg: keyring `/home/user/.gnupg/secring.gpg' created
gpg: keyring `/home/user/.gnupg/pubring.gpg' created
Please select what kind of key you want:
(1) RSA and RSA (default)
(2) DSA and Elgamal
(3) DSA (sign only)
(4) RSA (sign only)
Your selection?
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048)
Requested keysize is 2048 bits
Please specify how long the key should be valid.
0 = key does not expire
<n> = key expires in n days
<n>w = key expires in n weeks
<n>m = key expires in n months
<n>y = key expires in n years
Key is valid for? (0)
Key does not expire at all
Is this correct? (y/N) y
You need a user ID to identify your key; the software constructs the user ID
from the Real Name, Comment and Email Address in this form:
"Heinrich Heine (Der Dichter) <heinrichh@duesseldorf.de>"
Real name: Samuel Pepys
Email address: samuelpepys@example.com
Comment:
You selected this USER-ID:
"Samuel Pepys <samuelpepys@example.com>"
Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o
You need a Passphrase to protect your secret key.
Passphrase:
Repeat passphrase:
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
Not enough random bytes available. Please do some other work to give
the OS a chance to collect more entropy! (Need 284 more bytes)
........+++++
.+++++
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
.....+++++
Not enough random bytes available. Please do some other work to give
the OS a chance to collect more entropy! (Need 55 more bytes)
.+++++
gpg: /home/user/.gnupg/trustdb.gpg: trustdb created
gpg: key 933F6E71 marked as ultimately trusted
public and secret key created and signed.
gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u
pub 2048R/933F6E71 2011-02-25
Key fingerprint = 4742 1D26 31FF CB96 891B 9113 41A1 C94B 933F 6E71
uid Samuel Pepys <samuelpepys@example.com>
sub 2048R/1A6FB468 2011-02-25
In addition to creating a key pair, GnuPG has also created a secret keyring, a public keyring and a trust database (we’ll come to this later). Let’s have a look at them:
$ gpg --list-keys
/home/user/.gnupg/pubring.gpg
-------------------------------------------------------
pub 2048R/933F6E71 2011-02-25
uid Samuel Pepys <samuelpepys@example.com>
sub 2048R/1A6FB468 2011-02-25
$ gpg --list-secret-keys
/home/user/.gnupg/secring.gpg
-------------------------------------------------------
sec 2048R/933F6E71 2011-02-25
uid Samuel Pepys <samuelpepys@example.com>
ssb 2048R/1A6FB468 2011-02-25
The “pub†and “sec†lines are the important ones for us, the “sub†and “ssb†lines you can forget about. They are subkeys, and their use doesn’t matter to us. You may add more “uidâ€s in the future if you have more than one email address.
Initial Configuration
Let’s set some useful defaults and define ourselves as the default encryption key by editing the configuration file `~/.gnupg/gpg.conf
armor
no-greeting
default-recipient-self
hidden-encrypt-to 933F6E71
The last two lines set yourself as the default recipient if none is given; and add you to any recipient list that is given (replace the key ID with your own instead of mine). That means you’ll always be able to decrypt messages you encrypted (in spite of what I said in the opening section of this document).
Initial Encryption
That’s it — you can now encrypt a message to yourself.
$ echo "This text gets encrypted then decrypted" | gpg -e
gpg: skipped: public key already set as default recipient
-----BEGIN PGP MESSAGE-----
Version: GnuPG v1.4.10 (GNU/Linux)
hQEMAwAAAAAAAAAAAQgArOdJgISjdkiJ12ypZe3YTqPYgPZssosQkbPmCBRq/tS4
bbuL6UI8AtQLLF1zKYWzpdgz2I/dGiKLuNUYYy+66B0659WD/NY5dKJUtGaGE1Co
MV27t7+tXS7gb93rciOGJuNCddRT6zFilQGVjuChXv/W9Xri5NMLytpbLSyYiss9
K/66y3aID0N0haVt3PYwH0zu5aQCrBWznBfegwfEDDx4nfA55LuNREVyg51rFthk
23cSPWglfmGf/iDe5wG+s8rBBZdWRHdomWTfWc6rgjboC3OlDUJc47lCkxMOLWLZ
ofaHtnWK4mhRr4oloZyZ7mMbbPbytazkC+SixdHDi9JeAe5v8r+JSYTj7dGwmlSM
sFsVdtdcyPysoFgoFebA5wiHUIwH+08KiDfuIyTIvWJgLUYofkj6lj/gk5qGxmNs
y+xzp/MSksFq7L8vAi22IkXs4qQBmfcf+kAbJmhLxQ==
=n0pU
-----END PGP MESSAGE-----
This has come out as printable ASCII because we specified the ASCII “armor†option in the configuration file. If we hadn’t, then this would have been a stream of random binary bytes, that I couldn’t have shown you in a blog entry. ASCII armor is usually what you want though, hence why we’ve put it in the config file.
Now lets decrypt the message as well.
$ echo "This text gets encrypted then decrypted" | gpg -e | gpg
gpg: skipped: public key already set as default recipient
gpg: anonymous recipient; trying secret key 933F6E71 ...
Enter passphrase:
gpg: anonymous recipient; trying secret key 1A6FB468 ...
gpg: okay, we are the anonymous recipient.
gpg: encrypted with RSA key, ID 00000000
This text gets encrypted then decrypted
The last line is our plaintext back again just as we would expect.
Digital Signature
Let’s create a digitally signed message using our new key. I’ll use the --clearsign option so that the message is readable without the use of GnuPG.
$ echo "This is a signed message" | gpg --clearsign
You need a passphrase to unlock the secret key for
user: "Samuel Pepys <samuelpepys@example.com>"
2048-bit RSA key, ID 933F6E71, created 2011-02-25
Enter passphrase:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
This is a signed message
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iQEcBAEBAgAGBQJNZ9sWAAoJEEGhyUuTP25xDBQH/1eyfcHqBZjf6pdqxhnrv5FU
oM8BQTY5QGq1sDj7jjrOYDlKDgQZofXCPwhlqCRYSWUOe4yA1vfhOq83MiVhyVH5
SQC10cgbtYCrlTxw6aPBOBjv4qeXZHVrhmd0fooPzv+Lzgo+b7I3cIJ+jsDMk1ow
vSdqZHhWOwts4HHsHOyqUYXIZvTC30tRWBtJrvJb2YPa42zGwGyMP6T2L5eMz7H1
JblpgU1efHOZ/Evvz7aR7E8HPEZmx2bNzmAveN4kiNTmKaM9tQhH2YK3SKoeIgaI
bEbEfdqiCgqy1nI+a6FYbEGkqH6z+uhh8O21yJNzpU9XMrstGkqvSekH1DlMJps=
=T6Qp
-----END PGP SIGNATURE-----
Ignoring the passphrase request (which is necessary because it is your secret key that is used to create a signature, and so it needs unlocking), you can see a two part message: the plain text of the message followed by a signature block. These together are unfakeably from you. If anyone alters a single byte of this message then the signature will not verify. I’ll make two copies of this message, then edit one to have an extra full stop at the end of the text.
$ gpg < good.sig
This is a signed message
gpg: Signature made Fri 25 Feb 2011 16:43:09 GMT using RSA key ID 933F6E71
gpg: Good signature from "Samuel Pepys <samuelpepys@example.com>"
$ gpg < bad.sig
This is a signed message.
gpg: Signature made Fri 25 Feb 2011 16:43:09 GMT using RSA key ID 933F6E71
gpg: BAD signature from "Samuel Pepys <samuelpepys@example.com>"
A signature leaves the message readable by anyone — it is not encrypted; but it cannot be tampered with without being noticed. Further, it cannot be made to appear to be from anyone but you. Notice that GnuPG verified the signature like this:
gpg: Good signature from "Samuel Pepys <samuelpepys@example.com>"
A message with a good signature is a guarantee (as far as is humanly possible, assuming no coercion) that the owner of the private key really did write that message. Verification relies on you having a trusted copy of the signer’s public key.
Public Key Exchange
For others to be able to send you encrypted messages, they need a copy of your public key; and only your public key. Your secret key should never be given to anyone and your passphrase should remain secret at all times. You get a copy of your public key like this:
$ gpg --export "Samuel Pepys"
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.10 (GNU/Linux)
mQENBE1nzzYBCAC6UwplnYd3DsDNtFSkZPkEqDXqhGvtyq+LfWis5j4yztSOhbn6
rCbf3THHzACAbFfb8Y5yfoqEGbDGxDcXJSc74H+iUQmFs7V97KdBpYNhWvo0n/wn
9/1vGu1wJGJYQoUWI3w0VyfOqvCKJ/192p4H2pdZOI0bDfjQOjqqbXb4IjV5ZFeT
xQld2MGvznI/vofuYUt3I7tqIo/FT11oH2NF+ohe9GJINFqHCuIJJLN9OPUdJaqf
WV8YAgyLWCuiWVh31x80fqLlcLs9dAp9QHYV6xJlkcKiuCWlHzrbT8VBxrSvysYB
K5mEpN9vUxYZ6WkFWt1PohHAV7Fz/2ILj/azABEBAAG0I09udXMgUHJvYmFuZHkg
PG9wcm9iYW5keUBnbWFpbC5jb20+iQE4BBMBAgAiBQJNZ882AhsDBgsJCAcDAgYV
CAIJCgsEFgIDAQIeAQIXgAAKCRBBoclLkz9ucbPVCACxG/jVG6z5DzBk3ui4l8Fi
1AshxqKoQ9RaubF1EKdRlbjmOgVGNppmv8yQA4RpDMAtF90a54nwlxL7LzNGWPdJ
3rZ7BMDiaT9qYbEUBzHJppsjpXF9f+WgUFBpSGJOeYAW2osem2GWaf1iZdBIKOaE
hpLxZBcSdD/Qd67j+VjNBh8De6wJ3cTdvQvZwhf8tlPjKab68BQNTBgw/4QW80Ua
u2WS+lbPbY5evQ8cbTiGgjuVP9WWDwOTAMDHc638hcuQnRo6Y/5lY+AQGgYkabwG
5jzAFfyHx0AvksTAHiGu8TUmrlixYhi5YNHP768Xt7L4KoDl8cjyohKuSbx5O1Lk
uQENBE1nzzYBCADe6HFXStaFd4dlPWsqTEgd4VPLydrmkEksuCUH26rUZP0pvgzv
VvSSCAmCrud933CIb48BuLdGnpm0BJrOx15OJ3OSqQAh5DrCST1enpskNbH+Z3mQ
sszNBNEHh6fBIIvr9LUj5+3ciGQxG6W1uTahcarp8Ck/sA58u0QekuT8Gc1C70Oz
kxtQ4xJ5FikrtMDRDWiqF9wrMmSNMUe3nr6H2P+ipseIrDSYHPQfejVFKZX5U+rp
Vh9eaa5V0Lhm60kcD8AlOMOIxpzfSd0xeVmCOxnfbh0TPNksPM7NE1Z5/5OFIelp
4Kv44+wZVZLDuho4nTzBIBtXItWob10zDYDbABEBAAGJAR8EGAECAAkFAk1nzzYC
GwwACgkQQaHJS5M/bnG1kAf+KMM6LN4IwCW2yDEKAV5nVIT99rOLGnr6j/bzHMI3
5Xpijrme9y10etIxydDg3ml3m1SyICnw6Qw5EWgYlKKPz/iewQQP97D2EQqiaTLo
DJyRxSZsWZTqK7soKXxvRuiGOf3VmhhYLI3o7uoxZUT8edpGafc2mu2YY09ZUxpQ
IgCP6BiqHrHbX2BK4HBvvJzET9crJIK0xwkM+hLX+9EobfXdDekDxCSdWcopftG6
khua/NVlUWMaGaKE0vzEnAq9BQOovl79Q7X79RVt46zMDviiUWgApIb7KMfiT3EP
r6PFmjrcgj1e3xGRtQY6Fecb0kvtdHYUIkd0BHPcukY3oQ==
=73Rn
-----END PGP PUBLIC KEY BLOCK-----
Here’s where our paranoia starts to kick in. We need a way of getting this to our confidant in a way that guarantees it is not tampered with. An attacker could (in theory) intercept this key in transit and replace it with their own. Then when encrypted messages are sent to you, they can be decrypted by the attacker, and reencrypted for you. You might argue that that is highly unlikely, and you are probably right. You should be aware that its possible though.
Once your confidant has a reliable copy of your public key, things would seem to get easier. He can encrypt his public key and send it to you. I’m afraid not. Since your public key is just that: public, an attacker can encrypt their public key and pretend it’s your confidant’s and pull the same man-in-the-middle attack described in the previous paragraph. So: the same paranoid precautions are necessary to perform a public key swap. Again: you can say that it’s unlikely this level of paranoia is justified. No problem. That’s up to you. A good method of doing a key swap is in person, perhaps on USB drives.
Personally, I was never that paranoid, and so emailed it to the people I wanted to have it. That was eight years ago, so I’m fairly confident everyone has trustworthy keys.
So; what do you do with your confidant’s public key once you have it? You add it to your keyring. I’ll use Eric Raymond’s public key as an example.
$ wget --output-document=esr-public-key.asc http://www.catb.org/~esr/gpg-public-key.asc
--2011-02-25 16:28:03-- http://www.catb.org/~esr/gpg-public-key.asc
Resolving www.catb.org... 152.46.7.81
Connecting to www.catb.org|152.46.7.81|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 2346 (2.3K) [text/plain]
Saving to: `esr-public-key.asc'
100%[==============================================================>] 2,346 --.-K/s in 0.1s
2011-02-25 16:28:04 (20.1 KB/s) - `esr-public-key.asc' saved [2346/2346]
However you got it, you should have a small ASCII file containing a public key you want to add to your keyring. It’s easy to do so:
$ gpg --import esr-public-key.asc
gpg: key 8421F11C: public key "Eric S. Raymond <esr@thyrsus.com>" imported
gpg: Total number processed: 1
gpg: imported: 1
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u
And let’s look at our updated keyring:
$ gpg --list-keys
/home/user/.gnupg/pubring.gpg
-------------------------------------------------------
pub 2048R/933F6E71 2011-02-25
uid Samuel Pepys <samuelpepys@example.com>
sub 2048R/1A6FB468 2011-02-25
pub 1024D/8421F11C 1997-10-05
uid Eric S. Raymond <esr@thyrsus.com>
sub 2048g/5E995ED4 1997-10-05
Our own key, and now an additional key. Note that our secret keyring will be completely untouched; we would anticipate only ever having a single secret key (other than advanced users) — our own.
Trust
Our keyring is now sufficient to encrypt to our confidant now, and to verify a digital signature from them. Going through the process of physically meeting everyone whose key you need is inconvenient and time-consuming. There is a better way. We make use of what is called, the Web of Trust.
GnuPG can sign an arbitrary message, as we saw earlier. It can also sign a public key. Let’s say that I trust that the key I have for Eric Raymond is really his — that we physically met, and he showed me a copy of his passport; or perhaps we have been friends since childhood. I have faith that he owns the key he says he owns, and that the matching public key I have came directly from him. Now, say that you don’t know Eric Raymond, but you do know me — you trust me as much as I trust him. You trust me enough to vouch for his key. GnuPG can let you apply some of the trust you have in me to him.
Firstly, I must tell GnuPG that I trust Eric Raymond’s public key.
$ gpg --edit Eric
pub 1024D/8421F11C created: 1997-10-05 expires: never usage: SCA
trust: unknown validity: unknown
sub 2048g/5E995ED4 created: 1997-10-05 expires: never usage: E
[ unknown] (1). Eric S. Raymond <esr@thyrsus.com>
gpg> sign
pub 1024D/8421F11C created: 1997-10-05 expires: never usage: SCA
trust: unknown validity: unknown
Primary key fingerprint: 3CE7 64D4 FAFF 5FA8 10B2 03BF ADF5 16D3 8421 F11C
Eric S. Raymond <esr@thyrsus.com>
Are you sure that you want to sign this key with your
key "Samuel Pepys <samuelpepys@example.com>" (933F6E71)
Really sign? (y/N)
You need a passphrase to unlock the secret key for
user: "Samuel Pepys <samuelpepys@example.com>"
2048-bit RSA key, ID 933F6E71, created 2011-02-25
Enter passphrase:
gpg> quit
Save changes? (y/N) y
Let’s look at the signatures on Eric’s key:
$ gpg --list-sigs Eric
pub 1024D/8421F11C 1997-10-05
uid Eric S. Raymond <esr@thyrsus.com>
sig 8421F11C 1997-10-05 Eric S. Raymond <esr@thyrsus.com>
sig B5AF5867 1999-03-09 [User ID not found]
sig 9EDDB31F 1999-03-10 [User ID not found]
sig 7DF1849C 1998-08-21 [User ID not found]
sig E43C5FC3 1998-07-07 [User ID not found]
sig 0FD14ACD 1998-09-30 [User ID not found]
sig 087CD151 1998-12-27 [User ID not found]
sig FF9189D4 1998-09-03 [User ID not found]
sig 933F6E71 2011-02-25 Samuel Pepys <samuelpepys@example.com>
sub 2048g/5E995ED4 1997-10-05
sig 8421F11C 1997-10-05 Eric S. Raymond <esr@thyrsus.com>
You can see that it has been signed by a number of keys that we don’t have copies of — only the key IDs are shown; but it is also now signed by me. Remember: that signature from me is unfakeable, and you have a copy of my public key which you trust. If Eric were to send you a copy of this public key (with my unfakeable signature on it), you could safely trust that copy is the same as my copy; and that it is exactly the key that I signed.
In this way only one of us needs to trust that any given public key hasn’t been tampered with in order for us both to be able to trust that it hasn’t been tampered with. Note: this is not saying we extend our personal trust (it doesn’t mean you will hand over your children), we are saying that we trust that the owner of the key is who the key says it is.
This question of trust and signatures is a key one to understand: I’m anonymous, “Samuel Pepys†is not my real name. However, you might decide that the method by which I transferred my public key from me to you was secure — that my key could not have been tampered with on its journey. That might lead you to sign my key. That doesn’t mean you are saying you trust me personally (how can you, I am anonymous) you are saying that you believe that that key is owned by that identity — samuelpepys@example.com.
Extending Trust
Once we can rely on Eric’s key, we can further rely on his signature to verify other keys. Making it easier again to gain trusted copies of public keys.
However, what if we don’t trust Eric? What if you trust me to verify that he owns that particular key, but we think he’s an incompetent buffoon who will sign any public key sent to him from an any old account, from people he’s never heard of before?
$ gpg --update-trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0 valid: 1 signed: 1 trust: 0-, 0q, 0n, 0m, 0f, 1u
No trust value assigned to:
1024D/8421F11C 1997-10-05
"Eric S. Raymond <esr@thyrsus.com>"
Primary key fingerprint: 3CE7 64D4 FAFF 5FA8 10B2 03BF ADF5 16D3 8421 F11C
Please decide how far you trust this user to correctly verify other users' keys
(by looking at passports, checking fingerprints from different sources, etc.)
1 = I don't know or won't say
2 = I do NOT trust
3 = I trust marginally
4 = I trust fully
s = skip this key
q = quit
Your decision? 2
gpg: depth: 1 valid: 1 signed: 0 trust: 0-, 0q, 1n, 0m, 0f, 0u
Having told GnuPG that I don’t trust Eric to verify keys, it will never use the presence of his signature on another key to extend trust to that key.
Extending the question of trusting an anonymous identity like my own that we raised above: you would sign my key (if you believed it was my key) but you would tell GnuPG that you did not trust me to sign other keys. Your web of trust would always stop at me.
In summary: sign any key you really, really believe is owned by the identity that claims to own it. By ownership we mean that the same identity has access to the private key. Then use your own judgement to say how much you trust that identity to vouch for other identities.
You can occasionally run
$ gpg --update-trustdb
And gpg will ask you to supply levels of trust for any that you haven’t already specified. Again: this is not the level of personal trust, or even trusting that identity it is whether you trust them to acceptably verify another identity. For example: you might create a key pair for your non-techie wife, and trust entirely that the public key you hold is hers. That does not mean that you trust her to be able to use gpg to successfully sign another key, so you would set her trust to ‘do not trust’. I know it seems rude, but that’s what the ‘ownertrust’ field means to gpg.
Misconceptions
It’s common for people talking about signing other people’s keys to tell you that what you are signing is that that person is a real person; that you should check passports and drivers licenses, bank statements before signing — in other words they want it to be a verified way of connecting cyberspace and “meatspaceâ€. They are missing the point of keysigning. It’s job is to show that you are convinced they own the identity, not that they are the identity.
It’s subtle distinction, but important to understand. The thing is: you can’t trust a passport or a drivers license to prove identity. You are (presumably), like most people, not an expert in spotting forged identity papers. Therefore they prove nothing to you. Let’s remember the purpose of all this key signing is to provide you with a secure, encrypted path to a particular person. It is not an identity system; it is a proof-of-ownership system.
Once that ability to communicate in a secure way using encryption, and the ability to ensure messages aren’t faked; you can build up whatever level of trust you want in the identity you are communicating with, just as you do with every other personal relationship.
In summary then: sign keys if you believe (and remember that your trustworthiness in this adds to the trustworthiness of your key) that that public key’s private key really is owned by the identity it claims to be owned by.
Here’s how it might work in practice:
- Samuel Pepys asks you to sign his public key,
933F6E71. You want Samuel Pepys to sign your public key too. - You both exchange public keys. You can do this using whatever method you wish (including insecure methods, that can leave the copies of the keys compromised).
- Here’s the important part: so far all that has been exchanged has been publicly available information. You should now each pick a secret one-time-use phrase (any long sequence of random characters will be fine). Each of you should encrypt your secret for the other and send it. This leaves you each with knowledge of two secrets — your own, and the other. These are secrets that can only be decrypted by the owner of the key pair.
- You each generate and print out copies of the public key fingerprints (
gpg --fingerprint). Note that the eight digit key ID is actually the last eight digits of the key fingerprint. - Now you meet. Each of you knows what your own key fingerprint really is, and what you expect the other’s key fingerprint to be. You simply compare those fingerprints and confirm that they all match. i.e. Samuel Pepys shows you what he knows his public key fingerprint is, and you check that it matches what you think it is. And vice versa. Similarly, you then verify that the other really does know the one-time-use secret you made up. You can then be sure that they are the genuine owner of the private key.
- It is important that this is done in person (or, I suppose any other channel you know can’t be tampered with en route), as you are each verifying that the public key you have for the other is the real public key, rather than a substitute one created by a man-in-the-middle attacker.
- Assuming everything matches, you can each return home and sign the other’s public key.
This works because you have been given a fingerprint and email address, in person. The fingerprint verifies that you are both speaking of the same key; and the knowledge of the shared secrets means that the person you meet really is the owner of the private key that matches that public key — otherwise how would they have decrypted it when you sent it them?
See the Signing Role Keys and Pseudononymous Keys section in the keysigning party howto document for more information.