GNUPG or GPG for short

By Robert Spotswood

Table of Contents

1. GNU Privacy Guard
2. Introduction
3. About GPG
4. Why? (part 1)
5. Why? (part 2)
6. Why? (part 3)
7. Why? (part 4)
8. Theory - Pieces
9. Theory - One Way Hashes
10. Theory - Algorithms
11. Theory - Keys Part 1
12. Theory - Keys Part 2
13. Theory - Keys Part 3
14. Theory - Symmetric keys
15. Theory - Asymmetric keys
16. Theory - Key Signing (Part 1)
17. Theory - Key Signing (Part 2)
18. Theory - Encrypting/Decrypting
19. Theory - Digital Signatures
20. Theory - Certificates
21. Theory - Vulnerabilities
22. Practice - The tasks
23. Practice - Listing the keys on your keyring
24. Practice - Encrypting a message
25. Practice - Decrypting a message
26. Practice - Signing a message
27. Practice - Signing a message (con't)
28. Practice - Verifying the signature
29. Practice - Generating a key pair
30. Practice - Generating a revocation certificate
31. Practice - Exporting your public key
32. Practice - Importing (adding to your keyring) the public keys of others
33. Practice - Validating a key
34. Practice - Signing a key
35. Practice - Checking a key's signatures
36. Practice - Deleting keys from your keyring
37. Practice - GUI Frontends
38. ROT13 Explained

Introduction

• Hopefully, by the end of this presentation, you will be better equipped to use gpg to increase your security. Understand, however, that gpg (or its brother pgp) is not a magic bullet. By itself, it does not guarantee security. No product can.
• Security is a chain; it's only as strong as the weakest link. People (mostly uneducated users) are the weakest link. It is my hope that after this lecture, you at least, will not be the weak link with respect to GPG.
• The second part of this lecture gives you some background on the GPG program itself.
• The third part of this lecture (Why?) tells you why you would want to bother with gpg at all. If you aren't sure if you should bother with this extra effort of learning about this program, this part is for you.
• The fourth part of this lecture (Theory) goes into detail about the theory behind gpg and public key technology. Technically, this part is optional, and in an ideal world will never be useful to you. However, we live in the real world, so it probably will be useful. How do you recognize an attack? What do you do? This section helps to answer these questions.
• The last section (Practice) gives you instruction on how to actually use the program, as well as telling you about some GUI front ends to GPG.

GNU Privacy Guard     Table of Contents   About GPG

About GPG

• Full replacement of PGP and full OpenPGP implementation. Also decrypts and verifies PGP 5, 6 and 7 messages.
• Does not use any patented algorithms. Supports ElGamal (signature and encryption), DSA, RSA, AES, 3DES, Blowfish, Twofish, CAST5, MD5, SHA-1, RIPE-MD-160 and TIGER.
• Better functionality than PGP and some security enhancements over PGP 2.
• Integrated support for HKP keyservers (wwwkeys.pgp.net).
• Runs on almost any Unix, including Linux (of course), and even Windows.
• Homepage is at www.gnupg.org.
• Is a command line program, which means it works well in shell scripts.
• There are numerous GUI front ends if you don't like the command line.

Introduction     Table of Contents   Why? (part 1)

Why? (part 1)

When I (and others who think like me) try to convince others to start using encryption to protect themselves, the most common response is "Why should I worry about my privacy? I have nothing to hide?"

My response is this:

• Privacy isn't about hiding things. It's about self-possession, autonomy, choice, and integrity.
• Privacy is the right of people to control what details about their lives stay inside their own homes and what they share with the rest of the world.
• How many of you would like someone filming you every moment (and I do mean EVERY moment) of your life and making it available to anyone? Just imagine being able to re-live your most embarrassing moments and greatest failures over and over again and not having a choice about sharing that with the world!
• Privacy isn't about wanting to watch porno over the net, but about the man/woman who's afraid to use the Internet to organize her community against a proposed toxic waste dump -- afraid because the dump's investors are sure to dig through her past if she becomes too much of a nuisance.
• Privacy is about lovers who will take less joy in walking around city streets or visiting stores because they know they're being photographed by surveillance cameras everywhere they step.
• Privacy is about free elections. How many people would change their votes if they knew that one party was watching and would pay them a "special visit" if they vote for the wrong candidate?
• Privacy is about good, honest, and honorable citizens that refuse to enter public service because they don't want a bloodthirsty press (or other party) rummaging through their old school reports, computerized medical records, and email.
• Privacy is about the woman who wants to research breast cancer without fear her employer will find out and drop her health coverage.

In addition, gpg isn't just about privacy. It does other tricks too.

• Email can be forged. It's trivial to do. GPG is about having some reasonable assurance the "important" email isn't forged.
• Email could be intentionally altered or corrupted in transit. GPG is about being able to detect this.

About GPG     Table of Contents   Why? (part 2)

Why? (part 2)

This brings us to the next objection: "To enjoy the benefits of modern society, we must necessarily relinquish some degree of privacy."

My response is this:

• In the 1950s and 1960s are society faced an "environmental crisis". Some say the crisis isn't over.
• Advocates of big business said that poisoned rivers and lakes were the necessary costs of economic development, jobs, and an improved standard of living. Poison was progress. Anyone who argued differently was a crazed radical or simply didn't understand the facts.
• Today was know sustainable economic development depends on preserving the environment. Without clean air to breathe and clean water to drink, we will surely die. How do you have an improved standard of living if your dead?

Why? (part 1)     Table of Contents   Why? (part 3)

Why? (part 3)

The next objection heard is "I'll use encryption only when I need it. Only when I have something sensitive."

My response is this:

• If you are being watched, encrypted messages will stand out like a beacon. The eavesdropper may not be able to read the message, but he/she/they will know something is up. From there, more info can be learned.
• If you always encrypt, another encrypted message is nothing unusual.
• Can you tell, with 100% certainty for the next 20-50 years (or maybe even longer) whether something might be sensitive?
• Practice makes perfect!

Why? (part 2)     Table of Contents   Why? (part 4)

Why? (part 4)

Now the objection heard might be, "Ok, so it is useful, but it's too much trouble to bother with."

My response is this:

• How many of you bother with keys and locking your home and/or car?
• PKI venders have been lobbying for laws to the effect that if someone uses your private signing key, then you are not allowed to repudiate the signature. In other words, under some digital signature laws (e.g., Utah and Washington), if your signing key has been certified by an approved CA, then you are responsible for whatever that private key does. It does not matter who was at the computer keyboard or what virus did the signing; you are legally responsible.
• Heard of the "Electronic Signatures in Global and National Commerce Act"? It's now the law in the US as of June 30, 2000. Online documents will have the same force of law as paper contracts and records. On top of that, while the Act allows you to dispute the authenticity of particular electronic signatures or digital documents, this means you have to prove an electronic signature or document isn't yours or is not otherwise authentic.
• Don't want to bother knowing what you are doing? Lots crooks and lawyers are rubbing their hands together in glee at the prospect!

Why? (part 3)     Table of Contents   Theory - Pieces

Theory - The Pieces

GPG has many "pieces" that make it up. To understand how they work together, you first should understand what each piece does. The following "pieces" are going to be described:

• One way hashes
• Algorithms
• Keys
• Symmetric keys
• Asymmetric keys
• Key Signing

After you understand the pieces, next will be how the pieces fit and work together:

• Encrypting/Decrypting
• Digital Signatures
• Certificates
• Vulnerabilites

Why? (part 4)     Table of Contents   Theory - One Way Hashes

Theory - One way hashes

• One way hashes are like digital fingerprints - a few small pieces of data serve to identify a much larger piece of data.
• As the name implies, the hash is a one way ticket. You can compute the hash of any given piece of data, but given that hash, you can't recreate the data (if the hash is any good at least).

Here is a very simple example of a one way hash. Take every third letter of each word. If there is no third letter, starting with 0, substitute a digit, increasing the digit by one each time. Once you reach 10, start over with 0 again. For example given the following text:

Mary had a little lamb

• One way hashes are for all practical terms, unique for a piece of data. For MD5 hashes, the chance of another random piece of data having the same MD5 sum as the first piece of data are estimated at 1 in 2^64 or 1 in 18,446,744,073,709,551,616.
• For the same piece of data, the one way hash is always the same. (If it isn't, your hashing program is either trojaned or has a very, very serious bug!)
• One way hashes provide a simple, but effective way to verify the data is the same and is unaltered. The original author takes a one way hash of the data and publishes it. Any receipent can take the same hash of his copy of the data. If the hashes match, the odds of the data being altered are extremely small.

Theory - Pieces     Table of Contents   Theory - Algorithms

Theory - Algorithms

• As used in GPG (and cryptography), an algorithm is used to transform a plaintext message into gibberish, and later, turn the gibberish back into plain text. A simple (and insecure!) algorithm is ROT13.
• Everyone in the group to whom the secret messages will be sent/received, be it 1 or 100 people (or more) must know the same algorithm.
• The algorithm must be really good, or it will be broken and hence worthless.
• If anyone leaves (or is kicked out) the group, the whole group needs a new algorithm.
• You will need a different, good, algorithm for each group of people. Good luck!

Theory - One Way Hashes     Table of Contents   Theory - Keys Part 1

Theory - Keys Part 1

• To prevent having to use 10's, 100's, even 10K's of good algorithms, the cryptographic key was invented (by Leon Battista Alberti, in 1466).
• With keys, the algorithm is incomplete. The key complete's the algorithm. ROT13 is an example. The ROT is the algorithm and 13 is the key.
• Since each key can be different, it doesn't matter who knows the algorithm, if the algorithm is any good.
• A good algorithm puts all the security in the key and none in the algorithm. Knowing the algorithm should be worthless without the key.
• If you want to kick someone out fo the group, just use a new key.

Theory - Algorithms     Table of Contents   Theory - Keys Part 2

Theory - Keys Part 2

• Since a key in GPG (and virtually every other computer cryptography program) is just a string of bits (0's and 1's), change just one bit, and you have a different key.
• Key length refers to how many 0's and 1's there are. For example, a 128 bit key has 128 0's and 1's (total).
• The number of possible keys for any given length is 2^{(key length)}. For 128 bit keys, 2¹²⁸ = 340,282,366,920,938,463,463,374,607,431,768,211,456 possible keys.
• Brute forcing a key is trying every possible key.
• The average time it takes to brute force a given key length is [2^{(key length)}/2] * [time to try 1 key]. For example, if you can try 1 4bit key in 3 seconds, on average, you can brute force such a key in [2⁴/2] * [3 seconds] = [16/2] * [3 seconds] = 24 seconds.
• Increasing the number of bits by 1 doubles the average time to break the key. Using the previous example, a 5 bit key would take [2⁵/2] * [3 seconds] = 48 seconds.

Theory - Keys Part 1     Table of Contents   Theory - Keys Part 3

Theory - Keys Part 3

• Randomness (aka entropy) in choosing the bits is VITAL!
• Suppose in the previous 5 bit key example, the key-generator has a flaw, and the first 2 bits are always "11". This means if an attacker takes advantage of that fact, the average time to break the key is 12 seconds, not the 48 seconds you might think.
• In the above example, you really have a 3 bit key masquerading as a 5 bit key.
• Security of the keys is not only dependent on the length, but also the randomness. Bigger keys are not necessarily better.

Theory - Keys Part 2     Table of Contents   Theory - Symmetric keys

Theory - Symmetric keys

• A symmetric cipher is a cipher that uses the same key for both encryption and decryption. Here the terms symmetric cipher and symmetric keys are used interchangeably.
• Two parties communicating using a symmetric cipher must agree on the key beforehand.
• The then sender encrypts a message using the key, sends it to the receiver, and the receiver decrypts the message using the same key.
• Symmetric algorithms have the advantage over asymmetric algorithms (discussed shortly) that they are faster to encrypt and decrypt.
• Modern examples of symmetric ciphers include 3DES, Blowfish, and IDEA.
• The biggest problem with symmetric keys is distributing them.
• Since anyone with the key can decrypt any message encrypted with that key, the key must be distributed in a very secure manner.
• It would probably be much easier for an attacker to work to intercept the key than it is to try all the keys in the key space.
• This leads to a Catch-22 situation. You can't distribute keys securely over the internet without encryption. But you can't have very useful encryption unless you distribute the keys securely.

Theory - Keys Part 3     Table of Contents   Theory - Asymmetric keys

Theory - Asymmetric keys

• Public-key ciphers were invented to avoid the key-exchange problem of symmetric keys entirely.
• A public-key cipher uses a pair of keys for sending messages. The two keys belong to the person receiving the message.
• The keys are not the same, hence the name asymmetric keys.
• One key is a public key and may be given to anybody. You will more often hear the term public key than asymmetric keys. They mean the same thing.
• The other key is a private key and is kept secret by the owner.
• Something encrypted with the public key can only be decrypted by the private key. It cannot be decrypted by the public key.
• Something encrypted with the private key can only be decrypted by the public key. It cannot be decrypted by the private key.
• Because having the public key doesn't enable someone else to decrypt messages encrypted with that key, it doesn't matter who has the key. The secure distribution problem is solved!
• All that is required is that some time before secret communication the sender gets a copy of the receiver's public key.
• Now the biggest problem is being sure you have the correct public key! This is discussed next.

Theory - Symmetric keys     Table of Contents   Theory - Key Signing (Part 1)

Theory - Key Signing (Part 1)

• Once you have a public key, how do you know it belongs to the person who you think it belongs to.
• One way is to physically get the key from that person on a floppy (or CD, etc). However, this is of limited usefulness on the internet.
• Another way is to securely (generally done in person or by phone) verify the fingerprint of the key. Doing it over the internet is risky (there are all kinds of attacks on this method), but is less risky than doing no verification at all.
• The final way to be sure the key is correct is by key signing.

Theory - Asymmetric keys     Table of Contents   Theory - Key Signing (Part 2)

Theory - Key Signing (Part 2)

• Suppose you have gotten someone's public key securely. This means you can decrypt with confidence anything encrypted with that person's private key. This person is also very trustworthy and knows what he (or she) is doing.
• If this reliable person told you another key really belonged to the person the key says it belongs to, you could be pretty sure the key is legitimate.
• GPG (and PGP) allow for this "telling" by what is know as key signing.
• When you export a key, someone else can attach a small piece of data encrypted with his private key that says the public key is legitimate. This is the key signing part.
• Since only this trustworthy person has his private key, if his public key decrypts the message, you can be sure he gave his assurance that the public key is legitimate.
• With key signing, you don't have to personally verify every key. You only need someone trustworthy to do the verification.

Theory - Key Signing (Part 1)     Table of Contents   Theory - Encrypting/Decrypting

Theory - Encrypting/Decrypting

• By now, you should know that encrypting takes a message and turns it into gibberish. Decrypting reverses this process.
• To encrypt a message to someone, you first must have his public key. You then use that public key to "scramble" the message.
• When he gets the "scrambled" message, he uses his private key to make it readable again.
• Actually, the public key isn't used to encrypt the message. To make the process faster, a symmetric key is chosen and used to encrypt the message.
• The symmetric key is then encrypted with the public key.
• When the message is received, the symmetric key is recovered using the private key, and the symmetric key is then used to decrypt the message.

Theory - Key Signing (Part 2)     Table of Contents   Theory - Digital Signatures

Theory - Digital Signatures

• The first step in creating a digital signature is to take a one-way hash of the message.
• This hash is then encrypted with the signer's PRIVATE key. In theory, only the signer's public key can unencrypt this hash.
• This encrypted hash is the digital signature.
• When the another person checks the digital signature, he (or she) generates his own hash of the message.
• The receiptent now uses the public key to decrypt the encrypted hash and compares the two hashes.
• If the hashes differ, something is up! Either the message or the signature has been tampered with.
• If the message has been tampered with, the hashes won't match.
• If the signature has been tamped with, and this includes substituting another signature, when decrypted, it won't decrypt properly. If it doesn't decrypt properly, the hashes won't match.
• If the hashes do match, since only the signer should have access to his private key, no one else can put a different signature and still have a hash match. Therefore, the signer must have really signed the message and the message has not been changed.

Theory - Encrypting/Decrypting     Table of Contents   Theory - Certificates

Theory - Certificates

• Although they are not called certificates, certificates (by definition) can be (and often are) used in GPG. Even if you don't use them in GPG, you probably do using them Web surfing, so I'm going to cover them briefly as well.
• A certificate is just the person's/server's/company's/whatever's public key, and information such as the server name and organization responsible for it. This "certificate" of information is then signed by the secret key of a trusted third party (such as VeriSign). This is essentially the same thing as the key signing web of trust used by GPG (and PGP).
• The trusted third party's key (for web use) is usually built into such software as Web browsers. If an attacker can subvert the Web browser and modify the certificate, they will also be able to redirect information before it gets encrypted. All bets are off. How long before there is an ActiveX control that does just that for IE?
• Issuing certificates can provide an attractive business model. They cost almost nothing to make, and if you can convince someone to buy a certificate each year for $5, that times the population of the Internet is a big yearly income. If you can convince someone to purchase a private CA and pay you a fee for every certificate he issues, you're also in good shape.
• Almost all the literature and lobbying on the subject is produced by PKI vendors. Be careful to view with some skeptism any literature on the subject.
• Root keys (from the CA) are often held in "root certificates." "Root certificates" are a self-signed certificate and offers no increased security.
• Certificates generally associate a public key with a name. But how useful is this association? You may only know one John Smith, but how many does the CA know? To get around that problem, the certificate's Common Name will probably be extended with some other information, in order to make it unique among names issued by that one CA. Do you know that other information about your friend? How many other people know that information?

Theory - Digital Signatures     Table of Contents   Theory - Vulnerabilities

Theory - Vulnerabilities

• The biggest vulnerability in GPG (here the same thing as public key encryption), or computer security in general is not bad algorithms, or program bugs, but the user.
• Public key encryption relies heavily on the user to make the right decisions, especially when faced with an attack, and most users are not educated enough to know what the right decision is.
• My experience shows most users don't want the education either. "Some drink from the fountain of knowledge, others gargle with it; the rest pee in it."
• Users often make the wrong decision - how many times have users been told not to open up executables emailed to them? Or "Warning: server's key has changed. Continue?" Most users will hit Yes without a second thought.
• Even for those who do have some idea what to do, for most, the moment security gets in the way of something, out it goes.
• One article states "Security breaches cause more than $15bn worth of damage worldwide every year, yet total investment on network security is only half this..."

Theory - Certificates     Table of Contents   Practice - The tasks

Practice - The tasks

In GPG, there are only a few operations you will perform with any regularity. They are:

• Listing the keys on your keyring.
• Encryping a message.
• Decrypting a message.
• Signing a message (can be combined with encrypting).
• Verifying the signature on a message (can be combined with decrypting).

There are also a few other operations that while only needed once in a while, are also important. They are:

• Generating a key pair.
• Generating a revocation certificate.
• Exporting your public key.
• Importing (adding to your keyring) the public keys of others.
• Validating a key.
• Signing a key.
• Checking a key's signatures.
• Deleting keys from your keyring.

The following describes how to use GPG from the command line. However, for those that like GUI's, there are numerous frontends to GPG. They are listed at the end of this presentation. They making using GPG much easier. However, by learning the command line, you are not stuck if a GUI (or X) isn't available or working. Not every option can be presented (time!). See the official docs if you are interested in more options.

Theory - Vulnerabilities     Table of Contents   Practice - Listing the keys on your keyring

Practice - Listing the keys on your keyring

Listing keys is important, because other operations will often ask you what key to use. The simplest way to list the keys on your public keyring use the command-line option --list-keys. For example:

[robert@linux]#  gpg --list-keys
gpg: Warning: using insecure memory!
/home/robert/.gnupg/pubring.gpg
pub  1024D/38952095 2000-08-27 Robert Spotswood (New gpg key and new address) <berzerke@swbell.net>
sub  1024g/0D2EF746 2000-08-27

pub  1024D/9B4A4024 2000-01-06 MandrakeSoft (MandrakeSoft official keys) <mandrake@mandrakesoft.com>
sub  1024g/686FF394 2000-01-06

pub  1024R/98ABFE7D 1996-08-25 Craig H. Rowland <crowland@psionic.com>

pub  1024D/DB42A60E 1999-09-23 Red Hat, Inc <security@redhat.com>
sub  2048g/961630A2 1999-09-23
<snip>

The part after the / on the lines that start with pub is the key's name. For instance, for my key (the first one), the key's ID (or name) is 38952095. If you don't want to see all the keys, you can add a name after the --list-keys. The name can be the key's ID, fingerprint (covered later), or any part of the descriptive text (i.e. for me, it would be "Robert Spotswood (New gpg key and new address) ". For example:

[robert@linux robert]$ gpg --list-keys key
gpg: Warning: using insecure memory!
pub  1024D/38952095 2000-08-27 Robert Spotswood (New gpg key and new address) <berzerke@swbell.net>
sub  1024g/0D2EF746 2000-08-27

pub  1024D/9B4A4024 2000-01-06 MandrakeSoft (MandrakeSoft official keys) <mandrake@mandrakesoft.com>
sub  1024g/686FF394 2000-01-06

Practice - The tasks     Table of Contents   Practice - Encrypting a message

Practice - Encrypting a message

• Encrypting is one of the four most important uses of GPG.
• The procedure for encrypting (and decrypting) documents is very simple. If you want to encrypt a message to someone (say Robert), you encrypt it using Robert's public key, and then only Robert can decrypt that file with his private key. No one else can decrypt it. Note that you first must have the public key of Robert to encrypt to him.
• To encrypt, use the command line option --encrypt and give a name of the file you want to encrypt. You will then be asked for the key's name (see listing the keys). If you use part of the descriptive text, be sure it is unique. Here is an example:

  [robert@linux robert]$ gpg --encrypt junk.txt
  gpg: Warning: using insecure memory!
  You did not specify a user ID. (you may use "-r")
  
  Enter the user ID: 38952095
  gpg: using secondary key 0D2EF746 instead of primary key 38952095
  

• While nothing seemed to happen, in the current directory is an encrypted version of junk.txt named junk.txt.gpg.
• Warning: GPG does NOT erase the unencrypted text. You must delete the original file.
• If you use the --output option, you can specify the output file name. Otherwise, it creates a new file (warning you if it already exists) with the extension gpg. The --output option must come before the --encrypt option.

Practice - Listing the keys on your keyring     Table of Contents   Practice - Decrypting a message

Practice - Decrypting a message

• Decrypting is the second of the four most important uses of GPG.
• To decrypt a message the option --decrypt is used.
• You must have the private key that matches the public key used to encrypt the message.
• You must know and enter the passphrase for the private key.
• If you don't use the --output option, gpg prints the decrypted text to STDOUT (the screen). The --output must come before the --decrypt.

Here is a sample decryption:

[robert@linux robert]$ gpg --decrypt junk.txt.gpg
gpg: Warning: using insecure memory!

You need a passphrase to unlock the secret key for
user: "Robert Spotswood (New gpg key and new address) <berzerke@swbell.net>"
1024-bit ELG-E key, ID 0D2EF746, created 2000-08-27 (main key ID 38952095)

This is a test encryption. <----This was the encrypted text.

Practice - Encrypting a message     Table of Contents   Practice - Signing a message

Practice - Signing a message

• Signing, aka creating a digital signature, is the third of the four most important uses of GPG.
• You must have the passphrase and your private key to sign something.
• Signing can be combined with encrypting, and the output option can be used with or without the encrypt option.
• ANY alteration to the message will void the signature.
• To sign a message, you can sign (--sign) or clearsign (--clearsign).
• Plain signing (--sign) is mostly used when you are also encrypting. Because a regular signed message can, and often does, contain control characters (the output is binary), displaying a regular signed message can really mess up someone's display.
• Clearsigning (--clearsign) is generally used when not encrypting. It is commonly used for emails and usenet postings. The option --clearsign causes the document to be wrapped in an ASCII-armored signature but otherwise does not modify the document. In otherwords, no control characters to mess up someone's display.

Here is an example of signing and encrypting and using the output option:

[robert@linux robert]$ gpg --output junk.gpg --sign --encrypt junk.txt
gpg: Warning: using insecure memory!

You need a passphrase to unlock the secret key for
user: "Robert Spotswood (New gpg key and new address) <berzerke@swbell.net>"
1024-bit DSA key, ID 38952095, created 2000-08-27

You did not specify a user ID. (you may use "-r")

Enter the user ID: 38952095
gpg: using secondary key 0D2EF746 instead of primary key 38952095

Practice - Decrypting a message     Table of Contents   Practice - Signing a message (con't)

Practice - Signing a message (con't)

Here is an example of just clearsigning:

[robert@linux robert]$ gpg --output junk.clear.gpg --clearsign junk.txt
gpg: Warning: using insecure memory!

You need a passphrase to unlock the secret key for
user: "Robert Spotswood (New gpg key and new address) <berzerke@swbell.net>"
1024-bit DSA key, ID 38952095, created 2000-08-27

The file junk.clear.gpg (clearsigned message) is:

Hash: SHA1

This is a test encryption.
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE6WVkDXPYCfjiVIJURAkllAKCmlKtCnlIZvB92E7lsnU3Dv+X7rwCfdJFu
mWcXQYxGOWUqaj6jcXpsN9Q=
=+D/K

Practice - Signing a message     Table of Contents   Practice - Verifying the signature

Practice - Verifying the signature

• Verifying a digital signature, is the fourth of the four most important uses of GPG.
• You must have the public key of the person who signed the message.
• If the message is encrypted as well as signed, the signature will automatically be checked when you decrypt. As a general rule of thumb, you cannot verify a message that was also encrypted. You must use the --decrypt option.
• To verify a message, use the --verify option. The --output option does not work here.

Here is an example of verifying with an unaltered file:

[robert@linux robert]$ gpg --verify junk.clear.gpg
gpg: Warning: using insecure memory!
gpg: Signature made Mon 08 Jan 2001 12:06:59 AM CST using DSA key ID 38952095
gpg: Good signature from "Robert Spotswood (New gpg key and new address) <berzerke@swbell.net>"

Here is an example of verifying when I added a space before " encryption.". This is something only a few people would ever notice.

[robert@linux robert]$ gpg --verify junk.clear.gpg
gpg: Warning: using insecure memory!
gpg: Signature made Mon 08 Jan 2001 12:06:59 AM CST using DSA key ID 38952095
gpg: BAD signature from "Robert Spotswood (New gpg key and new address) <berzerke@swbell.net>"

Practice - Signing a message (con't)     Table of Contents   Practice - Generating a key pair

Practice - Generating a key pair

• In order to really use GPG, you have to have your own public and private keys. You will only use the private key, but others need your public key.
• You start the key generation process with the --key-gen option.
• You will be asked a series of questions. For most users, the default answers are fine. If you've been through the theory, you should understand most of the questions.
• The most important question is your passphrase. If someone else gets a hold of your secret key, this is the only thing that stands between them using it and not using. Choose carefully! It is a phrase, so blanks are allowed.
• Do not forget your passphrase! If you forget it, for all practical purposes, it is lost for good. (See generating a revocation certificate.)
• Your private key must be protected at all costs!

Practice - Verifying the signature     Table of Contents   Practice - Generating a revocation certificate

Practice - Generating a revocation certificate

• If you every forget your passphrase, or lose your secret key for whatever reason, a revocation certificate is how you let the world know the key is to no longer be trusted.
• To be able to do this, you need your secret key, else anyone could revoke your certificate.
• This has one BIG disadvantage. If you don't remember your passphrase or have lost the key, you can't revoke the key!
• To overcome this problem it is wise to create a revoke license when you create a key pair. If you do so, keep it safe! If someone else gets a hold of it, that person can render your key worthless.
• To issue a revocation certificate, use the --gen-revoke and give some part of the name of the key.

Here is an example of me generating a revocation certification:

[robert@linux robert]$ gpg --gen-revoke berzerke@swbell.net
gpg: Warning: using insecure memory!

sec  1024D/38952095 2000-08-27   Robert Spotswood (New gpg key and new address) 

Create a revocation certificate for this key? y
Please select the reason for the revocation:
  1 = Key has been compromised
  2 = Key is superseded
  3 = Key is no longer used
  0 = Cancel
(Probably you want to select 1 here)
Your decision? 3
Enter an optional description; end it with an empty line:
> test revocation
>
Reason for revocation: Key is no longer used
test revocation
Is this okay? y

You need a passphrase to unlock the secret key for
user: "Robert Spotswood (New gpg key and new address) <berzerke@swbell.net>"
1024-bit DSA key, ID 38952095, created 2000-08-27

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!
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org
Comment: A revocation certificate should follow

gFi<snip>gTy
C<snip>ZsrI
=RguI

P.S. That's not my real revocation certificate above!

Practice - Generating a key pair     Table of Contents   Practice - Exporting your public key

Practice - Exporting your public key

• You export your public key (NOT PRIVATE) key so that others can use it.
• By exporting your public key, others can starting contacting you securely.
• The most basic way to export is "gpg --export" and give a key name. The output is a binary format to STDOUT.
• The options, which come before the --export that are very useful here are --armor, which makes the output in ascii, and --output, which sends the output to a file rather than your screen.
• The public key does not have to be secured. Anyone can have it. The security part comes from the fingerprint and others signing it.
• Distributing the key can be by any method convenient: publish it on your web page (and fingerprint!), finger, upload it to a key server, email it, etc.

Here is an example:

[robert@linux robert]$ gpg --output robert.key --armor --export berzerke@swbell.net

Practice - Generating a revocation certificate     Table of Contents   Practice - Importing (adding to your keyring) the public keys of others

Practice - Importing (adding to your keyring) the public keys of others

• In order to communicate securely with someone else, you need their public key.
• Having someone else's public key allows you to encrypt to them and verify their digital signature.
• When you received someone else's public key (or several public keys) you have to add them to your key database in order to be able to use them.
• The command to add the public key(s) to your keyring is --import and the file name(s).

Here is an example:

robert@linux robert]$ gpg --import cert_pgp_key.asc
gpg: Warning: using insecure memory!
gpg: key 20B19259: public key imported
gpg: Total number processed: 1
gpg:               imported: 1  (RSA: 1)

Practice - Exporting your public key     Table of Contents   Practice - Validating a key

Practice - Validating a key

• Ok, so now you've got a key. How do you know it really belongs to the person it claims to belong to? This is biggest Achilles' heel in the whole GPG/PGP system.
• This is not a theoretical attack! For example, in the past, forged CERT/CC PGP keys have been created and uploaded to public keyservers.
• There are two ways to validate a key: the fingerprint, and the signatures.
• To check the fingerprint, use the --fingerprint option. You can add a key name if you are only interested in only one (or a few) keys. This lists the fingerprint for the key you imported. Now find a way to verify that fingerprint. If they match, the key is most likely genuine.
• The other way of verifying a key is to look at the signatures attached to the key with the --list-sigs. Is the key signed by someone you trust?

Here is an example of fingerprinting a key:

[robert@linux robert]$ gpg --fingerprint CERT
gpg: Warning: using insecure memory!
pub  1024R/20B19259 2000-09-20 CERT Coordination Center <cert@cert.org>
     Key fingerprint = 6D DB 09 5E 34 8A C5 60  11 57 0D D1 1E 43 FD 1D

Practice - Importing (adding to your keyring) the public keys of others     Table of Contents   Practice - Signing a key

Practice - Signing a key

• If you have, by some means, determined the key really belongs to who it says it does, you should sign it.
• There are two ways to sign a public key. The --sign-key option allows others to relie on your signature. The --lsign-key option allows you to sign the key, but others can't relie on your signature. Only use the --sign-key option if you are careful and sure the key is valid.
• Signing a key validates it. In some PGP programs (perhaps all, including GPG), you can not use a key until you sign it.

Here is an example of signing a key:

[robert@linux robert]$ gpg --sign-key CERT
gpg: Warning: using insecure memory!

pub  1024R/20B19259  created: 2000-09-20 expires: 2001-10-01 trust: -/q
(1)  CERT Coordination Center 

pub  1024R/20B19259  created: 2000-09-20 expires: 2001-10-01 trust: -/q
             Fingerprint: 6D DB 09 5E 34 8A C5 60  11 57 0D D1 1E 43 FD 1D
     CERT Coordination Center <cert@cert.org>

Are you really sure that you want to sign this key
with your key: "Robert Spotswood (New gpg key and new address) <berzerke@swbell.net>"
Really sign? y

You need a passphrase to unlock the secret key for
user: "Robert Spotswood (New gpg key and new address) <berzerke@swbell.net>"
1024-bit DSA key, ID 38952095, created 2000-08-27

Practice - Validating a key     Table of Contents   Practice - Checking a key's signatures

Practice - Checking a key's signatures

• If you've gotten a key, and would like to see who has signed it (in theory stating they believe the key is genuine), you need to check the signatures.
• Every key will have one or more self-signatures as well as a signature for each user that has validated the key.
• If you can't verify the key based on the fingerprint, this is about the only other way to verify the key.
• You can check the signature(s) of the key(s) by the option --check-sigs and an optional key name.

Here is an example of checking signatures on a key:

[robert@linux robert]$ gpg --check-sigs network
gpg: Warning: using insecure memory!
pub  1024D/A70A8463 1999-08-20 Networked Systems Survivability Master Key 
sig!       A70A8463 1999-08-20  Networked Systems Survivability Master Key 
sig?       F414952B 1999-08-24
sig!       38952095 2001-01-11  Robert Spotswood (New gpg key and new address) 
sub  3072g/3A526935 1999-08-20 [expires: 2004-09-30]
sig!       A70A8463 1999-08-20  Networked Systems Survivability Master Key 

Practice - Signing a key     Table of Contents   Practice - Deleting keys from your keyring

Practice - Deleting keys from your keyring

• Eventually, for whatever reason, you may want to delete a key from your keyring.
• The command to do that (for public keys) is --delete-key and the name.
• DON'T forget the name here. Without the name, the default is to delete all the public keys. Do you have a backup copy of your public keyring?

Here is an example of deleting a key:

[robert@linux robert]$ gpg --delete-key crowland
gpg (GnuPG) 1.0.4; Copyright (C) 2000 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.
 
gpg: Warning: using insecure memory!
pub  1024R/98ABFE7D 1996-08-25   Craig H. Rowland <crowland@psionic.com>
 
Delete this key from the keyring? y

Practice - Checking a key's signatures     Table of Contents   Practice - GUI Frontends

Practice - GUI Frontends

Want to use GPG but hate the command line? You're in luck! There are a number of GUI front-ends for GPG. Here are links to some of them:

• Seahorse is a GNOME frontend for GnuPG. This is my current favorite.
• GPA aims to be the standard GnuPG graphical frontend.
• GnomePGP is a GNOME desktop tool to control GnuPG.
• Geheimniss is a KDE frontend for GnuPG.
• TkPGP is another graphical tool to control GnuPG.
• WinPT is a MS-Windows program to integrate GnuPG into the Desktop.

All of these frontends will require some degree of cut and paste to use with email programs such as Netscape and Mozilla. The following programs are available to help eliminate the cut and paste:

• KMail from the KDE desktop does supports GnuPG. I currently use this for most of my email. It will automatically sign (or encrypt and sign if you have the proper public key). It also automatically decrypts (if appropriate) and verifies signatures. However, turning this off and on is a pain. I leave it on. Also, the address book needs some work, especially in supporting lists.
• Mutt is an advanced MUA with complete MIME and GnuPG/PGP support. Download the international version.
• Mailcrypt for Emacs. You may need the latest patches until there is a new release of Mailcrypt.
• Mew has support for GnuPG.
• exmh is a Tcl/Tk based MUA.
• pgp4pine is a Pine filter to handle PGP messages.
• Another Pine filter named gpg4pine can be found at azzie.robotics.net.
• pgpenvelope is a Pine and procmail filter which allows one to process messages with GnuPG.
• privtool is another GPG enabled MUA.
• XFmail works with GnuPG.
• MagicPGP is yet another set of scripts to use GnuPG with Pine.
• PinePGP is also a Pine filter for GnuPG.

Practice - Deleting keys from your keyring     Table of Contents   ROT13 Explained

ROT13 Explained

• ROT13 rotates the alphabet by half its length, ie 13 characters. ROT13 stands for `rotate alphabet 13 places [forward]'.
• ROT13 as a text operation is obviously inverse to itself; using it twice on the same text reveals the original.
• ROT13 is a simple way to "encrypt" text, but it is not meant for serious protection. It doesn't offer any serious protection either! ROT13 is mainly used to hide text from casual reading. ROT13 is mainly used on Usenet to "hide" texts such as "spoilers" to puzzles or "offensive" text.

To manually encrypt or decrypt a ROT13 message, for each letter in the first line of the chart below, replace it with the letter on the second line:

abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXY
nopqrstuvwxyzabcdefghijklmNOPQRSTUVWXYZABCDEFGHIJKL

For example, the text "Linux" would encrypt as "Yvahk".

Practice - GUI Frontends     Table of Contents