Perhaps Google's announcement that Chinese cyber attackers went after human rights activists' Gmail accounts has made you skittish about just how private your own messages are on the Google e-mail service.

Well, if you want to take a significant step in keeping prying eyes away from your electronic correspondence, one good encryption technology that predates Google altogether is worth looking at. It's called public key encryption, and I'm sharing some instructions on how to get it working if you want try it.

Unfortunately, better security typically goes hand in hand with increased inconvenience. But some human rights activists who used Gmail right now likely wish they'd put up with a little hardship to help keep hackers at bay. I'm not going so far as to recommend you use e-mail encryption, but I think this is a good time to take a close look at it.

Specifically, I'll show here how to use a collection of free or open-source software packages: GPG, or GNU Privacy Guard, Mozilla Messaging's Thunderbird e-mail software, and its Enigmail plug-in.

But first, some background about how it works.

Public key cryptography
Encryption scrambles messages so that only someone with a key (or a tremendous amount of computing horsepower, or knowledge of how to exploit an encryption weakness) can decode them. One form is called, curiously, public key encryption, and this is what GPG and Enigmail use.

Here's the quick version of how it works. You get a private key known only to yourself and a public key that's available for anyone else to use. The person you're corresponding with also has such a pair of keys. Although the public and private keys are mathematically related, you can't derive one from the other.

To send a private message, someone encrypts it with your public key; you then decrypt it with your private key. When it's time to reply, you encrypt your message with the recipient's public key and the recipient decodes it with his or her private key.

Messages in transit from one machine to another are a bunch of textual gobbledygook until decoded. If you're being cautious enough to encrypt your e-mail, you should be aware that there's still some information that leaks out to the outside world. The subject line isn't encrypted, and somebody might take interest in the identity of your active e-mail contacts and the timing and frequency of communications.

So how do you find out what your correspondent's public key is? You can either fetch the key firsthand from the correspondent, or you search for it on public computers on the Net called key servers--mine is stored at pool.sks-keyservers.net.

This form of encryption has another advantage: you can sign your e-mail electronically so the recipient knows it really is from you. This time the process works in reverse: you sign your e-mail with your private key, then your recipient verifies it's from you using your public key.

Drawbacks aplenty
Weighed against the encryption advantages of privacy and message signing is the fact that you'll lose access to service you may like or depend on.

When you see an encrypted e-mail in the Web-based Gmail, it's gibberish. Google doesn't index it, so Gmail search doesn't work. And the strong points of cloud computing--reading your e-mail from your mobile phone, your friend's computer, a computer kiosk on the airport--isn't possible. You're once again anchored to your PC with the encryption software installed.

Gmail won't be able to make heads or tails of your encrypted e-mail.

(Credit: Screenshot by Stephen Shankland/CNET)

Another doozy is that the technology, while conceptually manageable in my opinion, quickly gets complicated. It's the kind of thing where you benefit from some hand-holding from your technologically sophisticated pal. Encryption is chiefly used by the expert crowd, so the documentation quickly gets technical, the options quickly go beyond most people's comprehension, and the help quickly can shift from Spartan manuals to grasping at straws on a search engine results page.

Given time and experience, intractable technology can be beaten into submission, though. The bigger problem with encrypted mail is convincing others to install the software and use it. Until then, you'll be like the proverbial owner of the world's single fax machine: nice technology, but there's nothing you can do with it until someone else gets one.

My personal hope is that encrypted e-mail will become more common and that wider use will encourage some flavor of it that will work more transparently with existing systems, perhaps through local plug-ins on a computer such as FireGPG, though there appears to be challenges getting it to work with Gmail.

Meanwhile, here's one collection of software that's available today for public key e-mail encryption.

Install the software
First, install Thunderbird e-mail software, if you haven't already. I recommend the new version 3.0, which is available for Windows, Mac OS X, and Linux. One particularly nice feature is that the software will ask you for your e-mail address and password on its first launch, and Gmail users will find the software automatically handles the tangle of configuration details that previously had to be manually set.

Next up is GPG, the command-line software that handles the actual encryption, decryption, and key management behind the scenes. Fetch the appropriate copy for your operating system from the "binaries" links at the GPG downloads page. Technophiles will like using this actual software from the command line, but don't worry--you don't have to.

Last is installing the Enigmail plug-in for Thunderbird. Fetch the appropriate version from the Enigmail download site and make a note of where you save the file.

Enigmail isn't the kind of file you double-click to install. Instead, go to Thunderbird, open the Tools menu and click Add-ons. In the lower-left corner of the dialog box that appears, click "Install..." When prompted for a location, point to where you saved the plug-in; the filename should be "enigmail-1.0-tb-win.xpi" or some other operating system-appropriate variation.

Set up the software
Next, it's time to get started. Enigmail offers useful instructions that generally are up to date, though they don't mention Thunderbird 3.0 and some other matters.

You'll likely get a setup Wizard from Enigmail, which is fine. My advice: set it to sign encrypted messages by default but not to encrypt messages by default unless you're confident you're going to use it a lot.

The first task is generate your public and private keys--your "keypair." Enigmail can handle this chore. In Thunderbird, click the OpenGPG menu, then the "Key Management" option. A new window will pop up with its own set of menus. Click the rightmost one, "Generate."

The default options are pretty good, though setting the key not to expire might be preferable for some people. That can be changed later, if you have second thoughts. For your passphrase, the usual password rules apply: the longer it is and the farther away from anything in a dictionary it is, the harder it is to crack.

Now comes the best part of the whole thing: helping out the random number generator while the keys are being generated. It doesn't take long, but doing something else while it happens--browsing a Web page or loading a word processing file, for example--creates events that actually inject a little helpful unpredictability into the algorithm. It's one of those wacky computer science moments.

Once the keys are generated, upload yours to a key server so your pals can find your key. It's easy: click the "Keyserver" menu, "Upload Public Keys," and go with the default pool.sks-keyservers.net server.

Try it out
Now it's time to get viral. You have to find somebody to experiment on. Go through your list of nerdy, security-minded, perhaps somewhat paranoid friends and start recruiting. A tinfoil hat isn't a prerequisite for using e-mail encryption, but there's a connection.

Once you've got a companion--or set up a second keypair with another e-mail account--start a new e-mail message and type in a subject line and some text. In the OpenPGP menu, select "sign message," "encrypt message," and if your message recipient is using Enigmail, "Use PGP/MIME for this message." (The latter option has some advantages, but isn't supported universally.)

When you send the message, you'll need to use your recipient's public key to encrypt the message and your own passphrase to sign the message with your private key.

When it's time to read, you'll need the public key of your correspondent to verify the signature and your own passphrase to decrypt it.

Sending and receiving is where those public key servers come in handy. Seek, and if ye don't find, ask your friend to e-mail you the public key.

There's a whole new world of encryption out there--the web of trust, key signing, fingerprints and such--that I won't get into here. I recommend a look at the Enigmail configuration manual and the Enigmail Handbook.

If you're a command-line nut, I recommend Brendan Kidwell's practical introduction and, with my usual reservations about the utter lack of informative examples, the GPG man page. History buffs can check the Wikipedia pages (the saga of Phil Zimmermann vs. the U.S. government concerning GPG's precursor, PGP, or Pretty Good Privacy, is particularly notable), and one 10th-anniversary GPG retrospective from founder Werner Koch.

In closing: backup your key
There is one last task you should attend to: export your keypair. Enigmail can handle this fine: In the search field, type your name until your key appears, click it to select it, then click "File" and "Export Keys to File."

This backup will be useful for decrypting your mail on a new computer, installing software from scratch, or otherwise managing the inevitable digital transitions in your life. But be warned: that private key is what somebody needs to crack your encryption, so don't leave it where somebody can find it.

I'm not convinced that GPG will rule the world. Indeed, I'm concerned that so much documentation I encountered for this article was written before Windows Vista arrived.

But I am convinced there are serious holes with our current security and privacy arrangements. A 2,048-bit encryption key won't thwart phishing scams or other social engineering attacks that appear to have been employed in the Google-China case, but it's a good place to start.

And using encryption sends a message to the technology world: perhaps it's time to start taking our security more seriously. Google opted for encrypted Gmail network connections, even though it will tax their servers with more processing, which is a good start. Better security can be inconvenient and expensive, but don't forget to consider the drawbacks of poor security.

This Google Doodle featuring the Esperanto flag was exploited by scammers to spread malware, according to Barracuda Networks.

(Credit: Google)

Online scammers are taking advantage of the public's interest in the Google Doodle to spread malware, a security firm warned on Tuesday.

In so-called "SEO poisoning," scammers use search engine optimization techniques to increase the distribution of malware. They create special malware-rigged Web sites or hide malware on legitimate Web sites they've compromised and then use tags associated with popular search terms to get them listed high up in search engine results.

Typically, scammers capitalize on public interest in news events or celebrities, targeting searches like "Swine Flu" or "Michael Jackson death." But in the latest twist on this technique, scammers are exploiting interest in the Google Doodle, the graphics that often take over the Google logo on holidays or to mark special events.

For instance, the doodle on Tuesday showed a flag for Esperanto, a universal language created by L.L. Zamenhof which is based on parts from a variety of languages. Clicking on the doodle, located near the search box, brings up a list of search terms for "L.L. Zamenhof."

Dave Michmerhuizen, a research scientist at Barracuda Networks, found 31 poisoned sites among the first 100 results, 27 of them in the first 50 sites alone.

On the first results page was a link leading to a compromised Web site that redirects visitors to a fake antivirus site, according to Michmerhuizen. That site displays a fake alert saying the computer might be infected and does a fake scan before prompting the user to pay for antivirus software, he said.

A Google spokesperson said the company had already removed many of the allegedly malicious sites from the index using manual and automated processes to enforce the policies.

"As you probably know, the use of popular search terms to target malware is neither a new vector nor unique to any particular search engine. We work hard to protect our users from malware, and using any Google product to serve malware is a violation of our product policies," the spokesperson said in an e-mail.

"Our Safe Browsing technology is capable of detecting malware being served from sites that have been compromised," the Google e-mail said. "In fact, as we've explained publicly, we have been seeing more infections coming from compromised sites" across the entire Web.

The compromised site on the Google Doodle-related search results page leads to a site selling fake anti-virus.

(Credit: Barracuda Networks)

For about the 4,000th time in the last five years, I tried to sign up for a new Web service, but it wouldn't accept my proposed password. Apparently, the site operators decided that passwords should contain only letters and numbers. Aarrrrgh! This isn't the first time I've seen this idiocy, and it won't be the last. But it should be.

Guidelines on how to construct a strong password almost uniformly recommend using a mixture of upper and lower case letters, numbers, and symbols. Tools for generating passwords (for example, strongpasswordgenerator.com) encourage the use of symbols. There's even a mathematical formula that precisely calibrates how much more unguessable symbols make a password. So why don't sites support symbols in passwords? It makes no sense.

The strongest case against limited-character passwords isn't technical. It's not about "information entropy." It's about human factors and behaviors. Human factors dominate the success (or failure) of all information systems, including password systems. Humans are lousy at choosing random or quasi-random sequences--exactly the kind of high-entropy, hard-to-guess passwords that information security professionals think ideal. People are even worse at remembering said passwords.

So the pragmatic balance is a middle ground--passwords that are strong enough to thwart hackers' brute-force attacks and guessing algorithms, but easy enough that when someone is presented with a sign-in prompt, they're not stumped, frustrated, and ready to reset all their pass codes back to something like goofydog that easily lets hackers break into their account.

One good solution is using a password generator, such as PasswordMaker. Give it a Web site's URL, as well as a master password; it hands back a strong password such as Ga9i)t|Z that's unique to that site. A hundred different Web sites? No problem! A hundred different passwords, each of them very strong, yet the user has to remember just one (or for the very paranoid, a few) master passwords. For those using Firefox, there's even a plug-in; give it your master password once (per browsing session), and a single keypress automatically fills in the correct strong password whenever it's needed. It's not quite smart card or SecurID strong, but it's plenty strong for most uses, yet easy.

Sites that restrict the characters that can be used in passwords--they are the monkey wrench in this machine, the fly in this ointment. They don't accept the strongest of passwords, thus thwarting users' attempts to pragmatically balance password strength and ease by using password generators. This just encourages users to fall back to easy-to-remember, easy-to-hack passwords. Sigh. Sites that restrict password characters? You are doing it wrong.

While we're waiting for the laggard site operators to get passwords right, there is a good fallback: mnemonic abbreviations. Take a phrase you can easily remember, and turn it into an acronym. For example, "Coffee is my favorite beverage on Planet Earth" might become CimfboPE. You can spruce this up a little further, if you like, by doing letter-number substitution (e.g. 0 for o, 1 for i, 3 for e, and so on,). Hackers probably aren't going to guess C1mfb0PE any time soon, yet it's surprisingly easy to recall when it's needed. Farhad Manjoo's article "Fix your terrible, insecure passwords in five minutes" explains this technique well. For some, mnemonic abbreviations are a fallback; for others, they may be strong enough to use for all passwords. After all, anything's better than goofydog.