The following assumes "gpg" is in your $PATH. If you're using a unix of some sort and have GnuPG installed, this is almost definitely the case. In windows, you either need to add it to your path, or instead of "gpg" type "C:\Program Files\GnuPG\gpg.exe" (you'll need quotes since it has a space in it).
Using the gpg utility, create your key.
$ gpg --full-generate-key
gpg (GnuPG) 2.2.5; Copyright (C) 2018 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Please select what kind of key you want:
(1) RSA and RSA (default)
(2) DSA and Elgamal
(3) DSA (sign only)
(4) RSA (sign only)
Your selection?
Note that on some versions of GnuPG the option is --full-gen-key.
I recommend selecting RSA and RSA (1) here.
Advanced note (feel free to skip): In newer PGPs you may see NISTP, and others. These are elyptic curve algorithms that should allow equivalent or greater security with smaller key-sizes. While the math is promising, they are new. Since 4K RSA keys are no where near being vulnerable at this time, I still personally recommend 4K RSA keys.
Select 1, and you'll see:
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (3072)
You should type "4096" here.
Requested keysize is 4096 bits
Please specify how long the key should be valid.
0 = key does not expire
<n> = key expires in n days
<n>w = key expires in n weeks
<n>m = key expires in n months
<n>y = key expires in n years
Key is valid for? (0)
If this is your first key, I'd recommend choosing 1 year for your expiration date. This way lost passphrases, forgotten keys, etc. all get expired. However, if you use PGP regularly, having a key that doesn't expire isn't unreasonable as long as you generate a revocation cert you store somewhere separately! So pick 1 year:
Key expires at Tue Sep 10 13:48:16 2014 PDT
Is this correct? (y/N)
Obviously, say y, and then:
You need a user ID to identify your key; the software constructs the user ID
from the Real Name, Comment and Email Address in this form:
"Heinrich Heine (Der Dichter) <heinrichh@duesseldorf.de>"
Real name:
It will ask for your name (you know that one, right?), and your email (again, not something I can help you with), and a "comment." I always leave the comment blank as I don't find it useful and it makes the key ID very long. If you'd like, you can use this field to differentiate different keys - i.e. your work key and your personal key. Anyway, when you've filled in that info, you'll see:
You selected this USER-ID:
"Foo Bar <foo@bar.com>"
Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit?
If you made a mistake you can choose one of the options to fix it, otherwise choose O for Okay, and it will ask you to generate some randomness by typing random keys and moving the mouse around. You should do this. It may seem silly, but cryptography requires good entropy (a.k.a. randomness).
When generating a key it's prudent to also create a revocation certificate which you store in a safe place. The revocation certificate will allow you to revoke a key that you lose (thus the certificate should be stored separately from the key), gets compromised, or you forget the passphrase to. To do this:
$ gpg --output revcert.asc --gen-revoke foo@bar.com
sec 4096R/BEEFF00D 2013-09-05 Foo Bar <foo@bar.com>
Create a revocation certificate for this key? (y/N)
Select y and you will be asked to provide a reason.
Please select the reason for the revocation:
0 = No reason specified
1 = Key has been compromised
2 = Key is superseded
3 = Key is no longer used
Q = Cancel
(Probably you want to select 1 here)
Your decision?
Since this is a pre-generated revocation certificate, you probably want to select 0 for "No reason specified" and it will let you provide extra information. Should you have access to the key and want to revoke this key later, you can always generate another revocation certificate. Enter in a description at the prompt, and end with an extra empty line:
Enter an optional description; end it with an empty line:
>
You will be given one final chance to bail out:
Reason for revocation: No reason specified
test
Is this okay? (y/N)
GnuPG will then ask for your passphrase:
You need a passphrase to unlock the secret key for
user: "Foo Bar <foo@bar.com>"
4096-bit RSA key, ID BEEFF00D, created 2013-09-05
Enter passphrase:
And some final information about your revocation certificate will be printed.
ASCII armored output forced.
Revocation certificate created.
Please move it to a medium which you can hide away; if Mallory gets
access to this certificate he can use it to make your key unusable.
It is smart to print this certificate and store it away, just in case
your media become unreadable. But have some caution: The print system of
your machine might store the data and make it available to others!
Your revocation certificate is now in revcert.asc, put it some place safe!
There are two files that come into play when it comes to choosing your keyserver and how you interact with it. These files are in the GnuPG configuration directory (~/.gnupg/ in unix-like OS's, or in %home%\Application Data\GnuPG\ for Windows).
The first is gpg.conf where you specify what keyservers and any options about when to use and what data to accept from them. I currently have this setting:
auto-key-retrieve
keyserver hkps://hkps.pool.sks-keyservers.net
keyserver-options no-honor-keyserver-url include-revoked
The hkps.pool.sks-keyservers.net pool is the only pool I've found that actually gaurantees SSL (hkps). Since the keyservers all sync, any keys you push to it, should make their way to all the others, but it's nice to know the keys you search for aren't trivially snoopable. In addition, I've passed in a few keyserver-options for additional safety. The first, no-honor-keyserver-url tells GnuPG to ignore the "preferred server" URL in a key when refreshing or verifying keys. The second, include-revoked wil return revoked keys when searching for keys. Finally I have a top-level config auto-key-retrieve which will automatically pull keys whenever signature. If you turn this on, it's especially important to have no-honor-keyserver-url if you'd like not to be tracked.
The second file is dirmngr.conf which controls dirmngr the process that actually handles keyserver interactions.
hkp-cacert /usr/local/share/ca-certificates/sks-keyservers.netCA.pem
allow-ocsp
The first line tells dirmngr where to find the CA file for the SKS servers so it can properly validate them and the second tells it to do OCSP validation on the certs.
Go into the interactive edit-key menu for your key:
$ gpg --edit-key foo@bar.com
gpg (GnuPG) 1.4.1; Copyright (C) 2005 Free Software Foundation, Inc.
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions. See the file COPYING for details.
Secret key is available.
pub 4096R/BEEFF00D created: 2013-09-05 expires: 2014-09-05 usage: CS
trust: unknown validity: unknown
sub 4096R/DEADBEEF created: 2013-09-05 expires: 2014-09-05 usage: E
[ unknown] (1). Foo Bar <foo@bar.com>
Command>
Type in the command trust and it will prompt you:
Please decide how far you trust this user to correctly verify other users' keys
(by looking at passports, checking fingerprints from different sources, etc.)
1 = I don't know or won't say
2 = I do NOT trust
3 = I trust marginally
4 = I trust fully
5 = I trust ultimately
m = back to the main menu
Because this is your key (and you should verify that it is your key by ensuring it's your name and email above), you should choose ultimate. You shouldn't trust anyone else's key ultimately. In fact, setting explicit trust like this is rarely done for keys other than your own. See the page on PGP trust for more info.
Anyway, after you type 5 and answer y to confirm, you'll be back at the command> prompt and you can type quit to exit.
$ gpg --send-key KEYID
Replacing KEYID with your keyid. You can find your keyid with gpg --fingerprint foo@bar.com and taking the number after 4096R/. You now have a key - people can send you encrypted email and verify your signed email among many other benefits!