People often complain that using encryption in email is too much work. Sometimes, it can be fraught with difficulty for the encryption novice. Managing public and private keys can be confusing at first, and getting someone at the other end to use encryption as well can sometimes be a challenge. Worse yet, it can be difficult to maintain an encryption key "identity" properly once you've gotten everything set up — as things stand, good encryption practice is not a "fire-and-forget" proposition where you can just go through the hassle of setup once and be done with it.
It requires maintenance.
Sure, it's easier to just skip the encryption. I sympathize. While I'm sufficiently motivated to set up encryption keys for myself and maintain the attendant identity, I sometimes find the persistent encryption identity maintenance downright annoying. I can understand the desire to forget about it, and just ignore good encryption practice altogether. There's just one problem with that attitude: it's stupid.
Encryption is your last defense against malicious security crackers violating your privacy. When all other means of protecting the data on your computer prove fruitless, encryption is the last barrier against your most sensitive data being accessible to people who simply should not have it.
When you're communicating with someone else over the Internet, encryption is also your first line of defense. Authenticating on the SMTP server that handles your outgoing mail should only be done via an encrypted connection (and no SMTP server should operate without some attempt to authenticate users), so that a malicious security cracker "listening in" will not be able to pluck your username and password out of plain text communication. The same is true of receiving emails, and authorization on your POP or IMAP server for incoming mail should be encrypted as well. Hopefully any regular readers of TechRepublic's IT Security Weblog already know the importance of SSL/TLS encryption (usually marked by the
https:// URI scheme) for accessing any website — like a Webmail server — that requires authentication and provides access to sensitive data.
Sometimes, more than simply the authentication should be encrypted, however. If you are discussing private matters, and sharing sensitive data — such as passwords, trade secrets, social security numbers, home addresses and telephone numbers, the schools your children attend, or any of a number of other pieces of information that might be abused — you don't want outsiders being able to "listen in" on that either. Encrypted connections with your mail servers protect only the leg of the journey between you and the server on your end, even if the encryption protects the entire session rather than just authorization. Even if both of you use encrypted sessions on your respective mail servers, you still have to consider the problems of the other third of the journey, between the sender's SMTP server and the receiver's POP or IMAP server.
An often overlooked weak point in the security of data over an email's journey is the actual mail server itself. Even if two mail servers somehow negotiated a secure, encrypted connection through which plain text emails could be passed without fear of being intercepted and read along the way, the mail servers themselves are probably not impervious to eavesdropping. How do you know, when you're sending an email, that they have not been compromised by some malicious security cracker that will search through emails for sensitive data? Are you maintaining the server yourself, or is it maintained by your IT department's netadmins, your ISP, or someone else entirely that may not have your best interests at heart? Too often, people assume that the servers that manage their daily communications are free of any suspicion without even knowing the names of anyone that actually has daily, unfettered access to those servers for maintenance purposes. Are you willing to bet your security on the assumption that people you've never met — never even heard of — are trustworthy?
There are two defenses against all these hazards along the way:
- email encryption
- email avoidance
When communicating about sensitive subjects, you can either encrypt your email or simply not send it. Anything else is not secure. You may make the argument that nothing is ever truly secure, and there's some truth in that statement, but there are degrees of relative security — and security that is unlikely to be broken within this century at current levels of encryption cracking technology is far better than "security" that amounts to doing the next best thing to tracking down a malicious security cracker and handing over all your secrets yourself.
Keep in mind that any other form of long-distance communications may be subject to eavesdropping as well, particularly when you aren't using encryption. The dangers are significantly different in many cases, such as when using a telephone, and the solutions to the problems those dangers pose are very different as well. Those dangers exist, nonetheless — so choosing to discuss something over your cellphone without encryption just because you don't trust email without encryption doesn't necessarily make you more secure. All that changes is the threat landscape.
I use encryption with IMs whenever it is reasonable to do so. I prefer Pidgin — available for pretty much every major workstation-capable OS, including MS Windows, Linux distributions, BSD Unix systems, and MacOS X — with the OTR encryption plugin. For MacOS, Adium X is probably a better choice of multiprotocol IM client that supports OTR, because the Pidgin developers do not officially support that platform.
I use encryption whenever I have to send sensitive data via email. I prefer Mutt with GnuPG, a popular combination on Unix systems such as FreeBSD and Linux-based systems like Debian. GnuPG can also be used on MS Windows, such as via Gpg4win, with email clients like Microsoft Outlook, Claws Mail, and Mozilla Thunderbird.
What I don't do is use unencrypted communication methods to share sensitive data. Discussion in person is the only suitable replacement, barring life-threatening emergencies, for due diligence in maintaining my long-distance communications security. If the other party doesn't want to go through the effort of learning to protect both himself and me over long-distance communications media, he must not want to be able to communicate over such media on subjects of a sensitive nature at all.
The alternative — sending plain text emails for anyone with a packet sniffer to read at his or her leisure — simply isn't an option where important, sensitive data is concerned. Sensitive data must be encrypted, or it must not be sent at all. Knowing what I know, to treat the matter otherwise would just be stupid.
Chad Perrin is an IT consultant, developer, and freelance professional writer. He holds both Microsoft and CompTIA certifications and is a graduate of two IT industry trade schools.