Reasons I don't use it:

1) I'm not terribly concerned with anyone reading what I send, because I've never personally observed any negative consequences from that happening, so that concern is external to me, even if real.

2) It's another complexity added to my life that I don't need.

3) Since others don't use it, I don't have the time or the inclination to explain to them why they should bother to deal with my encrypted messages.

4) If the government, etc., wants to get something out of me, they will.

5) Too many different ways to do it, none of them universal (chick and egg problem, yep, but....)

I think the key problem (no pun intended) is that email encryption can't be securely implemented on the server side.

Simply put, most of the people who are paranoid enough to need email encryption don't trust Google (GMail) with their PGP private keys. Therefore, they either have to use an offline email client (unacceptable to a lot of people) or install a brittle and poorly integrated third-party solution like FireGPG (which the vast majority of users will never do).

I actually tried a few years ago since I routinely sent patent applications, business plans and other sensitive information in e-mails. Unfortunately I couldn't get anyone to install encryption software at the other end (PGP) so I had to give up. Not even our patent attorney seemed to think that it was worthwhile to encrypt his mail.

I could probably have gotten a lot of really good patents by sniffing his mail and sending in applications before his customers got around to it :-)

Why didn't you try S/MIME? It is built into all email software worth using.

Why don't we use HTTPS for everything we send over the internet? Why don't we have locks on on all our mailboxes? In fact, the post is just terribly insecure. Heck, plenty of people who live in more rural areas don't even lock the doors to their house.

There are lots of reasons, but when you get down to it, we just don't care that much about security.

Without load balancer assisted hardware SSL acceleration (e.g. the load balancer transparently hosts the site's SSL certificate and performs the encryption/decryption), SSL processing can cripple a server under load.

We do, for obvious reasons, but I get why people don't. Email isn't going to be encrypted until email encryption is automatic and transparent.

There's also two conflicting standards now; S/MIME and PGP. We have to use both, since roughly half our customers are married to each.

Most users will only use encrypted/signed email if encryption and signing is done automatically. If the automatic encryption/decryption/signing/verification is done by the server (e.g. GMail), security gurus will complain that it isn't secure enough.

If the encryption/decryption is done in the "totally secure" way on the client, users complain that they are locked out of their email too often (can't access it from a secondary ___location and/or lost their keys).

Average users don't have an effective method for exchanging keys.

Email security doesn't really work without a signing mechanism that results in nonrepudiation. But, a lot of users don't want nonrepudiation for the messages they send; they want nonrepudiation for the messages they receive and 100% repudiation for the messages they send. To implement that, you need some kind of expiring signing keys, separate from the encryption keys, which S/MIME and GPG UAs don't natively support.

Consumer-level email services are mostly webmail at this point. There is no good solution for securing webmail beyond TLS encryption between SMTP endpoints (e.g. between Google, Hotmail, and Yahoo, and between the browser and the server). However, your email is still just a subpoena away at every endpoint.

Server-side spam filtering doesn't work with encryption. As soon as spammers start using your encryption key, the spam will pass right through the filters. That means you need to keep your encryption key private. But, that makes key exchange and revocation checks even more difficult.

Online certificate revocation checks are important for email security. However, the process of doing the revocation check leaks sensitive information (who you are corresponding with) if it is optimized for performance. The current means of revocation checking that is optimized for privacy has unworkable performance issues. A new, nonstandard, mechanism for doing revocation checks is needed. But, everybody hates anything proprietery, so it would have to be standardized, but the standardization process will take years.

Everything related to internet email has been free/open source/public ___domain since the beginning. Any solution that someone comes up with will have to be opened up and freely given away--including the specifications and reference implementations--before it has any chance of being adopted. This limits revenues. Yet, you need a costly infrastructure to implement the service levels that users expect from email (99.9% uptime and high performance and pennies a day or free).

I have been working on a solution to most of these problems but I don't have the resources to move it forward. Please email me ([email protected]) if you are serious about coming up with improvements to everyday email security so that we can compare notes.

Although I get a lot of email, I don't really send much and most of what I send is that I can't meet $person when they want because of $reason and that I would rather meet at $date. That sort of thing isn't really sensitive.

That said, I occasionally exchange details that could be covered by an NDA and for those cases I'll just send an OpenSSL encrypted attachment. Most people I work with don't have a problem with that and the few that do are easily helped by simply reminding them of the syntax:

  % openssl enc -d -aes-256-cbc -in document.pdf.aes256 -out document.pdf

The biggest problem I have is that people rarely think about the sensitivity of things they send to me unless I explicitly remind them to.

I'd be happy to use it if the only user interaction was flipping a preference switch.

Because when you search through your email, it has to be already decrypted, so why bother?

On the other hand, I cryptographically sign all of my email, so those who use the web of trust have a reasonable assurance it came from me.

> Because when you search through your email, it has to be already decrypted, so why bother?

Of course, there's a huge difference between "decrypted on my hard drive" and "decrypted as it passes through N untrusted mail servers".

Heck, it doesn't even have to be decrypted on your hard drive in order to be searchable; just use dm-crypt, or TrueCrypt, or PGP, or any of the myriad other full-disk encryption options.

My business does. Anything commercially confidential is encrypted in transit and at rest on anything portable (file encryption isn't currently set up on the servers but will be in the next refresh).

FWIW the way to use it successfully is to use it to get people to think about the sensitivity of the data (as in 'should I send this unencrypted?') as opposed to using it for everything. People that gripe and moan about it at work tend not to need it and are generally less exposed to it. Those that need it understand why.

Another question along the same lines is the question of email signing. As a sysadmin I receive large amounts of email asking me to change something on various systems and almost none of them are signed. How am I to know that the real person wants some configuration change or not? I see it as a big security problem. Doesn't mater how much I complain, no-one changes their ways.

How are you to know I didn't sit at someone elses PC and send an email automatically signed as them?

That usually requires your signing password, which, done securely, shouldn't stay in memory for more than a few minutes. Of course a lot of people probably just check the "remember indefinitely" box.

Encryption is all mixed up with PKI and certificates and that whole bundle of (overly)complex stuff that I really don't want to have to bother with any more than I have to.

I think I have GPG running somewhere, but know only one person who used it. I like that they pushed me to use it, but haven't needed to email them since.

Whatever it was would have to work on all the ways I read my main email (iPhone, Browser, Outlook), and not involve typing a decryption password for every email or even every time I check for mail.

I just use SSL to access the IMAP and SMTP servers. Anything more than that, I couldn't particularly care less. It's not like I send credit card information over email.

Email was designed to be a relatively simple way to send basic messages. In itself, it's an insecure platform. If you want security, use something else.

Very few friends use encryption, so full e-mail encryption is out. For a while I tried just signing my e-mails with a PGP cert, but I gave up when friends & colleagues kept asking why they couldn't open the attachment or what that attachment is ...

Because it's not default.