Unfortunately there is no defense against this attack at this time. Future versions of PGP may try to handle this case. Because it is relatively easy to create a new key with the same key ID, the need arose for a cryptographically secure fingerprint of a key. This key fingerprint is unique and cannot be easily forged. This value can be used as a key verification string; if the userid, keyid, keysize, and fingerprint all match then a user is sure he or she has the correct key. Key fingerprints can be trusted because they are made with the same hash algorithm, MD5, that PGP uses for message integrity.

However, matching the numeric values on a key is not good enough to trust that key. It also becomes important to check the name on the key. Anyone can create a key that says that it belongs to the President; however, it is highly unlikely that any of those keys actually belong to the Commander in Chief. Therefore, you, the user, must use other means to validate the name on a key. How to validate a key is covered in the section, “The Web of Trust.”

PGP Key Rings

PGP requires users to keep a local cache of keys. This cache is called the user’s key ring. Each user has at least two key rings: a public key ring and a secret key ring. Each key ring is used to store a set of keys that are used for specific purposes. It is important to keep both key rings secure, however; tampering with a public key ring can cause you to incorrectly verify signatures or encrypt messages to the wrong recipients.

Public Key Rings

The public key ring stores all the public keys, userids, signatures, and trust parameters for all the parties with whom you communicate. Whenever PGP looks for a key to verify a signature or encrypt a message, it looks in your public key ring. This means that you have to keep their public key ring up to date, either by frequently asking communiques to update your keys, or by accessing the PGP Public Keyservers.

Trust parameters are stored in the public key ring, so it is not feasible to share key rings between people. Moreover, PGP does not handle multiple key rings properly, so creating a site-wide key ring to store keys is not easy to do with the current releases. This is a known bug in PGP. Until multiple key rings are supported in a future version, the best way to distribute keys is to use a keyserver. One security concern with public key rings is that a compromised public key ring can lead to false positive signature verification or, worse, encrypted messages for the wrong parties. An attacker could change the trust parameters that are stored in the public key ring, or change the actual key material stored therein. These attacks are described in detail in the section, “Public Key Ring Attacks.”

When it was designed, the key rings were meant to hold only a few keys of close friends and associates. Unfortunately, it is clear from current usage that this design assumption is limited. Many people keep their key ring full of keys for people whom they have never met and with whom they have never communicated. Unfortunately this can cause problems, mostly due to replication of information and the time required to access the key ring. The recommended procedure is to keep the key ring as small as possible, and fetch required keys as necessary from a keyserver or site-wide key ring.

Secret Key Rings

The secret key ring is where personal secrets are stored for PGP. When you generate a key, the parts that you must not divulge are stored in the secret key ring. The data that needs to be kept private is encrypted, so access to the secret key ring does not automatically grant use of its secrets. However, if an attacker can gain access to the secret key ring, he or she has one less obstacle in the way to forge signatures and decrypt messages.

Because secret keys are not transmitted between people, the only keys that are supposed to be on a user’s secret key ring are his or her own secret keys. Because secret keys are protected by a pass phrase, simple transmission of the contents of a secret key ring will not allow access to the key material.

It is not recommended to share a secret key between parties, although at times it might be required. In particular, when you have a secret key that belongs to an organization, it might be worthwhile for multiple members of that organization to have access to the secret key. This means that any single individual can act fully on behalf of that organization, however.

Sometimes it might be useful to have a secret key without a pass phrase. For example, it might be worthwhile to have a server with a secret key acting on behalf of a group of people. In particular, you could run an encrypted mailing list in which the mailserver has its own key, and has the public keys for all list members. List members encrypt messages in the mailserver’s key and mail it to the list. The list processor decrypts the message and then re-encrypts it for each list member using his or her public keys. At this point the list server could sign the message with the list key, but that is not necessary. In such a situation, where a server process needs access to a secret key, it is desirable to have no pass phrase on the key.

Because it is possible to have multiple secret keys on a secret key ring, PGP has an option to specify the userid of the secret key you want to use. Whenever PGP needs to choose a secret key to use, it will choose the first key on the key ring, which is usually the most recent key to be created. You can override this by supplying the userid to PGP using the -u option, and it will use the secret key that has the appropriate userid.