Can someone else read my e-mail?
Umm -- could you be more precise? Who can read my e-mail?
Lots of people, starting with the system administrator of every machine
your mail touches, plus anyone who has hacked those machines, plus anyone
who is eavesdropping on any of the networks passed. (There are many
more ways for a hacker to get at it, too....)
Ulp. Let's take this one at a time. Why are so many system
E-mail rarely goes directly. Most PC mailers are so-called "thin
clients". They do the formatting (and often minimal formatting at
that), but never deliver the mail directly. Instead, they pass it
off to a mail server for actual delivery. The mail server may pass
the mail on to a higher-level server, especially for Internet email
which passes through a firewall machine.
Inbound mail is vulnerable as well. There are often multiple levels
of relaying (including, of course, the firewall) before it reaches
the end-user's mail server. From there,
the user generally uses something like POP3 to download it to the PC.
UNIX users go through a similar dance, though in their case the mail
is likely to be read by someone who has logged in remotely to the
mail server, either via rlogin or via an X window.
The real point, though, is that the mail will sit on the disk of
each of these machines for some amount of time. That makes it easy
pickings for anyone with privileged access to those machines.
Even the originating and receiving users machines are vulnerable,
if not directly then via their network usage. For example, if
the user relies on a network file server, that machine has the
actual mail. Similarly, if a computer is backed up over the network,
the backup server has copies. Are all of these machines secure?
What about the network? Can someone "wiretap" it?
Absolutely, though that's a hard way to get at the mail. It's much
easier to (ab)use the network to gain access to a user's account,
and proceed from there.
What sorts of network abuse?
That's getting into the whole area of network security, about which
entire books have been written. But let me give a few examples.
First, of course, an attacker can pick up your password. This is old
technology, and works very well. And bear in mind that many POP3
clients transmit your password every time they check for mail.
For UNIX users, IP spoofing is an easy way to gain access to the
server. Failing that, it's often easy to connect to a user's
X server and read keystrokes and screen images that way.
Okay, I'm convinced. Can I use encrypted email?
Sure. But unless you use it properly, it's not going to do you
Here we go again. Could you please be more precise?
Boy, some folks are never satisfied.
Let's start with what we've already talked about. If you're logging
in to a remote machine to read your mail, you're still toast,
because the mail will traverse the net after you've decrypted it.
For that matter, the password you use to unlock your secret key
will traverse the net, too. Or maybe the attacker will just pick up
your keystrokes from your X server.
Are you saying that only UNIX users shouldn't use encrypted e-mail?
Oh, no. PC users can be just as vulnerable, though to different
attacks. For starters, remember what I said before about networked
file systems and backup servers. And have you shared your own
Moving on from there, consider the lovely things that can be done with
tailored viruses. There have also been a number of bugs in Web browsers
that permitted access to arbitrary files on the machine.
I give up. What should I do?
Ah, that's the right question. Here are some guidelines:
Start with a good encryption package (see below). If the
basic technology is no good, you're just wasting your time and money.
Use it properly, don't take shortcuts, and follow the
instructions. They're there for a reason.
Encrypt and decrypt mail only on secure machines. The level of
security depends on how sensitive the information is (and on how
paranoid you are). My own laptop is probably more secure than
the corporate firewalls -- but I'm a paranoid by profession.
If you don't know how to secure your machine, get help. The
general rule, though, is to ensure that as few services as possible
are running, even if it means sacrificing some convenience.
If you're connecting to a secure machine over a network, it's probably
not a secure machine... There are exceptions, of course, especially
if you use a cryptographically protected channel to log in.
Your secure machine should never extend trust to an insecure machine.
For example, never run programs from an insecure source, either by
downloading them or by executing them from a file server. Similarly,
don't permit X server connections from insecure machines, even
if they travel over an encrypted channel.
Don't store cleartext copies of sensitive mail. Either save only
the encrypted form, or use an encrypting file system. There are
packages available for both UNIX and Windows systems.
Keep the machine physically secure. Physical access wins -- always.
Last, don't make the machine so secure that it's unusable. If it
is, your mail will be less secure, because you'll never use the
What is a good e-mail security package?
Look first at its general characteristics:
Start with a decent key size. 40-bit systems are good enough to
keep out 6th graders. They might keep out high school students;
they won't protect you from anyone with access to a LAN-full of
machines. 56-bit DES systems are at best marginal. They'll keep
out the casual hackers, but are weak against an adversary who can
spend just a few hundred thousand dollars. Recently
Clearly, the list of groups that can afford such
includes most medium-sized companies. And I'd bet that
most major governments already have DES-cracking abilities
Use a well-known cipher. Proprietary algorithms are generally
worthless. Eric Thompson, CEO of AccessData -- a private-sector
cryptanalysis firm! -- estimates that the average home-grown
cipher takes about a day to cryptanalyze.
DES is good -- or would be, with a longer key length; use
triple DES instead. RC4 (with a decent key size) is well-regarded,
as are IDEA and RC5 (again, with a decent key size).
(Note, though, that some of these are patented.)
The best choice is the
Encryption Standard (AES); it's fast, free,
and strong enough for
Make sure it's configured properly (i.e., disable any use of 40-bit
Buy from a reputable firm that understands security. There are lots
of little things to get right, like making sure a copy of the key
doesn't get written out to the swap area.
Can I get away with doing less?
As with any security system, that depends on who your enemies are.
If your main concern is eavesdropping on the public Internet or at
your recipient's site, you may be able to disregard some of these
precautions. If your own site is at all dangerous -- and that's
actually fairly likely -- yes, you do need to be very careful.
Do I need a certificate?
Certificates are a way of assessing the authenticity of a public key.
In other words, they only matter if get the key from a dubious source,
such as a public key server or directory. If you get the key from someone
you trust -- and in particular if the owner gives it to you directly
(not by email!), you don't need a certificate.
If you do use certificates, make sure you trust the issuer. You can
buy your own certificate-issuing program, but the machine it runs on
has to be very secure; if it gets compromised, your entire
secure e-mail infrastructure may be compromised.
What secure mail package should I use? My Web browser supports secure
email; can I use it?
I'm loathe to recommend specific products. In general, though,
smaller is better. Complexity is the enemy of correctness -- and
hence in this case, of security. That tends to suggest that
browser-based solutions are not ideal. On the other hand, some of
the latest be-all, do-all mailers aren't any smaller.
for an example of how software bugs can subvert cryptography.
I should add that with proper software structuring techniques, a
large program may be able to provide adequate protection of the
security-sensitive pieces. But that's hard, and requires a
degree of self-discipline that's relatively rare.
Stand-alone programs, though sometimes less convenient to use, are
much more likely to be secure.
There is one class of secure email program to avoid at all costs.
These are intended for use when you wish to send email to someone who
doesn't have a decryption program. These encryptors package up the
ciphertext in a self-extracting executable and send it to the
Now -- consider the security model from the recipient's perspective.
At a time when they think that someone might be reading their email,
they're supposed to (a) run a program sent to them in an unauthenticated
fashion, and (b) type a secret into this program of unknown origin.
And this is quite apart from the more general class of bad things that
can happen from trusting emailed executables.
Regrettably, several otherwise-responsible vendors have introduced
such products. Don't just trust the brand name; some ideas are stupid,
no matter who sells them.