You should normally use the default key type, DES + ElGamal. The passphrase can be long, so it should be easy to come up with something that's meaningful to you and easy to remember. The usual hints about using passwords apply: no simple dictionary words, nothing that someone who knows enough about you will think of trying, etc.
It's probably best for the key not to have an expiration date, unless you do plan to regularly change the public key. Even if there is no expiration, a key can be later revoked, i.e. marked as no longer used.
The default key size of 1024 bits is suitable for most users, but if you are worried that codebreaking technology will advance faster than we expect, or if you plan to use the keys to guard something truly important, you may want to choose 2048 (the tradeoff is somewhat slower processing).
The message about doing something while "entropy is generated" can be safely ignored. It takes quite a while for the key pair to be generated. You will also be asked to sign (certify) the new key yourself.
pub 1024D/8D81599D 2002-08-01 Eric Behr <email@example.com> sub 1024g/C87C359C 2002-08-01This describes your public key, whose unique ID is 8D81599D. The second line represents a "subsidiary key". There may be many of those attached to the master key, e.g. when other people start certifying your public key.
If you do gpg --list-secret-keys, you should see the listing of your secret keyring (which should now contain the same key IDs).
It's time to let the world know about this (if that's what you wish). The keys are stored in efficient binary form on your keyring, which makes it hard for humans to handle them. You can generate a text version of the public key as follows: gpg --armor --export your_key_ID (instead of the key ID such as 8D81599D you can also use the associated e-mail address, or even just the name; if there is ambiguity, the software will ask you which key you have in mind).
In most commands the --armor option tells gpg that you want the result to be in readable ASCII (suitable, say, for including it in a plain e-mail message), as opposed to a binary format.
This will print out something like this. It can be placed on your web page, given to friends, submitted to a "keyserver" such as www.keyserver.net or pgpkeys.mit.edu (just paste the whole text into the window), etc.
To verify a key it's best to first generate a "fingerprint" of the key you imported, with gpg --fingerprint bobs_key_ID. This will spit out a string of hex digits such as 96CA 01D9 600C A35C 0286 7438 ECD6 2C4C AD86 58C3. You can now call Bob at home and (assuming you recognize his voice ;-) ask him to generate the fingerprint of his secret key, e.g. with gpg --fingerprint --list-secret-key bobs_keyID. The two should match exactly. You can now be confident that Bob's key that you have on the keyring is authentic. You might decide to sign it with gpg --sign-key bobs_keyID, then export the ASCII version of Bob's key and send it to him, or submit it to a keyserver. This way people who already trust that they have your authentic key, and trust you as a person, may choose to trust Bob's key without further validation.
All this sounds quite paranoid, but remember that in this area the confidence in the process can only be as strong as the weakest link in it.
If you add the option --armor in the above command, the resulting text file will be called file_name.asc, and can be simply pasted into a mail message rather than attached.
You can also use the option --sign in such a command; in this case you will have to provide your passphrase, and the resulting message will contain the additional data telling Bob that it was indeed you who sent the message (assuming that Bob has your public key on his keyring).
There are situations when you don't have any specific recipient in mind, but you would still want to sign the data; for example, when you are sending an announcement to a mailing list or a newsgroup, and you want the skeptics out there to be able to verify that it's indeed from you. You can then do gpg --clearsign file, and a file.asc will be created, with the original message sandwiched between the components of the signature (this should only be done with ASCII files). The result can be sent as a regular letter by e-mail. To sign a binary file, such as a Word document or an executable program, simply do gpg --sign file, and the resulting file.gpg will contain the original along with a signature. You can then mail it as an attachment or post it on a Web page, and whoever receives it will be able to verify that it originated with you (and to check the integrity of the restored file at the same time). In some countries such digital signatures already have a full legal status, just like ordinary ones.
Finally, gpg can be used to perform the old-fashioned encryption of your own files. If you are worried about prying eyes of the system administrator, or that some other user might get at sensitive data because of improperly set permissions, you can use gpg --symmetric file to do it. You will be asked for a passphrase again, but this is completely separate from the one you chose to protect your secret PGP key, so it may be wise to use a different one in case one of these secrets is somehow compromised.
One example of when I use this is when I create a public key. If it so happens that I forget my GNUPG passphrase, or if a disk crash or system update wipes out my secret key, I want to be able to "revoke" or invalidate my old public key and start from scratch. But I can't do that without the secret key or passphrase! So after generating a public key, I also generate a "revocation certificate" for it, even though I plan to use the key for quite a while. This is done with gpg --armor --gen-rev keyID, which produces PGP data indicating that this key should no longer be used. When it is submitted (like any other PGP information) to one of the keyservers, they will mark my public key as expired. It's a good idea to have one of these lying around.
So far so good, but if I store this "just-in-case" revocation somewhere, it can somehow fall in the wrong hands, and the evildoer will all of a sudden be able to revoke my perfectly valid public key simply by pasting the revocation certificate into one of the keyservers.
The damage done this way to a typical user isn't great, but it can lead to confusion and some hassle (you have to redistribute the new public key and rebuild the "trust network"). So to avoid this I store the revocations in a form that is encrypted using the --symmetric flag, with some easily remembered simple password, just to make the evildoer's job harder.
We don't (yet) have a newsreader which would have a similar feature.
Also, wherever it makes sense, the --armor flag will produce ASCII rather than binary output; the --sign option will let you sign the message; the -v or --verbose flag provides more details on what's going on; and the --output option will let you choose a non-default filename for the result.
generate a new secret key: gpg --gen-key listing keys, with fingerprint: gpg --fingerprint --list-keys exporting cleartext public key to an ASCII file: gpg --output file --armor --export firstname.lastname@example.org signing someone's public key with your secret key: gpg --sign-key keyID importing keys from file: gpg --import file encrypting a file (you must have the recipient's key on the keyring): gpg --encrypt --recipient email@example.com file (then e.g. mail as an attachment) decrypting a received file: gpg --decrypt file encrypting with a symmetric (non public) cipher: gpg --symmetric file (best to use a different passphrase than the one for private key) this produces file.gpg; then decrypt it simply with gpg file.gpg signing a text file (e.g. for mail), output in file.asc: gpg --clearsign file signing a file (binary output in file.gpg): gpg --sign file verifying a signed file without unpacking the original: gpg --verify file creating a detached signature (file unchanged, signature in file.sig): gpg --detach-sig file verifying a detached signature of a file: gpg --verify file.sig