In depth: Thanks to software like GNU Privacy Guard (GnuPG or even just GPG), the kind of encryption that was used only by top secret government departments is now open to all. In many ways GnuPG is more than just a free software implementation of Phil Zimmermann's notorious Pretty Good Privacy (PGP) software, and a lot more than just another piece of cryptographic software.
With GnuPG you can check the integrity of an email message, authenticate the sender and keep its contents safe from prying eyes without going near a patented encryption algorithm.
Your mission, should you choose to accept, is to liberate your files and communications from the tyranny of snoopers. For further instructions, calmly place this tutorial in your suitcase, put on the goggles and the hat, and make sure no one's following you as you exit the GUI lounge and make your way to the keyboard.
GnuPG is available in the regular one-size-fits-all tarball, which is easily installable with ./configure, make, and make install (as root, as usual) without much hue and cry over missing dependencies. But with software such as GnuPG, you can save yourself the trouble and grab it from your friendly distribution repository.
That's because, most developers working on the popular distros use GnuPG, so it's one of the most thoroughly vetted pieces of software out there. In terms of size, it's also the software equivalent of a Chihuahua, so you can grab it over the puniest of dial-up connections.
But before you head over to the download page or fire up the package manager, open a terminal and type which gpg or which gpg2. It'll tell you if you've got GnuPG (or its newer GnuPG 2 avatar) on your box and where it's installed.
GnuPG is big on keys, so you'd better engage your brain before you put your mouth in gear. Traditional cryptography provides secrecy via a shared secret key. To decrypt an encrypted message, you need to have that key. In the classical war movies, it was the grocer who ferried the key on the reverse of wine bottle labels. Romantic as it may sound, it wouldn't be very useful in real life, especially if the encrypted message originates from the other side of the planet.
The more practical approach is to replace the single secret key with a set of public and private keys. Public keys are made available to everyone, and private keys are kept secret. In essence, with this system (known as asymmetric cryptography) everyone has their own secret private keys, and everyone's public keys.
Now when A Mole wants to send a message to John Doe, he encrypts the message with John Doe's public key. Even if PI Dick intercepts the message, it wouldn't make much sense to him, because only John Doe can decrypt the message with his private key. And it gets smarter. Using GnuPG, A Mole also signs the message with his private key, which assures John Doe that the message is from A Mole.
Now take this example, and extend it to storing and transferring encrypted files as well as signing and encrypting email messages and instant messages, and you become a much tougher target for eavesdroppers.
Gimme two keys and hold the sauce
Time for some command-line kung fu. Fire up a console and start the key generation process with gpg --gen-key. You'll be asked to select: the kind of key you want; the keysize; the validity period of the key; and your name and email address, along with any optional comments about the key. The default option is best for most of them, but it helps to input your name, and email address.
When it has all this info, GnuPG will ask you for a passphrase. You'll need it to sign stuff you send and decrypt stuff you receive, so make sure it's something you can recall. But don't choose anything docile enough to fall to a brute-force dictionary attack.
Since GnuPG feeds on innocent random bytes, it asks you generate a lot of them while it's generating the keys. In the good old days, launching OpenOffice.org or starting Firefox with 15 default tabs was sufficient for this. With the dual-core processors and flab-free apps you have today, you'll need to be encoding a video while compiling an app on your virtual machine to gain enough entropy.
Finally it'll print out your newly created key. Since it's fully domesticated, GPG even puts your key in a key ring. Congratulations. You are now a proud owner of your very own random bits of alphanumeric data.
Step by step: create keys with GPA
Generate keys: If CLI makes your fingers cramp, you can use GPA. If you launch it when you haven't created any keys, it prompts you to do so. If you choose to let it pass, or if you already have a key and want to create a new one, do Keys > New Key.
Enter your details: GPA then takes you through the process of creating your key, which involves surrendering personal information such as your name, email address, and such. Don't sweat - it's putting it all to good use.
Keyring editor: When you're through with the process of creating the key, you're dropped back to GPA's Keyring Editor interface. It lists your key along with lots of useful information about it, such as your key ID and fingerprint.
Order in chaos
It's hard to believe, but there's some structure in that random assimilation of characters GnuPG calls a key. At the console, type gpg --list-keys, which will print something like this:
pub 1024D/CFEA026E 2009-01-18 [expires: 2009-02-08]
uid Mayank Sharma (For locking documents and other files) <email@example.com>
sub 1024g/4CC088D2 2009-01-18 [expires: 2009-02-08]
The first line is the complete path to your public keyring, intelligently called pubring.gpg. You have another one for storing secret keys, called secring.gpg, and you can view its keys with gpg --list-secret-keys. Since you only have your own key at the moment, the contents of both pubring.gpg and secring.gpg will be the same, until you import someone's public key into your public keyring.
The second line is a series of hyphens to make up for the developers' lack of user interface design experience.
The third line is the most important . The pub is for public key; the 1024D is the number of bits in the key; CFEA026E is the unique key ID, which is followed first by the creation and expiry dates of the key. The fourth line is the user ID, with your name, email address and the comment specified while creating the key. The last line is the sub key which lists info in the same format as the pub portion of the key.
All keys also have a fingerprint. To see yours, type gpg --fingerprint, which produces an output similar to gpg --list-keys with an additional fingerprint line, something like:
Key fingerprint = A3E7 007A 6277 77BB 2A4B 61A7 1ED7 562B CFEA 026E
You can use the fingerprint to verify if the key is from the person you expect.
Load 'em up
Before others can send you encrypted files, they'd need your public key. For that you'll have to make your public key public. If you're part of a small secret collective of evildoers (or indeed a small group with non-nefarious ends) you can export the key into a file and email it to your peers, or you might also want to keep the keys in a text file for backup purposes. The command gpg --armor --export 86D68524 --output 7of9.asc will save the public key with key ID 86D68524 in a file called 7of9.asc, which you can then send to all members of your collective.
But the most popular way to share public keys is via a public key server. There are lots of these servers out there and they all sync with each other periodically, so it doesn't really matter which one you use. I'll use the MIT PGP server to send my keys with gpg --keyserver=x-hkp://pgp.mit.edu --send-keys 86D68524. You can also use the web interface on http://pgp.mit.edu to paste the PGP key you exported with the --armor option.
Now that you've exported your public key for others to encrypt files for you, it's time you import their keys as well. The mutual exchange of public keys is essential for a two-way encrypted communication. In other words, you need their public keys to encrypt files for them.
Just as with exporting keys, you can ask your fellow collaborators to email you their public keys. When they do, import their key (called key.asc) with gpg --import key.asc.
The other popular option is to search a public key server and retrieve the keys from there. If you are looking for your friend, Hu Burrows, the command gpg --keyserver=x-hkp://pgp.mit.edu --search-keys Hu Burrows queries the MIT PGP server for all keys which have Hu Burrows in their ID and throws back a list:
gpg: searching for "Hu Burrows" from hkp server pgp.mit.edu
(1) Hu Burrows <firstname.lastname@example.org>
1024 bit DSA key 89D62524, created: 2009-01-16
(2) Hu Burrows <email@example.com>
1024 bit DSA key E0B08B2D, created: 2008-07-05
Enter number(s), N)ext, or Q)uit >
When you find your friend, enter the corresponding number and his key will be automatically imported into your public keyring.
Step by step: import a key
Find the key: If you have it on your disk, click on the 'Import' button in the Keyring Editor interface, and locate the key with the inbuilt file manager. To fetch keys from a key server, head over to Server > Retrieve Keys and enter the Key ID of your friends key.
Set owner trust: To put GnuGPG at ease, right-click on teh key and select 'Set Owner Trust' from the menu. This brings up a window listing different levels of trust, and offers adequate information to help you make a decision.
Sign the key: If you really trust the person who sent you this key, you'd also want to sign it. Again, right-click on the key in the Keyring Editor, and select 'Sign Keys' from the context menu. GnuPG signs the key with your key after confirming it with you.
Sign me keys
If you've been to a Linux conference or your local LUG meet, chances are you'll have found a bunch of excited geeks running around with self-attested sheets of paper with gibberish printed on them. Since the geeks were so involved and you were looking for free beer, you probably didn't ask them what the fuss was about. Here's the scam in a snap - they were just trying to get their peers to sign their keys.
The paper had their key ID, and their fingerprint, and was signed by hand. To get M Entor to sign her keys Ruckie showed him this sheet. Then M Entor imported Ruckie's keys from a public key server, checked the fingerprint and UID and signed it with gpg --edit-key firstname.lastname@example.org.
After signing the key, M Entor has to send the key back to the public server, just like he sent his own public keys earlier. Next time on when another user downloads Ruckie's keys, they'll be able to see all the signatures on the key with gpg --list-sigs email@example.com, which produces an output similar to:
pub 1024D/FBD7E879 2009-01-18
uid Ruckie <firstname.lastname@example.org>
sig 3 FBD7E879 2009-01-18 Ruckie <email@example.com>
sig CFEA026E 2009-01-18 M. Entor (For patches and releases) <firstname.lastname@example.org>
sub 1024g/7004C897 2009-01-18
sig FBD7E879 2009-01-18 Ruckie <email@example.com>
But why do people go through all this trouble to get their keys signed? Because it's very easy for anybody to impersonate you, create keys under your name, and send them to people who trust you. On the other hand, if your real keys were signed by mutual friends, your friends would instantly know the real from the fake.
With the public keys exchanged, we are finally all set to convert ordinary text into extraordinary gibberish. This command, gpg --encrypt --recipient 'firstname.lastname@example.org' Ten_Places_to_chew.pdf will encrypt the specified PDF file with our friend Hu Burrows' public key. The command automatically creates a binary file called Ten_Places_to_chew.pdf.gpg. If you append the --armor option, you'll end up with file called Ten_Places_to_chew.pdf.asc that opens in your text editor but displays a long list of random alphanumeric characters.
Once the file is encrypted even we can't decrypt it, and it's safe for transport over unencrypted channels.
What if you want to encrypt a file to keep on your disk? Since you already have your own public key in your keyring, all you need to do is make sure you are the lucky --recipient.
Hu Burrows got your file and has sent you a reply. To your email client it's complete gobbledegook. You've been sent junk before, but this is different - the encryption is strong in this one. Download the attachment, fire up the console and type gpg --output foo.txt --decrypt foo.txt.asc. GnuPG recognises your public key, finds a corresponding private key in your keyring and prompts you for the passphrase. Once satisfied it does its magic and decrypts the file.
The procedure, or more accurately just the one command for decrypting files you've encrypted for yourself, isn't any different. Since you had marked yourself as the recipient, GnuPG looks for your private key while it's decrypting, finds it in your secret keyring, and after verifying your passphrase, obediently decrypts the file.
Sign clearly please
It's not necessary to always encrypt all your communications. Sometimes a little sign that says "Hi, this is from me! Verify." is all the doctor ordered. If Blac Oder wants to send a signed text file called leaks.txt to Mel Chat, he'd type gpg --clearsign leaks.txt, which creates a leaks.txt.asc file that looks something like:
-----BEGIN PGP SIGNED MESSAGE-----
Security isn't a dirty word.
Leak is a positively disgusting word.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
-----END PGP SIGNATURE-----
To verify the signature, Mel Chat types gpg --verify leaks.txt.asc and gets something like the following:
gpg: Signature made Tuesday 20 January 2009 01:59:00 AM IST using DSA key ID CREA026E
gpg: Good signature from "Blac Oder <email@example.com>"
Almost everyone who creates very strong passwords suffers from password amnesia at some point in their life. But unless you can travel back in time to retrieve your passphrase, you'll have to fall back to rather mundane mechanisms like a revocation certificate.
When you create a revocation certificate with the command gpg --gen-revoke 86D68524, GnuPG asks you for a reason for revocation, and prompts you for an optional comment and finally your passphrase. Keep the revocation certificate some place safe. When you need to use it, simply import the certificate into your keyring and then resend the key to the key server to revoke your public key.
Step by step: encrypt/decrypt a file
Select a file for encryption: The Files button in the Keyring Editor brings up GPA's built-in file manager. Use the 'Open' button to either select a .gpg or .asc encrypted file or any other file for encryption.
Encrypt and sign: When encrypting a file, GnuPG brings up a window to let you select the recipient's public key. You also have the option to sign the encrypted file with your private key. Click on 'OK' to encrypt the file.
Verify and decrypt: If you receive an encrypted file, signed by its author, it's a good idea to verify the signature of the file, so select the file and click on 'Verify' in the file manager. When you're satisfied, hit the 'Decrypt' button and let GnuPG do its magic.
Time to get GUIing
Like any Linux app, GnuPG lives and breathes on the command line. But it's highly adept with the GUI and can find its way around with a mouse as well. GPA (the GNU Privacy Assistant) is a GUI front-end for GPG. It's still just a beta release, but is fully functional and works quite well. Again you have the option to compile it from source or grab it from your distro repository, which is what we'd recommend.
There are also front-ends for Gnome (Seahorse) and KDE (KGPG). The best thing about all three clients is that you can use them all together with the command line without any issues. So you can create keys in GPA, import public keys from Seahorse, sign them and upload them via KGPG.
A big relief is that all clients have similar features. All can create and manage keys, publish and retrieve keys from key servers, encrypt, decrypt, sign, and verify files, etc. Desktop integration is the only area where both KGPG and Seahorse score over GPA. In their respective desktops, they'll pop up in the file manager, show up in text editors, and find their place in the right-click context menu.
For securing email with GnuPG there's the Enigmail plugin, which fits on to Thunderbird.
We've encrypted and signed enough files for one day. Is Big Brother reading your emails? I don't know. But what I do know is that he's certainly not reading mine!
You should follow us on Identi.ca or Twitter