E-Mail Encryption: Why Isn't Everyone Doing It?

[Shawn K. Quinn]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday October 23 2002 08:48, Eric S. Johansson wrote:
> that's not an entirely fair answer.  Phone encryption isn't done
> because people have an unrealistic expectation of privacy.  Same is
> true of postal mail; it's an envelope, it can't be easily snooped.=20
> e-mail is perceived as being hard to read on the wire because the
> end-user can't see it except with their e-mail client.

A good way of shattering this perception would be to use a program like=20
dsniff or Ethereal as part of a controlled demonstration on a closed =20
network (i.e. disconnected from the Internet) specifically dedicated to=20
the purpose. Outside of a controlled demonstration, of course, you run=20
the risk of violating laws such as the ECPA (in the US).

To really hammer it home, it should be made clear that everything is=20
just peachy as long as you trust *every* person with the capability of=20
root/administrator access on the path between and including you, your=20
mail servers, your recipients' mail servers, and your recipient.=20
Finding out just how many people have root on e.g. AOL's or Earthlink's=20
mail servers will quickly show this group is much, much larger than=20
most people think, as in at least one order of magnitude larger.

In theory, anyone can install Linux or one of the BSD variants on a=20
laptop, plug two network cards into it, configure it as a bridge, and=20
put it in front of a gateway with tethereal or tcpdump running full=20
time capturing everything that goes through it to disk. It is very=20
difficult to detect the difference between a legitimate dumb switch and=20
a laptop with two network cards conveniently set up to run a sniffer=20
and log everything. Also note that a bridge does not need an IP=20
address, and most attackers would in fact not want it to have one.

(Do realize that actually doing this almost certainly violates policy at=20
any decent company and probably every single applicable law. I am=20
definitely not advocating anyone actually do what I described, far from=20
it, however I do want to make sure as many people as possible are aware=20
of the risk of sending unencrypted e-mail!)

> I've often thought it would be "amusing" to capture e-mails in
> transit to make them visible via a Web interface.  Obviously one
> would need a very good lawyer and plenty of $$ to defend yourself but
> it would get the point across about e-mail not being private.

This just seems too risky. Especially in the US, where we have laws like=20
the ECPA, this seems like a one-way ticket to prison (and bankruptcy if=20
a civil suit is filed as well). A controlled demonstration on a closed=20
network probably would not.

> Now, more directly to Carl's question:
>
> 1) user interface sucks

KMail seems easy enough. If only more programs were as user friendly.

> 2) users will barely tolerate a single password and a pass phrase is
> just plain rejected

Well, they do so at their own risk, and I do not think it would be that=20
infeasible to brute force anything up to about three-word Diceware=20
passphrases. If they realized just how insecure a one-word "passphrase"=20
was, I think more would warm up to the idea.

> 3) it's not integrated into the client delivered by the ISP

Unfortunate, but not a total show-stopper. AOL is the worst offender=20
here, they don't even allow you to bring your own software to read AOL=20
e-mail. (You could always go get an account from HotPOP for $10/year=20
and a POP-capable e-mail program, but many will see it as not worth the=20
trouble.)

> 4) it's too much like work to dig up keys of the other person

I disagree. If I send you my key, all you have to do is copy and paste=20
into a running 'gpg --import'. If you have the right options in=20
gpg.conf, you might even get a version of the key sans things like=20
photographic user IDs automatically. This is the one thing I dislike=20
about KMail; it does not let you import keys easily.

> 5) the user interface still sucks

I agree somewhat that the console mode interface to GnuPG does suck.=20
Even I would like to see some form of native GUI interface(s) at some=20
point, and I have become accustomed to doing many things via CLI.

> I'm encountering similar problems with the camram antispam system.=20
> I'm trying to figure out how to train system without letting the user
> know that they're the training system.  It's a challenge getting the
> user to do anything different.
>
> As part of the camram system, I'm trying to address some of the
> encrypted e-mail in transit issues.  For example, I will be
> propagating public keys as part of every message.  I'm going to
> ignore the whole key server infrastructure because it just won't
> scale (think one public key per user per year, no revocation).

Not sure just how workable this really is in practice. You'll have a lot=20
of useless keys before too long. We already have keys created with very=20
old versions of PGP that are still floating around on the keyservers. I=20
know at least two or three of the keys with my name on them (mostly=20
ones with FidoNet addresses) are completely useless, yet they live on.=20
Designing a system to generate bloat like that on purpose strikes me as=20
bordering on insane.

> The next sacred cow to be slaughtered is I will not require any
> passphrases.  Yes, if an attacker gets in and steals the private key,
> they can cause all sorts of mischief.  The chances of the happening
> are extremely low especially if we generate new keys on a regular
> basis.

This is still incredibly dangerous. At one time, I did not use=20
passphrases myself (in the pre-Diceware era). I can't believe I was=20
that naive at that time, even today, and thankfully did not use=20
PGP/GnuPG for anything very important at that time.

Contrary to the usual saying, the passphrase requirement sacred cow=20
makes absolutely terrible hamburgers, and personally I flatly refuse to=20
trust a system that actively discourages or even prohibits users from=20
using passphrases.

- --=20
Shawn K. Quinn
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE9uYziQVXDBVmaIp0RAlqEAJ9ePBDiI/GCP9FAM0konTv4EAzQBgCcCCo1
6IJjPi1VdwKaAoL6pSuUd0U=3D
=3DUZ2y
-----END PGP SIGNATURE-----