Introduction to GnuPG
- Public Key
- How it Works
- Alice and Bob...and Eve?
- Private Key
- Command Line
- Generating a Key
- Signing / Encrypting
- Validating / Decrypting
- Managing Keys (import, export, edit)
- Web of Trust
- 101 Uses
- RPM Files (no more trojans!)
- Tar balls (no more trojans!)
- Tools That Use GPG
- Enigmail (Mozilla Mail)
- GPA (Gnome)
- Key Signing
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 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)
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@gohan]$ gpg --encrypt --armor --recipient email@example.com test.file
This will create an ASCII armored and encrypted file called test.file.asc, and will encrypt the file
using firstname.lastname@example.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
[augie@gohan]$ gpg --export --armor email@example.com > 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
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
[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.
gpg --list-keys firstname.lastname@example.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 email@example.com
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:
- The key has been signed by enough valid keys, meaning:
The path of signed keys from the key back to your key is less than five steps.
- You have signed it personally.
- It has been signed by one fully trusted key.
- It has been signed by three marginally trusted keys.
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 firstname.lastname@example.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
How to sign your RPM packages?
It's very easy:
- edit ~/.rpmmacros and put something like this:
%_gpg_name John Smith < email@example.com >
( 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
- Techniques in Cryptography
- Mandrake Secure: Using GnuPG
- The GNU Privacy Handbook
Post talk notes:
(these are noteable things I discovered about GPG after I gave this talk.)
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 firstname.lastname@example.org