Computer Security lecture notes Copyright © 2005 Mark Dermot Ryan
The University of Birmingham
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License,

Key certificates and PGP

Recap on issues about how cryptography is used

Symmetric-key encryption allows agents to communicate securely, but leaves them with a hard problem: how to agree securely on a key? The main solutions available to them are:
  1. Face-to-face key exchange
  2. Key exchange via a trusted third party (TTP), with whom the agents already share a secret symmetric key.
These solutions are inconvenient and expensive, especially as they have to be done frequently, or you have a key-management headache. (With n parties, you have O(n2) keys, or O(2n) keys if you want to allow messages private to a group.)

Public-key encryption solves the problem of key exchange, but gives us another problem: how to ensure the authenticity of other people's public keys? The same solutions exist:
  1. Face-to-face key exchange
  2. Key exchange via a TTP
but now they have to be done only once, since are only O(n) keys to manage. Public-key encryption also gives us another solution:
  1. Key certificates.

The concept of key certficate

A key certificate is an assertion that a certain key belongs to a certain entity, which is digitally signed by an entity (usually a different one).

If Alice trusts Bob and knows his public key, and Bob has signed asserting that Carol's key is K, then Alice may be willing to believe that Carol's key is K. 

In this example, Bob might create a signed certificate saying that Carol's key is K.  Anyone reading this certificate is assured that Bob asserts that Carol's  key is K. Thus, Carol can present that certificate to anyone that she wants to give her key to. Bob does not need to be present, or to be involved in the transaction. Carol can reuse the certiticate he has signed as often as she wants.

However, if Alice is to be convinced that Carol's key is K, she has to already know Bob's public key (in order to verify that he really states that Carol's key is K), and she has to trust him (in order to believe the statement).

Example: when you use "https" (i.e., a secure web site, say gmail), then gmail sends your browser its public key.  Your browser needs proof that that key really is gmail's key. So gmail sends a certificate asserting that the key is really gmail's key. The certificate is signed by a certificate authority, which in gmail's case is "Thawte Consulting (Pty) Ltd." Your browser will verify Thawte's signature on gmail's key, and warn you if it is incorrect. Your browser has Thawte's key built into it, so it can verify that Thawte really asserts that the key belongs to gmail. You are expected to believe Thawte, since it is a reputable key certificate authority.

Trust chains

There can be trust chains. Suppose
If I know A1's key, and I trust A1, A2,..., A20, then I am willing to believe that B's key is K.

A1 states that A2's key is K2. So, if A2 signs an assertion X, then A1 states that A2 states X. Thus, in the situation above, A1 states that A2 states that A3 states ... that A19 states that A20 states that B's key is K.

X.509 certificates

X.509 certificates are used by SSL/TLS, SET, S/MIME, IPSec and other protocols. They have these components:
The unique identifier fields were added in version 2 to handle the possible re-use of subject and/or issuer names; rarely used.

X.509 certificates are typically issued by a certificate authority (CA). Anyone can be a CA, but not all CA's are trusted by everyone. Verisign is a top-level CA, trusted by most people. Its key (valid 9/11/94--7/1/10) is built into browsers. If you go to Amazon's secure server and you view the certificate information held by your browser, you will see that Verisign certifies its public key (valid 14/5/03--13/5/04). So the chain is:
We trust Verisign, so we are assured of Amazon's key. Therefore we can be sure that we are dealing with Amazon, and not someone who is pretending to be Amazon (e.g, by launching a man-in-the-middle attack).

If you go to, Mozilla will say:
(You can continue anyway, at your own risk.) The reason is that SIS has not obtained a certificate from a CA recognised by the browser, such as Verisign or Thawte (because it is expensive and inconvenient to do so).

PGP ("Pretty Good Privacy")

PGP is a complete working system for cryptographic protection of files and email. It offers confidentiality, integrity, and non-repudiation, by using public-key cryptography algorithms. The original version by Phil Zimmermann was  released on the Internet in 1991.

PGP is now commercial, though freeware versions for Windows and other non-Linux platforms exist for individual, non-commercial use. OpenPGP is a set of standards which describes the formats for encrypted messages, keys, and digital signatures. GnuPG (or gpg) is an open-source GPL implementation of the standards, and is the usual implementation found on GNU/Linux systems. Most of what you read about PGP applies also to GnuPG, and vice versa.

A "PGP key" has several parts:
These fields are similar to those of an X.509 certificate. But a PGP key is not yet a certificate (no-one has signed it yet).

The PGP software will generate keys for you, and help you manage them. Usually you will have a different key for signing as for encryption. You may even have two keys for signing; one for signing keys and one for signing email and everything else. This is for extra security; your key-signing key is the most important one, and if other keys were compromised you would like that one not to be automatically compromised too.

When using PGP, you will need to store lots of keys.
The PGP software puts them in a file, called your keyring. Your private keys are in a file only you can read; for extra security, they are stored encrypted with a pass phrase. The public keys don't have to be protected.  The keyring also stores certificates, i.e. copies of other people's public keys which are signed by you. These ones are known with certainty by you to belong to the people they claim to belong to.

When you send someone a "signed message", PGP actually signs a hash of the message. This is because
When you send someone a message "encrypted with their public key", PGP actually encrypts it with a newly-generated symmetric key, and then you send that encrypted version appended to the symmetric key encrypted with the public key. It's more efficient. It also means you can prepare a message for reading by several people: just append the symmetric key several times, each time encrypted with one of the public keys of the intended recipient.

Thus, PGP puts together the ideas of symmetric-key encryption, public-key encryption, and hash functions, and also text compression, in a practical and usable way to enable you to sign and/or encrypt email. The algorithms PGP uses are:

Key management

I need to have Bob's public key on my keyring if
So, how do I get Bob's key onto my keyring? Here are some ways in which Bob can give me his key in a secure way:
More often, I will get Bob's key in an insecure way. . .
. . . and then I will verify it, e.g.

The web of trust

A key in your public keyring has the following attributes associated with it:

The diagram below is reproduced from William Stallings' excellent book, Cryptography and Network Security [2]. These diagrams are copyright 2003  by Pearson Education Inc., and are not covered by the Gnu Free Documentation License which covers the other parts of this document.
Example web of trust

The diagram illustrates how signature trust and key-signing combine to produce key legitimacy. The user (marked "you") always trusts agents D, E, F, and L to sign other keys and partially trusts users A and B to sign other keys. The arrows show who has signed whose key.

Getting started with PGP/GnuPG

Look to see what support your mail client has.  If none, change to Mutt if you like an ascii text-only client, or Mozilla Thunderbird if you want a GUI. They're both free.

Why does no-one use it?

Sadly, nearly no-one uses PGP. Among the 80 staff at SoCS, none of them use it regularly. Among the 73 PhD students, two use PGP regularly. Yet these people are among the most computer-literate people you can find, and they also have the right sort of political profile to be interested in PGP. I think there are several reasons why PGP is not much used.
Why Johnny can't encrypt is an interesting article attempting to explain why people can't/don't want to use PGP. The problems here are among the most difficult ones in computer security.  I think they can be overcome, and I think they will have to be in the long term, as attacks on privacy (including identity theft, spam, phishing) continue to increase.


  1. S. Garfinkel and G. Spafford, Web Security, Privacy & Commerce, O'Reilly, Second edition, 2002. There is very readable and good information about PGP/OpenPGP in Chapters 4, 6, 7.
  2. William Stallings, Cryptography and Network Security, Principles and Practice,  Prentice Hall, 1999.
  3. The Gnu Privacy handboook is a good intro to getting started with GPG (at least under Linux; not sure about the situation for other operating systems)
  4. Mutt is an easy-to-use text-based email client which can easily be set up to use PGP or GPG, for email signing, signature verification, and encryption/decryption.

VeriSign dead certificate: After the cert VeriSign used to sign other certs expired, the chain of trust was broken, leaving some aps unable to set up a secure connection. These apps then defaulted to trying to access Verisign's certificate revocation list server ( which, faced with a huge extra load, buckled under the pressure.