[ Index ] [ Anonymity ] [ Privacy ] [ Security ] [ Search ] [ Feedback ]

Why should I sign my own public key?

All things described below were confirmed using PGP 2.6.3i (32 Bit).
If your PGP behaves differently, please let me know.

All comments welcome

Why talk about self-signing?
Can anyone manipulate my user IDs?
What does signing do to a key?
How do denial of service attacks work?
Why does signing protect my user IDs?
5.1 Keys on a personal computer
5.2 Keys on a public key server
Do we need safer public key servers?
Does a self-signed user ID certify the key owner's identity?
Any arguments against self-signing?
Self-signing a new key or additional user IDs
How do I self-sign my user IDs?
How can I check a user ID?
Summary
References
Thank You' s

1. Why talk about self-signing?

A major advantage of public key encryption systems such as PGP is the fact that keys can easily be made available to everyone. Secure channels are not required for key distribution. However, a PGP user must be sure that the public key she obtained really belongs to the person she wants to send encrypted mail to. If a key's user ID was signed by a trusted person, it can be considered a valid user ID.

It is often recommended to self-sign all user IDs. However, Phil Zimmermann's PGP documentation (1) does not describe this procedure, but it is recommended in the PGP FAQ (2) as well as in several web publications (3, 4,5). The purpose of this article is to provide a comprehensive explanation of topics related to self-signing PGP public keys and thereby focus on problems that have not been addressed in the PGP documentation or the FAQ. I hope that avoiding technical terms makes it easy to grasp.

2. Can anyone manipulate my user IDs?

There is no PGP command to change a user ID. You can only delete (-kr) an ID or add a new one (-ke). Whereas deleting an ID does not require the secret key and passphrase, adding a new ID with PGP can only be carried out by the key owner. Unfortunately there is an 'unofficial' way to change someone's user IDs and PGP is even not required. This sort of attack ('denial of service'), which I will not describe in detail, takes advantage of the fact that user IDs in keyrings are not encrypted.

An example. John's key looks exactly like this (pgp -kvv):

Type Bits/KeyID    Date       User ID
pub  1024/ABCD1234 1996/01/01 John Harmless <john@company.com>

For an attacker it would be no problem at all to change it to

Type Bits/KeyID    Date       User ID
pub  1024/ABCD1234 1996/01/01 John Harmless <john@network.net>

When you tell PGP to add this bogus key to your key ring, it will unhesitatingly do so. If the original key ID ABCD1234 was in your keyring before, PGP does not replace but add the phony address as a new user ID:

Type Bits/KeyID    Date       User ID
pub  1024/ABCD1234 1996/01/01 John Harmless <john@company.com>
                              John Harmless <john@network.net>

3. What does signing do to a key?

A signature provides a certain level of trust, that a given key was generated by the person it claims to be from. That's what the signer certifies. Actually the signer doesn't sign the 'key' but the key owner's user ID (or one of the IDs if there are more). When a key is signed, PGP calculates a digest of some information that is unique to the signed key. This digest is called the MD5 hash, which is something like a cryptographically secure 'checksum' that represents the hashed information. As raw material for the MD5 hash PGP takes information from the RSA public key, the user ID string to be signed and other things. The MD5 hash then is encrypted with the signer's secret key and the resulting information written to the relevant user ID as a digital signature. No one can forge a signature unless s/he possesses the signer's secret key. When displaying or checking signatures (-kvv, -kc, -ka), PGP looks for all signer's public keys in pubring.pgp. If it does not find one of this keys, it can neither display nor check the signature. Since a digital signature contains unique information about the signer and the signed user ID, manipulation of both can be detected by PGP. Therefore signing is a prerequisite to enable PGP to identify a phony user ID.

4. How do denial of service attacks work?

If the attacker owns the phony e-mail address in John's key ID and distruibutes the manipulated key widely, it's possible that s/he intercepts part of John's mail. If the intercepted messages were encrypted with John's key (even with the modified one), the attacker will not be able to decrypt it but at least s/he has withheld the information. This is called denial of service and can also be achieved by generating and distributing an entirely new key in John's name. However, it is most unlikely that this 'imitation' will bear John's real KeyID:

Type Bits/KeyID    Date       User ID
pub  1024/0987DCBA 1996/01/01 John Harmless <john@company.com>

A certain type of attack (known as the 'dead beef' attack, first decscribed by Paul Leyland) can be used to tamper with a key in such a way that it will not only display a phony user ID but also someone else's key ID (6). Since this type of imitation key will have a different fingerprint, PGP's -kvc option can be used to unveil the attack.

5. Why does signing protect my user IDs?

When a signed user ID has been tampered with, PGP will beep and display a **** BAD SIGNATURE! **** message when this key is added to your keyring. The same warning will appear when the signature is checked with PGP's -kc option. The decrypted MD5 hash does no longer match the user ID string, which should alarm you to reject the key and inform it's owner.

5.1 Keys on a personal computer

Everyone can remove user IDs and signatures from keys in his public keyring and a matching secret key or passphrase is not required. Before changing a user ID, the intelligent attacker will remove all signatures. Therefore signatures cannot prevent this sort of attack!

5.2 Keys on public key servers

Keys on public key servers can be modified by everyone. An attacker or joker might want to download a key, change a particular user ID and resubmit it to the server, thereby adding a new ID to this key. Of course any message can be transported this way, even nasty things like 'Don't use this key any more', 'This key revoked', 'John Harmless is a fool', 'My new mail address is....' and so on. The key server (currently) does not check the sender's identity. As opposed to keyrings on personal computers nothing can be deleted on key servers. Therefore even the key owner will not be able to remove bogus IDs or a joker's signature. Since the attacker cannot forge the key owners signature, all unsigned user IDs should be considered suspicious. Never rely on an e-mail address or message in such an ID. Even if an ID was signed by someone you don't know, it does not make the ID more valid. The attacker could have created one or more keys for that purpose and signed the fake ID himself. A known and trusted signature wil l provide sufficient evidence, that a user ID was added by the key owner, provided that the signature passes a -kc check. In order to verify user IDs, self-signatures are preferable for two reasons:

additional public keys are not required to check them (-kc)
only by checking a self-signature you can find out for certain that a particular user ID was undoubtfully added by the key owner

Self-signing all user IDs therefore is recommended particularly for keys that are intended for submission to a public server. Unsigned IDs always should be considered to be of doubtful quality.

6. Do we need safer public key servers?

Public key servers play an important part prominently in making keys available to the PGP community. That's why they were brought into being. The server software was developed to enable key storage and distribution. Unfortunately there are some individuals out there that take advantage of the fact that key servers cannot protect keys from being tampered with. At present programmers of key server software improve the performance and security of public key servers (7). They are nearing completion of new versions with features that can avoid key manipulation. Marc Horowitz and Jeffrey Schiller (jis@mit.edu) at MIT recently re-implemented the "current" email based key server, using C instead of perl, and using C instead of PGP to manage keys. The new server is oriented around doing things faster. Currently it doesn't do any additional checking over what the old server did. Michael Graff (explorer@flame.org) is working on a "2nd Generation" key server, based on a DNS style distributed & delegated systems. This server will provide more security (among other things). Important "2nd generation features" are:

The server will be a distributed server. Each server knows only a subset of the keys.
To get a key in initially, M. Graff plans on sending out a message to the email addresses on the key (or to the submitter if there is no email address in any UserID) and require that they decode a magic string of random characters and mail that back to actually 'enable' the key in the server database. This will require that they have the key in question, as well as know how to use it. It should also help remove problems when someone submits a bogus key.
Only the owner of the key, the site admin, or someone else the site admin delegates will have the ability to change a key in the database. Key updates can only be submitted by the key owner. All that needs to be done is a simple-clear signing of the change request and the server checks the signature.
An update will be a total replacement, so the owner of the key decides exactly how it will appear.

We dont't have the next generation key servers yet. To add, update, or sign someone's key on a server is extremly unwanted unless she has given permission to do so.

There is a commercial key registry in operation at Four11 (SLED) Directory Services where only the key owner, using his private key, can update a public key. Old keys are purged. Only keys certified and signed by Four11 will be made available on their key server (8).

7. Does a self-signed user ID certify the key owner's identity?

No, a self-sig isn't a knot in the web of trust! If you don't know the key owner personally, only a signature from someone you know (and trust) can verify that a key belongs to the person it claims to be from. If the whole key is counterfeit, the attacker might have signed it with the matching secret key:

pub  1024/0987DCBA 1996/01/01 John Harmless <john@network.net>
sig       0987DCBA             John Harmless <john@network.net>

Although having been self-signed, this is not John's key!

8. Any arguments against self-signing?

"I never use keys unless they have a signature of a trusted friend. Therefore self-signing makes no sense to me. Self signing a key is a waste of space and only encourages false confidence."

If you are a security 'hardliner' you are suspicious about any key. If a key falls through your web of trust, you reject it and never send encrypted messages to it's owner. But...do you send clear text instead? Or do you refuse at all to communicate to unknown people? Most PGP users around the world encrypt messages to unknown people once in a while. Mostly they use keys that they cannot verify. A self-signature at least is a proof that a user ID has not been tampered with. Key servers have not been set up to serve as e-mail directories. When you send mail to someone unknown and you take her address from a reliable source, the worst that is likely to happen is that she cannot decrypt your mail, because you used a bogus key. Of course the receipient will inform you and next time you will use the correct key. E-mail should always be encrypted, even messages to an unknown recipient whose key can't be verified. There is no harm in it that I can see. Untrusted keys, even though you don't know whose they are, are s till useful. You don't know who is at the other end of e-mail either, and as long as they're the same person (or are verified in similar ways), the key is at least as secure as the conversation would have been without encryption, and is probably moreso.

9. Self-signing a new key or additional user IDs

When you generate an new key in your name and you already have a trusted one that was signed by other people, you can sign the new key's user ID with your trusted secret key. For those PGP users that have your old key this signature will provide the same level of trust for your new public key as all the sigs under the old one.

The same applies to a new user ID. If the old one has trusted signatures, your own sig under the new ID provides the same level of trust. It will serve as an introducer to the new user ID. Asking your friends to sign again is unnecessary.

10. How do I self-sign my user IDs?

To self-sign one of your user IDs:

pgp -ks your_ID [-u your_KeyID] [your_Keyring]

This will add a signature created with the secret key for your_KeyID to your_ID in your matching public key. If yourID is your key ID (like 0xABCD1234), the signature will be added to your key's default user ID. If yourID is one of your user IDs, you will sign that particular user ID. If you don't specify your_Keyring, PGP assumes pubring.pgp to be your public keyring.

Example: John Harmless self-signs his user ID in pubring.pgp

pgp -ks "John Harmless" -u 0xABCD1234 The result is as follows:

Type Bits/KeyID    Date       User ID
pub  1024/ABCD1234 1996/01/01 John Harmless <john@company.com>
sig       ABCD1234             John Harmless <john@company.com>

The international version of (2.6.3i) self-signs all new user IDs by default, a feature that is not provided by MIT's PGP 2.6.2. The self-signing option in 2.6.3i can be controlled with an AUTOSIGN=OFF/ON statement in config.txt (9).

11. How can I check a user ID?

PGP will not detect forgery to a user ID unless the ID was signed either by the key owner or someone else. Only signed user IDs can be checked. With the -kc option PGP will attempt to decrypt the hashed material stored along with a signature using the signer's public key. Therefore this key is required to check a signature. If PGP does not find it in the specified keyring, it will display Unknown signator, can't be checked.

To check a user ID and it's signatures:

pgp -kc ["ID to be checked"] [your_keyring]

If "ID to be checked" is not specified, PGP will list and check all signatures in your_keyring. If "ID to be checked" is a user ID, only signatures for that particular ID will be checked. Therefore you should specify the key ID instead, like PGP -kc 0xABCD1234.

A signature check automatically provides a user ID check, because information from the user ID string was added to the hash function when the key was signed. Comparing the decrypted MD5 hash from the signature with the actually calculated one will expose forgery. When a user ID has been tampered with, you will hear a beep and see a warning:

pub  1024/ABCD1234 1996/01/01 John Harmless <john@network.net>
sig*      ABCD1234             John Harmless <john@network.net>
                               ****  BAD SIGNATURE! ****

Remove bad signatures (Y/n)?

PGP will remove bad signatures on request, but it cannot distinguish between bad signatures and bad user IDs. So take this message seriously. You might want to delete a 'bad signature' from someone you don't know anyway, but this does not solve the problem with a bad user ID! When a -kc check unmasks a bad user ID, not all of it's signatures are necessarily bad. Someone (probably the attacker himself) might have signed a user ID after it has been tampered with, which will generate a valid signature for the fake ID.

pgp -kvv does not provide a check. Signatures will only be displayed. The same goes for encrypting a message. When you specify a fake user ID for public key encryption, PGP will not warn you.

When adding a key to your public keyring (PGP -ka), PGP automatically performs a signature check. When it informs you about a bad signature, remove this key from your keyring immediately. You should also ckeck the key owner's e-mail address and tell him what happend.

12. Summary

At present public key servers play an important part prominently in making keys available to the PGP community. Unfortunately they don't protect our keys from attackers and net clowns. That situation will change, when the '2nd generation' key servers come into being.
Self-signing (as any signing) of key IDs is a measure to make denial of service attacks more difficult and is particularly recommended for keys which are intended for submission to a public key server. However, a signature cannot prevent the attack but it enables PGP to detect it.
A self-signature isn't a knot in the web of trust. It does not verify the key owner's identity but can be used to verify the key's user IDs and expose at least one kind of denial of service attack.
For someone who does neither know a key's owner nor the people that have signed his key a self-signature is even better than any unknown people's sig.
A self-signature under an additional user ID serves as an introducer to the new ID, if the old one has trusted signatures.

13. References

(1) PGP documentation: by Phil Zimmermann
http://www.ifi.uio.no/pgp/doc.shtml
(2) alt.security.pgp: Frequently Asked Questions: by Jeff Licquia, May 25, 1995
http/www.prairienet.org/~jalicqui/pgpfaq.txt (now defunct)
(3) Why Should You Sign Your Own PGP Public Key?: by Francis Litterio
http://world.std.com/~franl/pgp/why-sign-your-key.html
(4) EFH PGP Workshop: by Paul Elliott, Electronic Frontiers Houston
http://www.efh.org/pgp/pgpwork.html
(5) The Beginner's Guide to Pretty Good Privacy: by Bill Morton, Version 1.1, April 13, 1995
http://netaccess.on.ca/~rbarclay/bg2pgp.txt
(6) "Dead beef" attack against PGP's key management: Posting to alt.security.pgp of April 1, 1996
Raph Levien (raph@c2.org)
(7) Known future developments in PGP servers and related subjects: http://www.pgp.net/pgpnet/
(8) Four11 Directory Services: http://www.Four11.com/
(9) Differences in International PGP Version: by Ståle Schumacher
http://www.ifi.uio.no/pgp/diffs.shtml

14. Thank You 's (in no particular order)

I would not have been able to write this without the help and inspiration of others. A big thank you especially to Michael Graff, Arnoud "Galactus" Engelfriet, Dave Tweten, Seth Golub, Jeffrey Schiller, Harald Fuchs, Gavan Schneider and Nollaig MacKenzie.

Number of visitors: .

Last modified: 18 Jul 1997
Author: Walter Soldierer <Walter.Soldierer@t-online.de>
Comments: galactus@stack.nl
This document was generated with Orb v1.3 for OS/2.