 |
 |
GnuPG Gentoo user guide1. Introduction What you will get in this guide This guide assumes that you are familiar with public-key cryptography, encryption, and digital signatures. If this is not the case jump to Public Key Cryptography or take a look at the GnuPG handbook, chapter 2, and then come back. This guide will teach you how to install GnuPG, how to create your key pair, how to add keys to your keyring, how to submit your public key to a key server and how to sign,encrypt,verify or decode messages you send or receive. You will also learn how to encrypt files on your local computer to prevent people from reading their contents. Installation of required software At a very basic level you need to emerge gnupg. Many aplications today have some sort of support for gpg, so having gpg in your USE variable is probably a good idea. If you wish to have an email client capable of using gnupg you can use pine (emerge pinepgp), mutt (emerge mutt), Mozilla/Netscape Mail, evolution (evolution is a GNOME Microsoft Outlook work alike) and KDE's own KMail (KMail is part of the kdepim package). Kgpg might interest you if you use KDE. This small program allows you to generate key pairs, import keys from ASCII files, sign imported keys, export keys and a few more features. 2. Generating your key and adding keys to your public keyring To create your key, just run gpg --gen-key. The first time you run it, it will create some directories; run it again to create the keys:
Here you can choose the type of key you want to use. Most users will go for the default DSA and ElGamal. Next is the key size - remember that bigger is better but don't use a size larger than 2048 with DSA/ElGamal keys. Generally 1024 is more than enough for normal email. After size comes the expiration date. Here smaller is better, but most users can go for a key that never expires or to something like 2 or 3 years.
Now it is time to enter some personal information about yourself. If you are going to send your public key to other people you have to use your real email address here.
Now enter your key passphrase twice. It is a good idea to use a strong password. If someone ever gets hold of your private key and cracks your password, they will be able to send messages signed by "you" making everyone believe the mails were sent by you. Then, GnuPG will generate your key. Moving the mouse or having a mp3 playing in the background will help speed up the process because it generates random data. Generating a revocation certificate
After creating your keys you should create a revocation certificate. Doing this allows you to revoke your key in case something nasty happens to your key (someone gets hold of your key/passphrase).
The gpg --list-keys command lists keys in your public keyring. You may use it to see the ID of your key so that you can create the revocation certificate. Now it is a good idea to copy all the .gnupg directory and the revocation certificate (in ASCII armor - revoke.asc) to some secure medium (two floppy's or a CD-R you store in safe location). Remember that revoke.asc can be used to revoke your keys and make them unusable in the future.
To export your key, you type gpg --armor --output john.asc --export [email protected]. You can almost always use the key ID or something that identifies the key (here we used an email address). John now has a john.asc that he can send his friends, or place on his web page so that people can communicate safely with him. To add files to your public keyring, you must first import it, then check the key fingerprint. After you have verified the fingerprint you should validate it.
Now we will be adding Luis Pinto's (a friend of mine) public key to our public keyring. After giving him a call and asking him for his key fingerprint, I compare the fingerprint with the output of the fpr command. As the key is authentic, I add it to the public keyring. In this particular case, Luis's key will expire in 2003-12-01 so I am asked if I want my signature on his key to expire at the same time.
3. Exchanging keys with keyservers Now that you have your key, it is probably a good idea to send it to the world key server. There are a lot of keyservers in the world and most of them exchange keys between them. Here we are going to send Luis's key to the pgp.mit.edu server. This uses HTTP, so if you need to use a proxy for HTTP traffic don't forget to set it (export http_proxy=http://proxy_host:port/). The command for sending the key is: gpg --keyserver pgp.mit.edu --keyserver-options honor-http-proxy --send-key [email protected] . If you don't need a HTTP proxy you can remove the --keyserver-options honor-http-proxy. You can also send other people's keys that you have signed to the keyserver. We could send Luis Pinto's key to the keyserver. This way someone who trusts your key can use the signature that you have placed there to trust Luis' key. Now we are going to search for Gustavo Felisberto's key and add it to the keyring of John Doe (just in case you did not notice Gustavo Felisberto is the author this guide :) ).
As you can see from the server response I have a few keys submitted to the key server, but I currently only use B9F2D52A. Now John Doe can get it and sign it if he trusts it. 4. Working with documents Let's say that you have a file that you wish to send Luis. You can encrypt it, sign it, or encrypt it and sign it. Encrypting means that only Luis will be able to open it. The signature tells Luis that it was really you who created the file. The next three commands will do just that, encrypt, sign and encrypt/sign.
This will create binary files. If you wish to create ASCII files, just add a --clearsign to the beginning of the command. Decrypting and verifying signatures Suppose that you have received a file which is encrypted to you. The command to decrypt it is gpg --output document --decrypt encrypted_doc.gpg. This will decrypt the document and verify the signature (if there is one). There are some nice advanced features in GnuPG. To find them, open the ~/.gnupg/options file.
Search for the above two lines and uncomment them. With this any time GnuPG needs to check a signature and it does not find the public key on the local keyring it will contact the key server at pgp.mit.edu and will try to fetch it from there. Another nice command is gpg --refresh-keys. This will contact the keyserver defined in the options file and refresh public keys in your local key ring from there, searching for revoked keys, new id's, new signatures on keys. You should probably run this once or twice a month so that if someone revokes his key you will be notified. 5. GnuPG interfaces 95% of the time you will use GnuPG with email, signing/encripting your outgoing messages and reading signed/encripted messages. So it is only fair that i talk about that first. There are two ways two sign/encript a email with GnuPG, the old way and the new way :). In the old way messages would appear in plain text, with no possible formatting and attached files would be unsigned/unencripted, here is an example of a message signed the old way:
Messages this way are no good in todays world, where we have nice GUI's and email readers that understand html. To solve this an addition to the MIME (Multipurpose Internet Mail Extensions) was created. This adds a field to the email that tells the mail reader that the full content of the message is signed and/or encripted. The problem with this is that not all mail readers support this. And some even mess the content, Microsoft's Outlook is famous for not working with this. Kgpg is a nice GUI for GnuPG. In the main screen you can paste the text that you wish to sign or encrypt, and you can also paste the ASCII armored text that you which to decrypt.
In this image you can see the Kgpg main window with ASCII armored and encrypted text pasted into it. From here you can decrypt it (you will have to provide your password), encrypt other files, paste new text to sign....
Now you can see the key managing window. From here we see our good key for John Doe. The two trusted keys for Gustavo and Luis, and the untrusted key for Daniel Robbins ( I still have not given him a call to check his fingerprint :) ). Seahorse aims to be a GnuPG GUI interface for the Gnome desktop. The software has been evolving fast, but it still lacks many important features that can be found in Kgpg or the command line version. Mozilla's version from 1.0 or above comes with Enigmail, a plug-in for the email client that is pretty simple to configure. You just go to Preferences -> Privacy & Security -> Enigmail. There you enter your key email and thats it. Mails that come with an untrusted pgp or gpg signature will be marked with a broken pen. Others that have good signatures will appear with a nice straight pen. Enigmail even comes with the ability to get keys from keyservers, but if it has problems it will print some very weird messages (but you still remember how to use the command line, right?). Kmail is also pretty easy to setup. I will just post a few pictures on how to set it up. Basically you have to tell KMail to use GPG and then which key to sign with.
This is my email reader of choice. It is very fast with big mailboxes, has all the nice features one wants in mail readers and works pretty well with gpg. The only problem is that it does not work with the old PGP signatures, so when you receive those kind of mails you have to hand check the signatures. To use your gpg key with Sylpheed-Claws just go to the acount configuration and select the privacy tab. Once there just choose which key to use, probably most users will go with the default key. 6. Public Key Cryptography The concept of public key cryptography was originally devised by Whitfield Diffie and Martin Hellman in 1976. When I first heard the words "public key" and "cryptography" in the same sentence back in '93 I tought to myself that it would be impossible to do such a thing. In those days there was no Internet (well there was, but not for me) so I went to the public library and asked for books on Cryptography. I must say that I was 16 at the time so the clerk there looked to me in astonishment and brought me a book for children on substitution cyphers (those where you change a letter for another like the famous Caesar Cypher or ROT-13 (Tragbb Ebpxf, naq lbh xabj vg vf tbbq orpnhfr lbh ner ernqvat guvf qbp.), (emerge rotix if you cannot read the preceding text)). I was very upset with this and started to search for more info. It is good to have mathematicians in the family, because as soon as I talked to one of them I was introduced to a new world. And now a bit of mathematics:
If I give you the number 35 and I tell you that this number is the product of two prime numbers it is easy to find that it was 5 and 7. But if I tell you the same for 1588522601 you will spend alot of time (or CPU cycles) to find it was 49811*31891. And if this number is really really big this task becomes "impossible". So now if I give the world my large number that is the product of two primes I know something about that number that no one else knows. This is the basis for Public Key Cryptography (PKC) implementations today. As an (unrealistic) example, I give anyone my number and that someone will use if for cyphering a message to me. Anyone can see the cyphered message, because I am the only one who knows a shortcut to read it, anyone else will first have to "split" that big number to be able to read the message, and it is a "fact" that it is impossible to do that in a short amount of time (todays methods and the fastest computers in the world would take thousands of years to do that). In this setup the two large prime numbers would be called the PRIVATE KEY, and the large non prime number is the PUBLIC KEY. In practice this is not 100% accurate with reality, but will give a good idea to the newcomer. For more information check hack.gr on the Diffie-Hellman protocol. For even more info go to the public library and grab a copy of the "Handbook of Applied Cryptography" by Alfred J. Menezes, Paul C. van Oorschot and Scott A. Vanstone, also this book is available online for free at the above site. One consequence of the above is that if you cypher a message to me, and you loose the original uncypherd message you will no longer be able to retrieve it from the cyphered version. We already saw how someone can send us a cyphered message if they have our public key. But how do we know that the author of the message is really who he claims to be? Or in other words: If I receive an email from you how do I really know it was you and not someone else claiming to be you? Remember me saying that PKC was not as simple as I had said? The idea is that when you cypher a message to me you sign it with your private key so that, when I receive it, I can first use your public key to check your signature and then use my private key to decypher the message. As you can see we could not do that in the setup i described before. Also very important, to sign messages you don't have to cypher them before. So like that you can create messages that can be read by anyone, but that come with your "branding". And if any single character is changed in the message it can (and will) be detected. But lets say that I have no previous contact with you until you send me a message, how do I get your public key, and how do I really know it is yours? To solve this problem public Key Servers were created. When you create your key pair (Public and Private key) you send your public key to the key server. After this everyone can retrieve your key from there. This solves the problem of finding the key. But how do I really know that that key is the author's key? For this another concept must be introduced, and that is key signing: Key signing means that, if I have the public key of another person, and I know for sure that it is really that persons key (it is my personal friend, someone I know in real life, etc.) I can sign that public key and send it to keyservers, that way I am telling the world: "This key really belongs to the person it claims to belong.". That way persons that have my public key and trust me can use that trust to trust other keys. This can sometimes be confusing so lets see a real world situation Let's imagine a 3 person situation: John, Mary, and Lisa. John is a good friend of Mary but does not know Lisa; Lisa is a good friend of Mary but does not know John. One day Lisa sends John a signed email. John will fetch Lisa's Public Key from the keyserver and test the message, if all went ok he will see that whoever wrote that message also created that key. But how do I know it was really the person it claims to be? He then see's that it is signed by Mary, which he can check because he already has Mary's key and he trusts that key. With this ring of trust he continues to conclude that the email he received was really written by Lisa. You are now ready to use this guide, you can go back to chapter 1 and learn how to use gpg. 7. Final thoughts and Credits I had some problems with photos in keys. Check the version you are using. If you have GnuPG 1.2.1-r1 and up you are probably OK, older versions may have problems. Also most keyservers don't like keys with photos, so you are better if you dont add photos. The latest versions of gnupg don't seem to work with the gpg --send-keys that was used so send all keys in your keyring to the public server. gpg is a very complex tool, it lets you do much more than what I have covered here. This document is for the user who is new to GnuPG. For more information, you should check the GnuPG Website. I did not write about other tools like pgp4pine, gpgpine, evolution and maybe Windows tools, but I will probably extend this document in the future. John Michael Ashley's GnuPG Handbook it is a very good book for beginners. Swift (Sven Vermeulen) for pushing me to re-write this. Everyone in the #gentoo-doc team you guys rock. Tiago Serra for getting me back to the privacy track. The contents of this document are licensed under the Creative Commons - Attribution / Share Alike license. |
|
