GPG mail signing

From Exterior Memory
Jump to: navigation, search

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.

Install GPG/PGP Software

Before you start, you may want to install some software.


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.

gpg --gen-key

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.

You are recommended to upload you new key to a public key ring, like of

Key Signing

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.

Basic Procedure

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.

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.

Key upload

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.

Verification Level

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).

Trust settings

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

Calculated Trust

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.

Automatic signing

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).

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 <>
[ultimate] (2)  Freek Dijkstra <>
[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 <>
[ultimate] (2)  John Doe <>

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

Let's summarize:

  • 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.

More information:

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.

Hash: SHA1

Hello world,
This is the mail body.
Version: GnuPG v1.4.2.2 (Darwin)


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:

Specific analysis per key (links point to my own key):

More Information