A Brief Overview of PGP Public Keys

Why & How To Use PGP Keys

For a good background education on PGP encryption and digital signatures, we recommend that you:

1. Read the basic documentation that comes with PGP (or GPG, or whichever OpenPGP application you are using).
2. Subscribe to the PGP-USERS mailing list.

A Very Concise, Basic Encryption Backgrounder

"Conventional" Encryption

Conventional (a.k.a. single-key or symmetric) encryption requires that the sender/author find some way to deliver the encryption/decryption "key" to the recipient/reader. (This can pose problems, because how does one securely get this key to the second party?) A very simple (and very weak, by modern security standards) example of conventional encryption is the simple character substitution cipher you may have toyed with as a school child. Usenet's ROT13 cipher is a code of this sort, as was Julius Caesar's secret military code.

More robust, modern forms of conventional encryption have benefits. Single-key encryption is very fast. It is especially useful for encrypting data that is not going anywhere, such as financial information on your hard drive. However, conventional encryption alone as a means for transmitting secure data can be quite expensive simply due to the difficulty of secure key distribution. Recall a character from your favorite spy movie: the person with a locked briefcase handcuffed to his or her wrist. What is in the briefcase, anyway? It's probably not the secret plans themselves. It's the key that will decrypt the secret data.

For a sender and recipient to communicate securely using conventional encryption, they must agree upon a key and keep it secret between themselves. If they are in different physical locations, they must trust a courier, an encrypting phone that uses some other already-secured key, or some other secure communication medium to prevent the disclosure of the secret key during transmission. Anyone who overhears or intercepts the key in transit can later read, modify, and forge all information encrypted or authenticated with that key. From DES to Captain Midnight's Secret Decoder Ring, the persistent problem with conventional encryption is key distribution: how do you get the key to the recipient without someone intercepting it?

Public Key Cryptography (PKC)

The problems of key distribution are solved by public key cryptography,the concept of which was introduced by Whitfield Diffie and Martin Hellman in 1975.

Public key cryptography (including PGP and GPG) is an asymmetric scheme that uses a pair of keys for encryption: a public key, which encrypts data, and a corresponding private, or secret, key for decryption (and from which the public key is derived). You may publish (e.g., to a PGP keyserver) your public key to the world, but must keep your private key secret. Anyone with a copy of your public key can encrypt information to you that only you can read. Even people you have never met. This makes public key encryption, such as PGP and GPG ideal for use in e-mail, since it allows people who have no pre-existing security arrangement to exchange messages securely. The need for sender and receiver to share secret keys via some secure, difficult method is eliminated; all communications involve only public keys, and no private key is ever transmitted or shared. And, since the expensive process of secure key exchange is removed, public key encryption is feasible for cheap, even free, use by individuals, instead of relegated to use only by governments and large corporations.

It is considered computationally infeasible to deduce the private key from the public key, which is a cryptographer's way of saying it's virtually impossible while still leaving open the possibility that a powerful organization with considerable resources and technical sophistication (or a very, very clever individual with a pocket calculator) will someday develop an extraordinary cryptanalytic capability (N.B.: history strongly suggests that this is precisely what the US National Security Agency is trying to do to 'crack' public keys under certain sizes using accelerated hardware devices). Anyone who has a public key can encrypt information to that key but cannot decrypt it (unless of course they also have the corresponding private key). Only the person who has the private key can decrypt the information.

• Sender creates a document ("plaintext").
• Sender encrypts this file with the public key of the recipient ("ciphertext").
• Sender sends the ciphertext to recipient.
• Recipient uses their secret key to decrypt the ciphertext.
• Recipient now has the plaintext the sender wanted them to see.

How PGP/GPG/OpenPGP Works

PGP (Pretty Good Privacy) and GPG (Gnu Privacy Guard a.k.a. GnuPG) are [mostly-]compatible encryption programs based on the OpenPGP Standard developed by the OpenPGP Working Group of the Internet Engineering Task Force (IETF). For example, CryptoRights is developing its HighFire system to be fully OpenPGP compatible and the term "HighFireID" actually refers to an OpenPGP format key with special attributes for use within the HighFire communications environment. PGP and GPG software clients are freely available internationally for a huge variety of operating systems (commercial versions of PGP also exist with additional features). Hereafter in this document, "PGP" may be used as shorthand for "any OpenPGP encryption software" (including HighFire) but is not to be confused with the commercial products from PGP Corporation.

PGP is a hybrid cryptosystem that combines the useful capabilities of both conventional (high security) and public key cryptography (key distribution). When a user encrypts plaintext with PGP, PGP first compresses the plaintext. Data compression saves transmission time and disk space and, more importantly, strengthens the cryptographic security. Most cryptanalysis techniques exploit patterns found in the plaintext to crack the cipher. Compression reduces these patterns in the plaintext, thereby greatly enhancing resistance to cryptanalysis. Attackers are forced to both decrypt and decompress on each brute force attack round, thus dramatically increasing the time needed to find the needle in the haystack.

PGP then creates a session key, which is a one-time-only secret key. This session key or "seed" is a random number generated from the random movements of your mouse and the keystrokes you type. This session key works with a very secure, fast conventional encryption algorithm to encrypt the plaintext (resulting in "ciphertext" — an encoded message). Once the data is encrypted, the session key is then encrypted to the recipient's public key. This public key-encrypted session key is transmitted along with the ciphertext to the recipient (transparently — the recipient simply seens a single encrypted message, and does not have to do anything manually with the session key; it's all handled by the hardware).

Decryption works in the reverse. The recipient's copy of PGP uses his or her private key to recover the temporary session key, which PGP then uses to decrypt the conventionally-encrypted ciphertext.

The combination of the two encryption methods combines the convenience of public key encryption with the speed of conventional encryption. (Conventional encryption is about 1,000 times faster than public key encryption.) Public key encryption in turn provides a solution to the secure key exchange problem. Used together, performance and key distribution are improved without any sacrifice in security.

Keys

A key is a value that works with a cryptographic algorithm (the mathematical process of encrypting) to produce a specific ciphertext (encrypted message) from a specific plaintext (original document). Keys are basically really, really, big numbers. Key size is measured in bits; the number representing a 1024-bit key is huge by the standards of anyone but a mathematician. In cryptography, the bigger the key, the more secure the ciphertext.

While the public and private keys are mathematically related, it's prohibitively difficult, even for a large and well-funded attacker, to derive the private key given only the public key; however, deriving the private key is always technically possible — given enough time and computing power. This makes it very important to pick keys of the right size; large enough to be secure, but small enough to be used reasonably quickly. Additionally, you need to consider who might be trying to read your files, how determined they are, how much time they have, and what their resources might be. As of 2004, CRF recommends generating public keys with a size of at least 3072 bits (up to 4096 bits, the maximum specified by the current OpenPGP format document, RFC 2440, available from the IETF website) because such key sizes should be secure against most or all governmental, individual or corporate attacks for quite some time, without being so large as to make their regular use on conventional personal computers impractical. As of this writing, PGP defaults to generating a 2048-bit key and CRF's HighFire defaults to generating a 3072-bit key (using GnuPG). Coincidentally, a 3072-bit key is considered by professional cryptographers to provide defense against cryptanalysis that is roughly equivalent to the 128-bit symmetric encryption that all OpenPGP-compliant software will use to encrypt the actual data being transmitted.

Larger keys will be cryptographically secure for a longer period of time. If you need to encrypt something that needs to be hidden for many years, you might want to use a very large key for such a document. But, given tomorrow's faster, more efficient computers, there is no way to guarantee how long even a 10,000-bit key will remain secure against concerted attackers using future cryptanalytic technologies. There was a time when a 56-bit symmetric key was considered extremely safe (this is obviously no longer the case today).

Keys are themselves stored in encrypted form on a harddisk to protect them from unauthorized use (since access control privileges are not considered secure enough). PGP stores the keys in two files on your hard disk; one file for public keys and another for private keys. These files are called keyrings. As you use PGP, you will typically add the public keys of your recipients to your public keyring. Your private keys are stored on your private keyring. If you lose your private keyring, you will be unable to decrypt any information encrypted to keys on that ring. Our PGP Help Team FAQ has some information and recommendations regarding PGP key and keyring management. Ideally, your secret keyring should be kept somewhere secure (i.e. on physically secure equipment such as a HighFire 'IceBox' server or 'FireBox' office appliance), and/or backed up securely (e.g. on a removable disk that you keep with you, and which you have a backup of in a lock-box, safe, etc.)

Digital Signatures

PGP isn't just about encrypting private communications. It also provides authentication and data integrity, i.e. proving that your communications come from you, not from an imposter, are were not modified.. This major benefit of public key cryptography is possible because it provides a method for employing digital signatures. Digital signatures enable the recipient of information to verify the authenticity of the information's origin, and also verify that the information is intact. A digital signature also provides non-repudiation, which means that it prevents the sender from claiming that he or she did not actually create and/or send the material in question. These features are every bit as fundamental to cryptography as privacy, if not more.

A digital signature serves the some of the same purposes as a handwritten signature. However, a handwritten signature is easy to forge (counterfeit). A digital signature is superior to a handwritten signature in that it is nearly impossible to fake, plus it attests to the contents of the information as well as to the identity of the signer.

Some people tend to use signatures more than they use encryption, especially if what they are communicating is not particularly private but the authenticity of which is very important.

The basic manner in which digital signatures are created is illustrated below. Instead of encrypting information using someone else's public key, you encrypt it with your private key. If the information can be decrypted with your public key, then it must have originated with you.

• Sender produces an original document or message (plaintext).
• Sender uses his/her own private key to digitally sign plaintext.
• This does not produce ciphertext, but simply "frames" the plaintext in a digital signature.
• Sender e-mails the signed plaintext to recipient.
• Recipient uses sender's public key to verify the signature on the plaintext.

Digital Certificates, Trust and Keyservers

One issue with public key cryptosystems is that users must be constantly vigilant to ensure that they are encrypting to the correct person's key, and that the key belongs to who the key says it belongs to. In an environment where it is safe to freely exchange keys via public servers, "man-in-the-middle" attacks are a potential threat. In this type of attack, someone could post a phony key with the name and user ID of an individual to be impersonated. Data encrypted to — and intercepted by — the true owner of this bogus key would then be in the wrong hands, and the imposter could post messages or send e-mail that appeared to come from the impersonated individual.

In a public key environment, it is vital that you are assured that the public key to which you are encrypting data, or which you are accepting signatures from, is in fact the public key of the intended recipient and not a forgery. You could simply encrypt only to those keys which have been physically handed to you. But suppose you need to exchange information with people you have never met; how can you tell that you have the correct key?

Digital certificates, or certs, are a form of credential that simplify the task of establishing whether a public key truly belongs to the purported owner. Certs consist of data that functions much like a physical certificate and includes information with a person's public key that helps others verify that a key is genuine or valid. Digital certificates are used to thwart attempts to substitute one person's key for another.

A digital certificate consists of three things:

• A public key.
• Certificate information about the owner of that key ("identity" information, such as name, e-mail address, and so on).
• One or more digital signatures by other parties attesting to the validity of the key and its identifying information.

Thus, a certificate is basically a public key with one or two forms of "ID" attached, plus a "seal of authenticity" from some other (hopefully trusted) individual or organization.

Certificates are utilized when it's necessary to exchange public keys with someone else. For small groups of people who wish to communicate securely, it is easy to manually exchange diskettes or e-mails containing each participant's public key. This is manual public key distribution, and it is practical only to a certain point. Beyond that point, it is necessary to put systems into place that can provide the necessary security, storage, and exchange mechanisms so coworkers, business partners, or strangers could communicate if need be. These can come in the form of storage-only repositories called key (or certificate) servers, or more structured systems that provide additional key management features such as issuance and revocation, and are called Public Key Infrastructures (PKIs). If the PKI has a person or persons responsible for authenticating all the keys administered in their PKI, they are knows as Certification Authorities (CAs), a term you may encounter. Most organizations that will be making use of PGP on a frequent basis should designate a CA and create a PKI (and internal key server and key administration responsibilities), rather than simply rely on the public key servers. Individuals making infrequent use of PGP are probably best served by the public key servers and individual verification of keys (e.g. if someone you need to communicate with has sent you their public key you might call them on the phone and have them verify the PGP key fingerprint of the key they sent you, so that you know it is genuine.)

Validity and Trust

Every user in a public key system is vulnerable to mistaking a phony key (certificate) for a real one. Validity is confidence that a public key certificate belongs to its purported owner.

Public key servers around the world often synchronize with one another. This process, combined with the ability to tell PGP that you completely or partially (or do not) trust, on an individual basis, the signatures that others have used to certify the keys of third parties, has led to the evolution of the "PGP Web of Trust". You can download a public key from a keyserver, see who has signed it and decide whether to trust that key's validity based on those signatures (or even the signatures on the keys of the signers, and so on). If your organization has a PKI and a CA, you can also derive trust from that source (though only for your organization's keys; your CA will probably not be authenticating keys originating from outside).

When you've assured yourself that a certificate belonging to someone else is valid, you can sign the copy on your keyring to attest to the fact that you've checked the certificate and that it's an authentic one. If you want others to know that you gave the certificate your stamp of approval, you can export the signature to your own PKI and/or to a public key server so that others can see it.

In short there are three forms of trust in public key cryptography:

• Direct Trust — trust in yourself that you have correctly certified as valid the key that an invidual has told you is theirs (e.g. by calling and validating the key fingerprint)
• Hierarchical Trust — trust that your CA is competent and honest and is correctly certifying keys that are issued by your organization's PKI.
• A Web of Trust — the trust that the various people who have signed someone's key as valid are not all lying or imposters; the more signatures on a key the better, and th emore signatures those signers have on their own keys the better, especially if some of them are people known to you directly and trusted by you.

For More Information

For more detail on how to use PGP/GPG, where to obtain the software, technical troubleshooting, and various frequently-asked questions, please visit our NGO Security Team FAQ at:
http://www.cryptorights.org/operations/pgp-help-team/faq.html