GPG mail signing
PGP and GPG allow you to both sign and encrypt mail. See Send Signed Email for a short overview and a comparison with S/Mime mail.
- 1 Install GPG/PGP Software
- 2 Create a Public/Private Key Pair
- 3 Key Signing
- 4 PGP Identities and Subkeys
- 5 Sending GPG Mail
- 6 Web of Trust analysis
- 7 More Information
Install GPG/PGP Software
Before you start, you may want to install some software.
- Software overview (stand-alone apps and mai client plug ins).
- Configuring GnuPG (Mac OS X)
- You can get gnupg from a package manager like MacPorts or Fink.
- Alternatively, download the software from http://www.gnupg.org/ (general) http://macgpg.sourceforge.net/ (Mac OS X GUI tools)
- If you use Thunderbird, download Enigmail
- For some very useful utilities, download the PGP Tools package for Debian.
Note that installing gnupg2 with gpg-agent did result in the error "Could not start the gpg-agent which is needed for your GnuPG version 2.0.3". Apparently the problem is that gpg-agent does not see the proper $PATH. This can presumably be fixed with a ~/.MacOSX/environment.plist</tt> file, but I simply downgraded to gnugp to fix it.
Create a Public/Private Key Pair
You only need to do this once.
Use the default settings (create DSA and Elgamal keys). Check if you got a key:
gpg --list-keys gpg --check-signs
Note the ID of your key, and, add your other mail addresses to this key:
gpg --edit-key [ID of your key] command> adduid
With GPG, it is common to share your settings and key database among all your computers. You can move your ~/.gnupg directory around. Just make sure it is not readable for others. Alternatively, you can use a different keys or different subkeys on each computer. Actually, if you are interested in PGP, I strongly recommend you take the later approach, and create different subkeys for certification (signing keys of your friends), encryption, and signing. See for example: gpgkeys met subkeysmaken (Dutch). While the procedure is definitely more complex than what is written down here, you may appreciate it later on.
GPG uses a web of trust. With Enigmail and the public key ring, you can automatically download keys from ther people. However, you should not just trust those keys, since it is very easy to fake (anyone can simply upload a fake key!). Instead, you only trust people you have met in person, and may use their "web of trust" by trusting the people they trust. Practically, you trust someone if you have signed his or her key, and you can set the level of trust.
To sign someone else his or her key:
1. Go to the person, and get his/her key with fingerprint on a piece of paper.
2. Verify the identity with a photo-ID (passport or drivers license)
3. Go home, download the key form a public keyserver (e.g. http://pgp.surfnet.nl/)
gpg --recv-key 0xB804CF07
4. Verify that the fingerprint is the same
gpg --fingerprint 0xB804CF07
5. Sign the key
gpg --sign-key --ask-cert-level 0xB804CF07
The certification level is how good you verified the identity of the signed key. If you like gpg to always ask for the certification level, add a line with ask-cert-level to ~/.gnupg/gpg.conf.
6. Optionally set the trust level:
gpg --edit-key 0xB804CF07 Command> trust
The trust level is how much you trust the key owner to do the signing of others.
7. Mail the key the owner, or upload it yourself.
If you want to trust a key, without actually signing it, you still have to sign it, but you can decide not to let anyone know about it. You do that by "locally signing" a key. These keys are marked "not for export".
gpg --lsign-key --ask-cert-level 0xB804CF07
The caff script automates steps 5 to 7, and is in particular useful if the key you are signing has multiple e-mail addresses attached to it. caff can be found in the pgp-tools packages for Debian or Red Hat.
As soon as you signed a key, you would other to take advantage of the new trust relation. You can either upload the signed key yourself:
gpg --send-keys 0xB804CF07
Alternatively, you can mail the signed key to the owner. The advantage of mailing it to the owner is that you immediately verify the mailaddress (you encrypt the message, and only the key owner can read it, and only if he has access to the given mail address).
gpg --export --armor 0xB804CF07 > signedkey.asc
And mail this file to the owner, while encrypting the mail.
If you are pedantic, you will observe that the above procedure does only verify the mail address you sent the mail to. What if the key contains multiple e-mail addresses? The really secure way would be to only send each signature (you create one signature per e-mail address) only to that e-mail address. As said, the caff script does this automatically.
GPG has defined four levels of cert verification (sign levels):
0 - No particular claim is made (generic certification) 1 - No verification of identity (persona certification) 2 - Casual verification of identity (casual certification) 3 - Extensive verification of identity (positive certification)
By default, GPG signs using level 3.
It is recommended to sign at level 3 for friends, and people you know for a longer time. Level 2 is to be used for people whose identity you verified using passport and whose mail address you verified with an encrypted mail. However, these definitions are vague by purpose, and you are free to deviate from them if you feel you have better criteria.
It is not recommended to use level 0 or level 1. The reason is that a lot of software simply ignores this verification level. Instead, if you want to trust a key that you did not or could not carefully verify, you instead "locally sign" (lsign) it (thus by marking the signature as "not for export" to the keyserver).
In addition to the above cert verification levels, you can also set the owner trust of each key that you sign. The owner trust setting is used to calculate the trust which is ultimately to decide if a key is "trusted" or "untrusted"
The levels are:
1 = I don't know or won't say 2 = I do NOT trust 3 = I trust marginally 4 = I trust fully 5 = I trust ultimately
Typically, you ultimately trust yourself only, and fully trust the people whose key you have signed.
You can change the trust setting with
gpg --edit-key 0xB804CF07
The calculated trust ultimately decides on the validity of a key. You can not set it, but it is a calculated. GPG will treat these keys as valid (trusted):
- your own key
- all keys that you have signed (including local signed)
- keys that have been signed by someone you fully trust
- keys that have been signed by at least three persons you marginally trust. In addition, there should be a chain of trust of 5 hops at most.
It is possible to alter these settings, but most people leave them as is.
The normal verification process verifies both the name (using passport identification) as well as the email address. There are a few automatic signers that will automatically sign your PGP key if you prove that a certain mail address really belongs to you. This is somewhat useful, since the keyservers do not verify the email address at all (it is very easy to upload a bogus key).
- CA Cert Signing Authority (Root CA) <gpg.at.cacert.org> (unclear if this really is an automated validator)
- PGP Global Directory Verification (six month validity).
- C't magazine validator
- More at http://www.vanheusden.com/pgp.php
PGP Identities and Subkeys
Analysing a given key
Each PGP "key" actually contains a few user identities. Usually, one user identity for each e-mail address that you use. The following PGP key has two keys (a primary and a subkey), for respectively signing, certification and authentication (SCA) and for encryption (E). Furthermore, it has three identities: two mail addresses and a JPEG image.
% gpg --edit-key 0xB804CF07 list quit pub 1024D/B804CF07 created: 2006-02-05 expires: never usage: SCA trust: ultimate validity: ultimate sub 2048g/2C33CF18 created: 2006-02-05 expires: never usage: E [ultimate] (1). Freek Dijkstra <firstname.lastname@example.org> [ultimate] (2) Freek Dijkstra <email@example.com> [ultimate] (3) [jpeg image of size 5225]
Multiple Keys or Multiple Subkeys
People can have multiple PGP keys. This is done to reduce the damage if they compromise their private key. For example, you can have PGP key for signing, that you keep off-line, and another one (daily use) key for sending and receiving e-mail. You only use the daily use one for a year, and then create a new one. This doesn't hurt your web of trust, since others only sign the off-line key (which then signs the daily use key).
The trick here is to separate functions:
- encrypt/decrypt (decrypt with your private key of a message you received)
- sign (sign data. For example a file or to send signed e-mail)
- certify (sign another key, establishing a trust-relation)
- authentication (log in to SSH with a PGP key; this is relatively new usage)
So the "off-line" key as described above would be only used for certification, while the "daily-use" key is only used for signing and decryption.
Actually, you can further split the usage of your daily key(s):
- A sign key on your home computer
- Another sign key on your work computer
- An decrypt key on both computer
You can not have a separate decrypt key for the home and the work computers. After all, if someone wants to send you an e-mail she/he doesn't know which key to use for encryption of the e-mail.
Beside of using different keys, it is also possible to use different subkeys for the different purposes. Thus, a key can noy only contain multiple identities (the uid records), but also multiple subkeys (sub records).
The great thing is that you can add four different kind of attributes to each subkey:
- e = encrypt/decrypt (decrypt with your private key of a message you received)
- s = sign (sign data. For example a file or to send signed e-mail)
- c = certify (sign another key, establishing a trust-relation)
- a = authentication (log in to SSH with a PGP key; this is relatively new usage)
Indeed, that is the same list as the functions above. You can find the flags with :
gpg --fixed-list-mode --with-colons --list-key 0xB804CF07
gpg --edit-key 0xB804CF07 pub 1024D/B804CF07 created: 2006-02-05 expires: never usage: SA trust: ultimate validity: ultimate sub 2048g/C0F03FEE created: 2006-02-05 expires: 2009-01-25 usage: S sub 2048g/2C33CF18 created: 2006-02-05 expires: 2009-01-25 usage: E [ultimate] (1). John Doe <firstname.lastname@example.org> [ultimate] (2) John Doe <email@example.com>
The trick is to keep your key as a whole offline, and only store the public key, and the secret subkeys on your online computer(s). Thus not the secret key of the whole key. You can do this as follows:
On the offline computer:
gpg --export 0xB804CF07 > publickey gpg --export-secret-subkeys 0xB804CF07 > secretsubkeys
An a on-line computer:
gpg --import publickey secretsubkeys
- Your "main" subkey is only meant for certification. This is your "off-line" key.
- You have one subkey for encryption, present on each online machine
- You have one or more subkeys for signing, each present on a single online machine.
- http://non-gnu.uvt.nl/pub/uvt-unix-doc/gpgkeys-met-subkeys-maken (Dutch)
- http://atom.smasher.org/gpg/gpg-migrate.txt (Upgrade an existing key to use subkeys)
Sending GPG Mail
Signing or Encrypting
A signed mail can be read by everyone, but the receiver can make sure that you are the one who has send the file. It is not possible for a man-in-the-middle to alter the mail. So signing provides you with authenticity and non-repuditation. It does not provide confidentiality, and it is still vulnerable against replay attacks (someone may take your mail and send it again to someone else).
Encryption on the other hand provides confidentiality. It makes sure that only the intended receiver(s) are able to read the mail. Technically, the mail is encrypted with a shared secret, and the secret is encrypted for each receiver with their public key. In addition, the secret is also encrypted with your own public key, so that you can still read the mail after you have sent it. Encryption does not provide authenticity; it is possible for some to alter the mail. Thankfully, you can use both encryption and signing at the same time.
Neither technique prevents replay attacks, and in encryption provides limited privacy: while the message body can only be read by the intended recipients, it is relatively easy to see that you communicate with someone in the first place. Just that information might be considered confidential too.
PGP/MIME or in-line
PGP allows you to send the mail using PGP/MIME. In that case, the whole message is encrypted or signed, including any possible attachments. The disadvantage is that most, but not all mail clients support PGP/MIME (in particular: Eudora on Windows does not display anything), and it typically won't work for mail sent to a mailinglist.
Traditionally, PGP can also sign a message, and add some addition information to the message body, as shown below. The disadvantage is that a mail client that does not support PGP sees a blob of strange text, and that it is not possible to sign or encrypt attachments.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello world, This is the mail body. -----BEGIN PGP SIGNATURE----- Version: GnuPG v22.214.171.124 (Darwin) iD8DBQFEPA3nVnw8LbgEzwcRAtbrAJ44pOR2aDpn3a4zBPTQ42075PrYQQCff8gn wJ5oV2KI5UFVavicQMDslK0= =Uog+ -----END PGP SIGNATURE-----
Another disadvantage of PGP/MIME is that it is not compatible with S/MIME.
Web of Trust analysis
A few people made analysis of the web of trust. Here are some results and useful links:
- Explanation of Keyring Analysis. Good starting point, also explaining terms like "strong set" and "mean shortest distance" (MSD).
- Dissecting the Leaf of Trust. A nice background read on the analysis of the web of trust.
Specific analysis per key (links point to my own key):
- http://www.phildev.net/pgp/gpg_graphs.html (Create a graph of your own web of trust)