GnuPG - An Overviewby Rick Moen
Revised: Wednesday, 2008-05-14
Master version will be at http://linuxmafia.com/faq/Security/gnupg.html, and I'll try to improve it there.
Scope of this talk: This talk will cover the general use of GnuPG, as well as some specifics relevant to a one-time customer of mine. That firm's IS Dept. uses GnuPG as a general delivery vehicle for security-token data to employees outside. I won't be covering those tokens and the systems they're for, just GnuPG and related systems.
History of public-key cryptography:
1466: Symmetric (or secret-key) cryptography invented by architect Leon Battista Alberti of Italy. Requires shared secret (key), which must be distributed separately -- logistical problem. (Symmetric crypto is used in GnuPG for the "session key", which gets transmitted encrypted using the other type.) Called symmetric because you use the same key for encrypting and decrypting. Examples: Blowfish (GnuPG's default), IDEA, 3DES, AES (Rijndael), German WWII Enigma code, PKZ's "Bass-o-Matic".
1970-71 Asymmetric (or public-key) crypto invented in secrecy by James H. Ellis of the British Secret Intelligence Service (technically, GCHQ). Ellis was deprived of credit for this until recently by the UK's Official Secrets Act.
1973: C.C. Cocks of UK GCHQ is claimed to have independently invented a public-key algorithm similar to RSA (again, in secret): http://www.cesg.gov.uk/site/publications/media/notense.pdf
1976: Public-key crypto re-invented by Whitfield Diffie and Martin Hellman ("DH") of Stanford U.
1977: Slightly more-practical method invented by Rivest, Shamir, and Adleman (RSA) at MIT, and published in Scientific American. Rights held (mostly) by MIT. And the game begins.
- Examples: DSA (GnuPG's default), RSA, ElGamal.
- Problem: They're slow.
- Misc. comment: They also used to produce "hashes" = crypto fingerprints of texts. ("Digital signatures".)
1991. PGP 1.0 ("Pretty Good Privacy") released by Philip K. Zimmerman (PKZ), infringing two patents and a copyright, not to mention USA "munitions" regulations. PGPi developed in parallel by crazy Norwegian Ståle Schumacher Ytteborg to get around the legal problems for non-USA/Canada users (based on PKZ code, but includes some variant crypto libraries). Licence on both was initially GPL through 2.6.3a, and then became gratis non-commercial usage. Later, PKZ sold his company (PGP, Inc.) and his software's copyright to Network Associates, Inc.; versions after 6.5.8 became binary-only and MacOS/Win32-only. In early 2002, development was curtailed.
In June, 2002, a group of old-time PGP experts bought PKZ's firm back from Network Associates, Inc., renamed it PGP Corporation, and resumed development. Current version (8.0) remains binary-only and proprietary.
What does it do? People can send you secret information by encrypting it with your public key. You can authenticate information as coming "from you" by signing it with your private key. A company might use the first of these two functions -- using the GnuPG package instead of PGP -- to send information that must be kept secret, when we're outside the company network (e.g., sending SFS passphrases and one-time password lists or seeds).
PGP uses symmetric (secret-key) techniques to encode the messages it protects, and asymmetic (public-key) techniques to safely transmit the necessary symmetric key used for that session.
1996. IETF document RFC 1991 "PGP Message Exchange Formats" defines clearsigning PGP e-mail as an Internet standard, based on PGP 2.x. IETF document RFC 2015 "MIME Security with Pretty Good Privacy (PGP)" then extends this to define a MIME-based alternative to clearsigning.
1998. IETF document RFC 2440 "OpenPGP Message Format" defines OpenPGP as an Internet standard. Tries to improve interoperability. (Dominant versions PGP 2.6.x, PGP 5.0, and PGPi 5.x had accumulated sundry incompatibilities.) This was then extended (2001) by IETF document RFC 3156 "MIME Security with OpenPGP" to define a MIME-based alternative, compatible with the PGP one (RFC 2015).
1999: Werner Koch in Germany releases GnuPG (aka gpg, short for "GNU Privacy Guard") as an OpenPGP implementation. GPL-licensed. Only significant compatibility issue is that it omits the IDEA symmetric algorithm (US-patented by Ascom AG of Switzerland until 2010). This compatibility issue (and a few others like it) will not be a problem for new deployments.
New deployments should standardise on GnuPG as a PGP-equivalent, invoking it as if it were PGP, generally (though there are some differences, and in particular the command-line options are not interchangeable).
(One can add IDEA support to GnuPG, by retrieving, compiling, and installing the extension for that program, and informing GnuPG of its presence by adding "load-extension idea" to ~/.gnupg/options . But you will encounter IDEA keys rarely if ever (basically, only from people using antique PGP 2.x releases). Also, please be advised that using IDEA in the USA may entail legal problems until May 25, 2010.)
How to Use GnuPG:
Generating Your Keys & Revocation Certificate:
"gpg --gen-key" Accept default option 1, to generate both DSA and ElGamal keys. Accept default keysize (1024 bits). It doesn't hurt to have no key expiration (default choice), because you can always change this. You'll be asked for a symmetric-crypto "passphrase" (some phrase you can easily remember): It will be used to encrypt the copy of your private key stored on your hard drive, and you'll be prompted for it any time you want to use your private key. GnuPG will work for a while: You'll be prompted to generate random activity with your mouse and/or keyboard, during the time it's working. Eventually, it will say it's finished, resulting in:
These will hold your public and private (secret) keys,
respectively. Other keys (e.g., from other people you deal
with) can be added to them, which is what makes them
"keyrings". To list the contents of your public keyring:
To list the contents of your private (secret) keyring:
Your keys are tied to your name and e-mail address. If either changes, you will need a new set of keys.
Also immediately do:
"gpg --output revoke.asc --gen-revoke yourusername" (You can use your e-mail address, instead of your username.)
This will create ~/.gnupg/revoke.asc , your "revocation certificate", which you'll be able to publish in the future if you ever need to get the word out that your keys should no longer be trusted.
Congratulations! Aside from key-signing, you're now pretty much done with having to use GnuPG from the command line.
(Just for your information, keyrings are stored in a human-hostile binary format, necessitating arcane formulas to "export" them from keyring to ASCII and "import" them from ASCII to keyring. You'll see references to "armoring" keys, which means exporting them to "radix-64 format", which is a type of ASCII conversion similar to uuencoding. Don't worry about this for now.)
Key sizes: Defaults are fine for any likely purpose, as weaknesses in the system will probably lie elsewhere. Longer keys = slower operation. If you genuinely need 80 years of secrecy, pay that price, and hire a staff cryptographer. Otherwise, don't.
Signing GnuPG Keys ("Key-Signings" or "Key-Signing Parties"):
Public-key cryptography made possible many tricks not previously available, but retains the Achilles Heel of all cryptography: key distribution (the flip side being key tampering). How do you know that a public key supposedly from your friend Alice really belongs to her? Advantage of "public key" methods is that the key can be public, but you still have the problem of proving it's a real, still-valid key for the right person.
Obvious way is to get it directly from Alice, but she may be around the world. How about if your friend Bob certifies that it's really Alice's? Or how about if your friend Carol certifies Bob's certification of Alice's key? Alice furnishes her key to Bob, who signs it with his key. Carol signs Bob's key with hers. And you know Carol, and have signed her key. These chains of signing build a "web of trust".
Trust is subjective: You trust other people's certification of other people's keys to the degree you think they're reliable in handling keys. (GnuPG has a way for you to privately mark such certifications that your trust level of that person is "none", "unknown", "marginal", or "full", but we won't get into that, here.)
Groups of individuals occasionally hold in-person keysigning "parties" to build and extend the "web of trust".
Here's a key procedure from a recent key-signing party held by the "Bay Area Debian" group (http://bad.debian.net/list/2001-June/001237.html):
1. Send your key to the key-signing party organizer. You can get your public key out of your keyring by doing a command like this:
gpg --export --armor "email@example.com" > yourname.asc
Then, e-mail yourname.asc to the signing party's
Please, don't encrypt the mail you send to the organizer.
2. Print out a copy of your key fingerprint. This is for you to carry around. You can get a copy of your key fingerprint by doing this:
gpg --fingerprint "firstname.lastname@example.org" > yourname.fp
...and then print yourname.fp out.
3. Make sure you have valid ID, like a passport or driver's license, that has the same name as on your key.
At the Party
0. Get a copy of the keyring printout from the organizer.
1. For as many people as you can, do identification (see below). (We'll probably have a semi-formal, around-the-room session to do mass identification, which I'll explain at the event. It worked pretty well last time.)
2. Meet people and have fun.
Here are the steps that happen when Alice is going to identify Bob.
Alice needs: keyring printout, pencil or pen.
Bob needs: fingerprint printout, ID.
0. Bob presents a picture ID, such as a driver's license or passport.
1. Alice marks on her keyring printout a single check next to Bob's name, to indicate "identified."
2. Bob reads his fingerprint printout to Alice. Alice follows along on her keyring printout.
3. If the fingerprint that Bob reads matches the fingerprint Alice has on her printout, she makes a second check, indicating "fingerprint matches."
Of course, it's nice if they then switch roles, and