PGP tutorial
Herein resides a brief (somewhat) tutorial on creating and signing PGP
keys with GPG. I'd originally intended to use this as the outline for a
presentation on the subject, but decided to put it on the web so I could
point people at it. The introductory section (Basics) is pretty lean, but
should provide enough of a background for simple stuff. All of this is
documented elsewhere on the web.
- Motivation
- I think that encryption should be an important part of any email
system.
- Much as I send regular mail in envelopes, not postcards, I prefer
to send email encrypted.
- In general, I think that everyone should be familiar with PGP for
personal privacy reasons
- In specific, I would, ideally, prefer never to send unencrypted
personal email.
- Basics
- Briefly cover encryption.
- Scrambles data so unauthorized people can't read it.
- Types of secrets
- Shared keys
- Simplest form of encryption.
- Some secret information (like a password) will both encrypt
and decrypt.
- public key systems
- There are two keys.
- Things encrypted with one of the keys can only be decrypted
with the other.
- Cannot tell by looking at one key what the other one is.
- Keep one key secret and make other public.
- Anyone can get public key and encrypt stuff for you. Only you
can decrypt.
- Signing
- Related to encryption
- Signing takes some information and creates a "signature" from
it.
- The signature is a block of data that can be used to verify the
origins of the signed information, much like a written signature on
a document.
- Usually used in PKC.
- Example: Send an email, sign with private key. Someone receives
it and checks signature with your public key. Only your public key
can properly decipher the signature, so, if it does, it must have
come from you.
- PGP
- Stands for Pretty Good Privacy
- Not perfect, but good enough for most people.
- Uses a public key system.
- Keys represent a name and email address.
- GPG
- Stands for GNU Privacy Guard
- Is a Free (open-source) implementation of the OpenPGP
standard.
- Interoperates with PGP 2.x and 5.x.
- This tutorial will cover gpg. Concepts will apply to PGP
versions, but all the commands are gpg-specific.
- Making a key.
- First, install gpg.
- Package in Debian is named gnupg.
- I don't know about packages for other distributions (other than
that they exist).
- If you want to compile from source, it's at
http://www.gnupg.org/.
- As your normal user, run '
gpg --gen-key'.
- First question is the type of key to make. The default choice
(DSA and ElGamal) is ok.
- [skip for presentation]
- DSA key is used for signing things. It cannot be used to
encrypt.
- ElGamal is the encrypting key. It's not as good at signing as
DSA is because the signatures end up larger and it may be easier
to attack an ElGamal signature.
- Paranoid people may wish to use RSA for signing, because
maximum size on a DSA key is 1024 bits. In this case, the
encryption key will have to be added afterwards.
- Next question is about the size of the ElGamal key. Again, the
default (1024 bits) is decent.
- [skip for presentation]
- The larger the key, the harder it is to brute-force the
encryption. (i.e. try every possible key and see which one
decodes the message.)
- 1024 bits is currently considered a reasonable size.
- The minimum is 768, which isn't really recommended for
anything other than casual use. It's probably not safe from
anything larger than a medium-sized business.
- 2048 is the highest recommended size. Every bit doubles the
keys available, so 2048 is roughly 1.79e309 times harder to crack
than a 1024 bit key.
- (I wanted to write out that number, but it would have been
17.9 followed by 25 millions (i.e. 17.9 million million million
...).)
- A key size of 2048 would be used for stuff that you would
never want to be decrypted, even decades (and quite probably
centuries) after your death. Most people a) don't need that sort
of security and b) are insecure enough in other ways that it
wouldn't matter anyway.
- Keys larger than 2048 bits are not recommended because using
them would be very slow.
- The next step is to choose the expiration date of the encryption
subkey.
- The default option (no expiration) is probably the best choice
for the average personal key.
- An expiration is useful to force people to change encryption
keys periodically. This means that even if one of your keys is
cracked, only a portion of your communications will be
compromised.
- Note that the expiration only applies to new uses of the key.
Items encrypted with a key before it expires can still be
decrypted with the related private key after the public has
expired.
- Next, you must enter your personal information.
- "Real name" should be fairly obvious. This should be at least
your first and last names. Nicknames are often acceptable if
they're unambiguous enough. Initials will probably not be
acceptable to most people who care about the name. Some uses may
require your full legal name.
- "Email address" should be equally obvious. Use your the main
email address from which you expect to be doing most of your PGP
work.
- "Comment" is a field for further clarifying the purpose of
this key. If, for example, you have both work and personal keys,
you could add a comment to each, indicating which is which.
- Note that any number of these may be omitted. You can specify
an email address with no name or vice-versa, if you feel it's
appropriate. (Note that some people may be unwilling to sign your
key in these cases.)
- Lastly, you need to enter a passphrase.
- The passphrase can (and should) be an actual phrase.
Generally, the longer the phrase is, the better, as it's harder to
guess that way.
- The passphrase should also, however, be something that you'll
remember and will be able to type easily. You'll have to find
your own balance between the two.
- After all of the information is entered, gpg will go about
making your keypair. Under Linux, it uses /dev/random, which is a
source of truly random data. (i.e. there is no way to predict ahead
of time what the data will be.) gpg will probably ask you to
generate entropy. Do as it asks (type on the keyboard, move the
mouse). Network activity (e.g. downloading files) helps, too.
- When that finishes, congratulations! You've created your own
personal keypair.
- To admire your new key type '
gpg --list-keys "<your
name>"'.
- The final step is to send your key to a public keyserver so that
other people can easily get it.
- The simplest method is just to run '
gpg --keyserver
<keyserver> --send-keys <key ID>'.
- The best keyserver to use is probably wwwkeys.pgp.net. The
others should synchronize to that one periodically.
- They don't always sychronize properly, though. the best
solution is to use recv-keys, a
script someone I know wrote to send (and receive) keys from every
keyserver.
- Signing keys
- Concepts
- Trust is an issue with keys. Presumably you put your own name
on the key you made, but you could just as easily have used someone
else's.
- What guarantee do you have that when you get a key claiming to
belong to, say, Phil Gold, that it's really from me?
- Personal introductions as an example.
- Suppose you had never met me before and someone walked up to
you and said he was Phil Gold. Would you believe him? (You
might. Further suppose that you were going to give me $100.
Would you give the money to this person based merely on his claims
about his identity?)
- On the other hand, if someone you trusted introduced me to
you, you'd probably be more likely to believe claims about my
identity.
- Public key signing works much the same way.
- A signature on a public key works much as a digital signature on
some other piece of information--it's a block of data created with a
private key that can only be verified with the corresponding public
key.
- The meaning is a little different, though. If you sign an
email, the signature is an indication that the email actually came
from you. If you sign a public key, the signature is an indication
that you will vouch for the identity of the key's owner.
- Example: I wish to converse with Nick. I get Nick's public key
from a keyserver, but I've had no personal verification that the key
really belongs to him. However, I also have Ray's public key and
I've verified its validity. I also trust Ray to sign keys. If Ray
has signed the key I downloaded, then I have a reasonable assurance
that the key really does belong to Nick, as it claims.
- NB: GPG is really flexible about trust. It has four settings
for your trust of the key's owner: full, marginal, none, and
unknown (which is the same as none). You can adjust the number of
full and marginal signatures needed to trust a key you haven't
yourself signed. For the record, I use the default settings (one
full or three marginal) but am very parsimonious with placing even
marginal trust in other people.
- Actually signing a key
- When you sign a key, you are declaring to the world that you
believe the key actually belongs to the person it claims to. Be
careful, then, in what you sign.
- Steps for verifying key validity.
- Talk to the person in a difficult-to-fake environment. Face
to face is best. Barring that, a telephone conversation is
probably good. Pretty much anything online is right out.
- Verify that the person is who they claim they are. This is
easy if you already know them or can be introduced by someone you
trust. Beyond that, you can check things like photo IDs and trust
them if you have trust in the issuing institution.
- Get the person's key information. You should get the person's
key ID and fingerprint.
- The key ID has been mentioned previously.
- The fingerprint is a number derived from the key
mathematically. It uniquely identifies the key, much as your
fingerprints identify you.
- NB: It is theoretically possible for two different keys to
have the same fingerprint. It is, however, statistically
very unlikely that this would happen. In addition,
there is no known way to create a key with a specific
fingerprint, which is why the fingerprint is a good method for
verifying keys.
- Go home.
- Once home, if you don't have the other person's key, get it
from the keyserver, either via recv-keys
or '
gpg --keyserver <keyserver> --recv-keys <key id>'
- Now that you have the key, check its fingerprint
- If the key ID and the fingerprint you were given match the
ones on your computer, you can be reasonably assured that you have
the right key.
- Once you've determined that the key is valid and belongs to its
claimed owner, you can actually sign it.
- The command to do this is '
gpg --sign-key <key
ID>'.
- GPG will show you the key information, including the key's
fingerprint. You can double check the information at this point
if you're being paranoid.
- Next, you'll be asked how careful you have been in your
verification of the person's identity. The default answer is
probably safe, but using the others as degrees of trust is useful,
presuming you have a set policy for signing keys.
- If you're going to use the different levels of
certification, you should use a policy URL. You may
look at mine for an example.
- Finally, GPG will ask you if you're sure. If you're certain
you want to sign the key, say yes then enter your key's
passphrase.
- After you've signed the key, you should send it to the OpenPGP
keyservers so that when other people get that key they'll get your
signature with it.
- Again, use of recv-keys is
recommended for sending the key, but '
gpg --keyserver
<keyserver> --send-keys <key ID>' will also
work.
- Note that the keyservers are smart about signatures. When you
send a key that the server already has, it will merge any new
signatures (and uids and revocations, but I haven't covered those)
into the existing key. Thus, two different people can grab a key
at the same time, sign their local copies, and send them back in
and the keyserver will end up with a single key with both
signatures.
- How to use your PGP key.
- Command line usage
- man page -- very "detailed", but the ultimate reference.
- encrypting files
gpg --encrypt <file>
- Will ask for recipients.
- If a recipient matches multiple keys, only the first match
is used.
- Result with be in
<file>.gpg and will be
binary data. Send that file to the other person.
gpg --recipient <person> --armor --encrypt
<file>
- Recipient on command line, so does not ask anything.
- Again, if more than one match, first match is used.
--recipient may be used multiple times to
specify multiple recipients.--armor creates file in ASCII text.- Result will be in
<file>.asc.
- decrypting files
gpg <file>
- Will figure out file is encrypted and attempt to
decrypt.
- Will ask for passphrase on your private key so it can
decrypt.
- Result will be
<file> with
.asc or .gpg extension removed.
- If file is ASCII-armored, gpg will extract the message, even
if there's other text around it. (So you can give it an entire
email and it'll ignore the email headers and such.)
gpg --decrypt <file>
- Same as above, but decrypted data is send to standard
output.
gpg --output <other filename> --decrypt
<file>
- Decrypts and puts result into file of your choosing.
- signing files
gpg --sign <file>
- Asks for your passphrase, then signs the file.
- Result is in
<file>.gpg and is in binary
format.
gpg --clearsign <file>
- Leaves text document readable and places signature in ASCII
text at the bottom.
- Result is in
<file>.asc.
gpg --detach-sign <file>
- Creates a file named
<file>.sig that
contains just the signature.
- Both the original file and the signature file are required
to verify the signature.
- verifying signatures
gpg <file>
- gpg will figure out that the file is a signature and verify
it.
- If the signature was a regular or clear signature, the
original file will be created, with a name based on
<file>, less the .gpg or
.asc extension.
- If the signature was a detached signature, the original file
must exist, with the same name as the signature file (without
the
.sig extension), and gpg will just tell you
whether the signature matches or not.
- [finding other people's keys]
- [~/.gnupg/options]
- MUAs
- mutt
- Support is integrated already. [in Debian; others need
additional stuff?]
- pine
- Mozilla/Netscape Navigator
- Eudora
- Outlook
- Avoid like the plague, if at all possible.
- Bad support for standards.
- Further information
That should about cover it. Please
email me if you have any questions,
comments, or suggestions about this tutorial.
Phil! Gold