
Ask HN: Why don't you use email encryption? - RK
For a number of years people have assumed that public key encryption would catch on as soon as it was easy to use and people understood the benefits of encrypting/signing messages.  One could argue that it's relatively easy to use email encryption nowadays, but very few people use it.<p>Besides the obvious answer that no one else uses email encryption, why don't you use it?  What would it take to get you to use it?  What do you think are the major adoption hurdles?
======
quoderat
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....)

------
smanek
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).

------
mixmax
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 :-)

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

------
mdasen
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.

~~~
wallflower
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.

------
tptacek
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.

------
briansmith
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 (brian@briansmith.org) if
you are serious about coming up with improvements to everyday email security
so that we can compare notes.

------
bayareaguy
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.

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

------
mjgoins
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.

~~~
Niten
> 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.

------
iuguy
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.

------
jdabney
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.

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

~~~
RK
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.

------
jodrellblank
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.

------
Zarathu
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.

------
mickt
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 ...

------
izak30
Because it's not default.

