nblug : augie : gpg

Introduction to GnuPG

  1. Public Key

    1. History
    2. How it Works
      1. Alice and Bob...and Eve?
    3. Private Key

  2. GnuPG

    1. Command Line
      1. Generating a Key
      2. Signing / Encrypting
      3. Validating / Decrypting
      4. Managing Keys (import, export, edit)
    2. Web of Trust
    3. 101 Uses
      1. RPM Files (no more trojans!)
      2. Tar balls (no more trojans!)
      3. Email

  3. Tools That Use GPG

    1. Enigmail (Mozilla Mail)
    2. Evolution
    3. Mutt
    4. GPA (Gnome)

  4. Key Signing



Public Key

The History of Public Key Cryptography is somewhat subject to interpretation, but traditionally the story begins with Whitfield Diffie and Martin Hellman who in 1976 announced to the world a new way of encrypting data, the public key system.

How it works. The easiest example is that of message passing. Below you see a picture of Augie and Brad having a conversation, Augie sends Brad a message in plain text, and Brad responds back in plain text. But what Augie and Brad don't know is that evil Eric has been intercepting these messages, and reading them and forwarding them on to their recipient. He's even been altering some of the messages before he forwards them on makeing it seem like Brad is making nasty comments about Augie to Augie.



Now had Augie and Brad been utilizing Public Key Cryptography (or in this case because they are Linux geeks, GnuPG) all this mis-communication could have been adverted. Augie and Brad could have encrypted their messages before they sent them off, then even if Eric does intercept the messages he cannot read the messages. Also if Augie and Brad were not too concerned with keeping their messages hidden, but more concerned with verifying the identity of message's author they could have signed their own message before sending it out.



While the details of Public Key Cryptography are interesting, they are outside of the scope of this talk, for more information see the resources at the bottom of the page. Basically the process is this: Augie generates two keys a private key and a public, and Brad does the same. Augie and Brad then exchange public keys. Brad then composes a message to Augie, and uses Augie's public key to encrypt the message, upon receiving the message Augie can then decrypt the message using his private key. Augie then composes a message back to Brad, and now maybe Augie is no longer concerned with hiding the information he is sending he just wants to let Brad know he received the message. So after finishing his response Augie then signs the message with his private key, Brad can then check Augie's signature with Augie's public key. If everything matches up then Brad can be secure in the fact that this message did infact come from Augie.

The things to remember from the above parapgraph are these: you want everyone, and anyone to be able to have your public key, because it is your public key that people will use to encrypt messages to you. Your private key however should be kept in a secret place, and not be available to anyone but you. This is because your private key is the only key in the world that can de-crypt messages that have been encrypted with your public key. Also because you are the only one who has access to your private key it is then used to verify messages sent from you, if you sign them. Signing a message with your private key is like encrypting it, but in reverse for this process. Now the only people that can verify your signature are those people with your public key, which could be anyone.

Private key. It is this splitting of the key that makes Public Key Cryptography different from its older counter part, Private Key Cryptography (or symmetric key). Before public key crypto two people who wanted to have a secure conversation had to actually meet first, and exchange secret previously agreed upon keys. But now with public key crypto two people can have a secure conversation, but not previously have met. This system has amazing implications for a network of people who may be geographically remote from one another, but who still want to have a secure conversation, this is the basis for secure communication over the internet.


GnuPG

The Command line is the basis for this introduction, this is because if you can learn these simple commands on the CLI, then changing to a GUI will be easy.

The first step in our GPG journey is creating a key pair:

[augie@gohan]$ gpg --gen-key

You will be asked to select a key type and key length, in both cases the default is fine.

Please select what kind of key you want:
(1) DSA and ElGamal (default)
(2) DSA (sign only)
(4) ElGamal (sign and encrypt)
Your selection?

About to generate a new ELG-E keypair.
minimum keysize is 768 bits
default keysize is 1024 bits
highest suggested keysize is 2048 bits
What keysize do you want? (1024)

Some people choose their encryption algorithms like they do their flavors of Linux...with fervor. For most people the default option is fine. When choosing the key length you should note that a longer key size is more secure against brute-force attacks, but will also cause encryptions and decryptions to take longer, and may increase the size of your signature as well. So again for most people I think the default value is fine.

The next decision you need to make is the expiration date of your key. Some people like to set their keys to expire after a certain period of time, in this way if your key is ever compromised it will only be good to the thief for a limited ammount of time. The downside however is that you must express this key expiration to those that may have your key after the expiration date has passed. The default is that the key does not expire, for most users this is probably fine.

Please specify how long the key should be valid.
0 = key does not expire
= key expires in n days
w = key expires in n weeks
m = key expires in n months
y = key expires in n years
Key is valid for? (0)

Now you will be asked to give your key some identifiable attributes, like your real name, a comment about the key, maybe your nickname, or affiliation, and your email address. Afterwards you will come to the final step which is also the most crucial step in safe guarding your private key. You must choose a passphrase, and since the passphrase unlocks your private key, and is the only protection you have against someone being able to use your private key if they steal it, you better make it a good one. A good passphrase is a mix of upper and lower-case, alpha-numeric and non-alpha-numeric characters, as well as words that are not commanly found in a dictionary.

Signing and Encrypting is very easy to do, but there are a few options that you should be aware of. For example let's say i wasn't Augie, and I wanted to encrypt a document and send it to Augie.

[augie@gohan]$ gpg --encrypt --armor --recipient augie@nblug.org test.file

This will create an ASCII armored and encrypted file called test.file.asc, and will encrypt the file using augie@nblug.org 's public key on our key ring. The reason for using the ASCII armor option is that the file created is readable in plain-text, and is the appropriate way to encrypt something for email and viewing in a text viewer. If we had not armored it we would have created a binary file, and possibly some confusion for our recipient.

Sign a file with the command below:

[augie@gohan]$ gpg --clearsign test.file

The clearsign option ASCII armors the signed document which makes it easier for people to view in a text editor, or an email reader. If you had just used the sign option you would have created a binary file instead. This command creates a file called test.file.asc, the .asc extension denotes that it has been ASCII armored.

Another method of signing is the detached signature, which is useful when signing binary files such as tar ball's or rpm's.

[augie@gohan]$ gpg --detach-sign --armor test.file.tar.gz

This will create a detached ASCII armored signature called test.file.tar.gz.asc which may be used to verify the integrity of the original file.

Validating and Decrypting your files is of course the next logical step. Decrypting a file that has been encrypted with your public key is as easy as:

[augie@gohan]$ gpg --decrypt test.file.gpg

The default output is STDOUT, but you're a Linux geek right? So you know how to redirect that output as needed. Verifying a file, provided you have the signers public key, is similarly as easy.

[augie@gohan]$ gpg --verify test.file.sig

To verify a detached signature on a file you must provide the name of the signature file along with the file that has been signed.

[augie@gohan]$ gpg --verify test.file.sig test.file

Most of the above command line options have short-hand counter parts that you can find in the gpg man-page. I have used the verbose names for clarity here.

Managing keys. The above signing, encrypting, and verifying are all dependent on you having someone elses public key or someone else having your public key, so you will need to know a little bit about key management. The first thing you will probably want to do is spread your key across the virtual landscape.

[augie@gohan]$ gpg --export --armor augie@nblug.org > augie.asc

This creates an ASCII armored version of your public key (if you were augie), and redirects it to the file called augie.asc. This file is suitable to put on your public webspace or include as an attatchment in an email message.

You may also want to export your public key to a public key server, which is a central repository for everyone and anyone to have access to your public key.

[augie@gohan]$ gpg --send-keys --keyserver wwwkeys.us.pgp.net EB38CA03

Once you receive someone's public key, and you wish to hang on to that key, you will want to add it to you public key ring. As above this can be done directly or via a keyserver.

[augie@gohan]$ gpg --import augie.asc

OR

[augie@gohan]$ gpg --recv-keys --keyserver wwwkeys.us.pgp.net EB38CA03

You may see the keys on your key ring with gpg --list-keys , or if you are just interested in one persons particular key you can specifiy that after the option. (e.g. gpg --list-keys augie@nblug.org).

Now that you have this key, you may want to change it in some way. If it is not your key then of course you may not be able to change all of its attributes, however you may use the following command to edit your own key.

[augie@gohan]$ gpg --edit-key augie@nblug.org

This brings you to an interactive menu where you may perform some administrative tasks on your key ring. Type in "help" to see a list of options. Of interest will be "check", which lists all the signatures the key may already have, "sign" can be used to sign the key, "trust" can be used to change the level of trust you have for this key. The gpg man-page has a full listing of options including those that you can use to edit your own key.

Web of trust. The point of the web of trust is that it allows you to be able to trust people (and their keys) that you may have never met, thus allowing you to send and receive encrypted messages with that person, and feel safe that person is who they say they are. The easiest way to see how this works is by example. The image below shows that if I (Augie) trust Dustin, and Dustin trusts Brad, then by transitivity (i.e. proxy) I can trust Brad. So if Brad sends me a signed message I can be sure that the signature is valid and the message really did come from Brad. Going the other way though, if Kat and Frank trust Eric, but Eric doesn't trust me, then Kat and Frank don't trust me.



There are two ways to establish the trust of a given key:
  1. The key has been signed by enough valid keys, meaning:
  2. The path of signed keys from the key back to your key is less than five steps.

Now that you understand how trust works, it is time to learn how to assign trust using GPG. To assign trust to a key use the --edit-key command from the previous section followed by the identifing attribute of the key you wish to edit. Type in "trust" at the menu prompt, and you will be given four options for the level of trust you can assign to this key.

1 = Don't know (no opinion of the person behind the key)
2 = I do NOT trust (you don't trust the person)
3 = I trust marginally (you know the person, and trust them, but you havn't actually gone through the steps to validate that they are indeed the owner of that key)
4 = I trust fully (you know this person, and have validated their key personally)

When assigning trust it is a good rule of thumb to err on the side of paranoia. Your trust of a key not only affects you, but also affects those that trust you. But how do you decide what level of trust to assign to a given key? Typically if you have physically met the person and have exchanged keys, say at a keysigning party, and have validated their identity, you can assign that person the highest level of trust, trust fully. Other people feel secure enough in just exchanging keys over the phone, the downside to this though is that you must be sure the person behind the phone is who they say they are.

Once you fully trust someone it is benneficial to them, and the rest of the web of trust, to sign their key, remember only sign keys that you fully trust. To sign a key use the "sign" option from the --edit-key menu option. You will be asked to confirm your choice, and for your passphrase. After signing the key you will want to get it back to its owner, this is similiar to exporting your own public key.

[augie@gohan]$ gpg --export --armor somebody@nblug.org > somebody.asc

Now take somebody.asc and send it to its owner. When the owner receives the key they will import it like they would any other public key. After importing the owner will want to redistribute their newly signed key by exporting it again, and placing it on their public website, or on a keyserver, etc. When the new key is downloaded by other GPG users they will see your signature on the key, and that you fully trust the person behind the key. If they trust you fully then they will, by proxy, fully trust this key. If they only marinally trust you, but the key is signed by atleast two other marginally trusted idividuals they will, by proxy, fully trust this key. And that is how the web of trust works.

101 uses. GPG may not have 101 uses, but it certainly does have several very important ones, especially to developers. For instance you may use GPG to sign your packages, rpm, or tar, thus verifying the packages integrity, and hopefully help people avoid downloading trojaned packages. Below is how to use GPG to sign your RPM packages, it comes from the Mandrake cooker site (http://www.linux-mandrake.com/en/cookerdevel.php3).

How to sign your RPM packages?
It's very easy:

- edit ~/.rpmmacros and put something like this:

%_signature gpg
%_gpg_name John Smith < jsmith@linux-mandrake.com >
%distribution Mandrake
%vendor MandrakeSoft
( replace _gpg_name with your own GnuPG id! -unless you are John Smith :-) ) Now, every time you recompile a package, you need to enter the following command: rpm --sign -ba --clean file.spec (you will be prompted for your personal secret phrase).

To sign your tar packages use the --detach-sign option as shown in the Signing and Encrypting section above. This can be used in the same way as the RPM signing, to avoid trojaned packages of your software.

Securing communication such as email, and usenet postings is what the more casual user will be using GPG for. In this way you may secure communication between two parties, or use it to sign your messages so that your recipients will always know the message really did come from you. I prefer to sign all my messages no matter how small, because it creates a precedent, so that if now someone receives a message from me, and it is not signed they may consider it suspect. Also signing everything increases the visibility of GnuPG, and encryption in general.


Tools That Use GPG

Enigmail
(http://enigmail.mozdev.org/)

Evolution
(http://ximian.com/products/evolution/)

Mutt
(http://www.mutt.org/)

GPA
(http://www.gnupg.org/gpa.html)

Resources:

http://www.rsasecurity.com/rsalabs/faq/3.html - Techniques in Cryptography
http://www.mandrakesecure.net/en/docs/gpg.php - Mandrake Secure: Using GnuPG
http://www.gnupg.org/gph/en/manual.html - The GNU Privacy Handbook

Post talk notes:
(these are noteable things I discovered about GPG after I gave this talk.)

http://web.bham.ac.uk/N.M.Queen/pgp/art4.html

In contrast with PGP and with early versions of GnuPG, ultimate trust is not automatically assigned to your own public key - it must be set by the user. If no ultimate trust is set, the web of trust will not work, and GnuPG will report that the ownership of a key has not been validated even if you have signed that key with your own key.

If GPG is telling you that certain keys are 'untrusted' even though you have signed them yourself, then the above may be the solution. That is assign your own key the 'Ultimate' level of trust and rebuild the trust-db.

Author: August Schwer augie@nblug.org