Why did email encryption never catch on?

November 10, 2005 5:26 AM

Why did email encryption never catch on? Is it a matter of laziness or are there sinister conspiracies at work?
posted by skryche to Computers & Internet (27 answers total)

It wasn't bundled with Outlook Express.
posted by Leon at 5:35 AM on November 10, 2005 [1 favorite]

Partly a matter of laziness, but mostly because encryption was not required by the protocol spec. Since you didn't know if people on the other side could transparently read your encrypted email, by default you wouldn't send encrypted emails.

If you really want to do something about it, create an SMTP-like protocol with a strong default encryption system that is flexible and extendable, give it a really snazzy name, and hype the fuck out of it. Write it up in an RFC. Maybe setup some tie-ins with ISPs like AOL (they're trying to paint themselves as security-conscious this year) or systems retailers like Dell or try talking MS into supporting your protocol in Outlook Express. Or Thunderbird. Get Slashdot buzz. Whatever.
posted by Ryvar at 5:38 AM on November 10, 2005

Lots of reasons. Sure, laziness. Non-bundledness. Necessity of a universal standard, combined with egotistical corporations (just look at SPF/Sender ID/DomainKeys for a similar conflict). The perceived unnecessity of it.
posted by Plutor at 5:39 AM on November 10, 2005

It's not easy enough. I'm a pretty savvy computer user with a vague interest in this kind of thing. Heck, I've even been to a keysigning party. But I still haven't managed to muster up the motivation to figure it out and get it set up.

What do I use? PGP? Is that built into Mail.app? No? What's this other thing? I need a certificate for that? Where do I get one of those?
posted by chrismear at 5:39 AM on November 10, 2005

Extending from what chrismear wrote, it's not invisible to the user.

Address, type message, send; that should be all it takes. Nowadays, the text of a growing percentage of the email I receive is in the subject line. The body is empty, or contains the words, See Subject.

Users can't be bothered and businesses don't see a return on investment.
posted by mischief at 5:53 AM on November 10, 2005

BTW, a lot of business email platforms have it built in, and it is very easy. For instance, in Lotus Notes, it's just a matter of checking boxes that say "Sign" and "Encrypt".
posted by smackfu at 6:06 AM on November 10, 2005

I think that encryption not being part of the spec, or bundled with major e-mail programs and enabled by default, kept it from taking off initially. Now, that inertia, coupled with the fact that a lot of people check their e-mail through a web interface, keeps it from catching on now. That, and a lot of people send mail that doesn't really need to be encrypted; people who have a need to exchange communication in a secure manner will find a way.

(In college, I was part of a team working on a project to provide a PGP-enabled webmail system. I should keep working on that.)
posted by Godbert at 6:07 AM on November 10, 2005

It's not just laziness, though I agree that's a big part of it. For one, most people just don't care enough. Most people probably think, and rightly so, that people don't care enough to read their mail. Two, distributing keys and what not is actually non-trivial.

(In college, I was part of a team working on a project to provide a PGP-enabled webmail system. I should keep working on that.)

See HushMail.
posted by chunking express at 6:22 AM on November 10, 2005

I think it has everything to do with user experience. I know in Apple Mail it's pretty slick and clean, but it's still a pain to get a key and set it all up.

It needs to be super easy, built into applications, and completely invisible to users. It's never been all three of those things.
posted by mathowie at 6:25 AM on November 10, 2005

Well, for me one of the problems is that at various stages in my career, I'd be using between 3-12 different computers over the course of a week, most of which don't give me permission to instal pgp or gpg.
posted by KirkJobSluder at 6:33 AM on November 10, 2005

If you want a nice lead-you-by the hand way to get a free certificate for MacOS X's Mail application, go here.
posted by Wild_Eep at 6:35 AM on November 10, 2005

I tried setting up encrypted email between work (Outlook 2003 on WinXP) and home (Mail.app on OS X). It took a lot of work to get something that: a) worked at all on each mail program, b) was recognized by the other side and c) seemed worth the effort. I never used it. I had to get a new work laptop and I haven't bothered to reinstall. To be honest, a flash drive is easier to use and doesn't restrict attachment size so I use that to transport files back and forth.
posted by tommasz at 6:51 AM on November 10, 2005

chunking express : See HushMail.

That was part of the idea to do the project; what this project was designed to do differently was provide more security for the underlying keys (by not storing them on a central server where they could potentially be compromised).

I'm getting off-topic now. If, for whatever reason, anyone wants to know more, my e-mail is in my profile.
posted by Godbert at 6:56 AM on November 10, 2005

It's really the necessity for an awkward key swap that has stopped it. What is needed is something like the finger command applied to mail servers.

1) You compose an email and check the encrypt box.
2) your mail server fingers the recipients mail server for their public key
3) if the recipient doesn't have a public key specified the mail server generates a temporary key pair.
4) either way your mail server encrypts the mail message using the supplied public key.
5) when the recipient receives the email message she hits her decrypt button on the message. If they are paranoid the mail package prompts for a pass phrase and then uses that pass phrase to unlock the locally stored private key. The more trusting stores the private key on the mail server and asks the mail server to automatically decrypt all mail before handing it to the mail package. The same can be done for mail server generated key pairs.

Get MS to make something like the about the default in Exchange and it would take off. Unfortunately encrypting stuff imposes a significant load on the server.
posted by Mitheral at 7:36 AM on November 10, 2005

Widespread use of public key encryption would require an effective infrastructure for securely distributing and authenticating public keys. Otherwise, the only way to get someone's public key is for them to have given it to you, and that's rife with practical problems and security problems.

Although it's technologically feasible to create a public key infrastructure (and many companies have tried), no single infrastructure ever gained enough people's confidence to be useful to anyone.
posted by profwhat at 7:46 AM on November 10, 2005

Oh I forgot the mail server's themselves would need key pairs so that the recipent's mail server could sign the public key being provided to the senders server. That way the sender's mail server could verify it was supplied with the correct key. So you still need a trusted public clearing house for mail server keys. Your back at square one but at least it's now IT professionals dealing with key swapping rather than every clueless tom, Dick, and Mary.
posted by Mitheral at 7:54 AM on November 10, 2005

profwhat: I'm not sure you what you mean when you say there are security problems inherent in giving someone your public key yourself, versus them getting it from some repository. I thought what was meant by the term 'public key' was that you could give it to anyone without compromising your security.
posted by cactus at 8:05 AM on November 10, 2005

Papers have been written on this: Why Johnny Can't Encrypt.
posted by kcm at 9:12 AM on November 10, 2005

The reason it's important to protect the process of giving out public keys is this: Let's say alice wants to send a message to bob. So she wants his public key and goes to, say, a key server to get it. No problem right? Except Carol has inserted HER public key in place of bobs. Whoops -- now bob can't decrypt it, but Carol, CAN.

So, noone can harm you using your public key, but if they can substitute their public key for yours, then they can read any traffic intended for you.

If you can hand someone your public key yourself, or through a trusted forum, then it's fine. But the former is cumbersome and the latter comes with security problems of it's own.
posted by RustyBrooks at 9:23 AM on November 10, 2005

Phil Zimmerman, the inventor of PGP, talked to ITConversations about this . He cited many of the reasons above, and noted that even he almost never digitally signs email. Why? Not for lack of knowledge, that's for sure. It's because his lawyers insist on it.

There are a lot of corporations that could be using encryption and signature technology, but they choose not to because the benefits come with very big risk of having made it easier for someone to successfully prove the source of some employee's ill-thought email.
posted by nakedcodemonkey at 10:35 AM on November 10, 2005

I used to work for a company that sold a pretty slick PKI that basically made encryption invisible to end-users; however, it cost something like $10,000 and would really only cover people within your company (unless you could convince everyone else to also use a PKI and cross-sign your root certs). There's probably space for a really kickass open source solution to this -- maybe something that integrates flawlessly with Thunderbird (our product worked seamlessly with Outlook and was simple enough to use that everyone in our company, including the salesmen, receptionists, etc, used encrypted mail for inter-company communication).
posted by fishfucker at 10:37 AM on November 10, 2005

For encryption to take hold it needs to be like falling off a log. I was religious about encrypting or PGP signing my email for a while but I realized that:

a) Rarely any of my email warranted it
b) Most of the recipients wouldn't have a clue what a PGP signature block was
c) I could count on one hand the number of people I could actually exchange encrypted email with.

For a signature to be meaningful Joe Blow has to recognize it as a signature. Everybody knows what the ball point scribble at the bottom of a contract is. Next to nobody knows what the line noise that is a PGP signature is.

The same goes for encryption but no encryption passes the "can my 79 year old dad understand it?" test.
posted by substrate at 10:41 AM on November 10, 2005

Whenever encryption comes up, I usually have this thought: If you really truly need to worry about encrypting your email, the FBI already has a trojan or keylogger on your box.
posted by poweredbybeard at 12:07 PM on November 10, 2005

Whenever encryption comes up, I usually have this thought: If you really truly need to worry about encrypting your email, the FBI already has a trojan or keylogger on your box.

I guess. I found it handy to encrypt passwords, etc, to send to people without worrying about it.
posted by fishfucker at 12:53 PM on November 10, 2005

It's just too difficult and abstract for the average email user. Plus, no web-based email service (that I know of) supports it. From personal experience, S/MIME seems to work pretty well and it's built-in to most "modern" email clients... it's a shame so few use it.

Note to chrismear: if you interested in S/MIME I'd be happy to help, contact me through my profile.
posted by Mike C. at 8:38 PM on November 10, 2005

Whenever encryption comes up, I usually have this thought: If you really truly need to worry about encrypting your email, the FBI already has a trojan or keylogger on your box.

So I assume you send all of your mail on postcards, too?
posted by aaronh at 6:53 AM on November 11, 2005

A lot of people have already mentioned the problems of key exchange / key management / web of trust. It is true that this is a hard problem. But it is not true that this is the ONLY way to deal with the issue of email encryption.

The first thing to realize about email encryption is that there are two competing camps: PGP and S/MIME. They each approach the problem differently, and have different strengths and weaknesses.

PGP: This is the one that most people are familiar with. In order to encrypt a message to someone, you need only their public key. However, to be sure that the public key that you have is really theirs, you need to form a chain of trust between you and them. This is the purpose behind keysigning parties, where you actually meet in person, look at someone's drivers license, verify their identity, and then have them initial a printout of their key fingerprint so that you know it is theirs.

To form this web of trust takes a lot of work and most ordinary people are oblivious to it. You can certainly just send off emails to people and trust that their public key is what you think it is, but that's not a great security practice.

Another feature/problem of this method is message signing, which you are probably very familiar with. You've all seen a message that contains stuff like "-----BEGIN PGP SIGNED MESSAGE-----". This "ascii-armored" method of signing is common, but it makes messages look rather fugly, at least in my opinion. There is an alternative, which uses a mimetype of "multipart/signed" and attaches the signature rather that including it in the plaintext. However, certain microsoft crapware doesn't handle this correctly (even though it's been an internet RFC for like 8 years now) and so recipients using LookOut will see a blank message.

Most email programs support PGP with third party plugins.

The alternative to this is S/MIME, which has much better stock support in most email programs. It also does not suffer from the problem of having to use the fugly "ascii armored" crap for signed messages. And it uses the same trust model as HTTPS - there are certificate authorities whom everyone explicitly trusts, whose function is to verify identities and issue certificates. In this model you don't have to manually form you web of trust, but instead you just place all your trust in a firm like Verisign and hope that they never make a mistake. On the surface this is much easier, but it does have problems: getting a cert is not always easy and free. For personal use there are a couple of firms that will issue one for free (like komono) but in general you have to pay, just like you have to pay for a SSL certificate. This has hindered implementation, compared to the more free PGP methods.

So, here you have two competing standards, each with distinct advantages and disadvantages. Both can be made to approximate the "just click here to encrypt" model, but doing so does sacrifice some security (in that you can't always trust the recipient's key.)

When you combine this with the fact that most regular people just do not understand how things like encryption, message signing, and web-of-trust work, and the fact that most people still think, "Oh I don't have anything to hide, why should I bother with signing or encrypting" you get the result that it's hardly used.
posted by Rhomboid at 9:06 PM on November 11, 2005