Automatically Encrypting all Incoming Email | Hacker News Reader

Automatically Encrypting all Incoming Email

grepular.com

48 pointsGygash19 comments

What's the point? This is equivalent to putting all postcards you receive in a safe so that no thief can read them if he breaks into your house.

I would think there is also other important data besides only mail on a PC, why not just go the safe route and encrypt your hard disk the proper way. File-by-file PGP encrypting stuff does not look like the best solution to me.

This makes most sense to do on hardware you don't own where the government can use a law from the 80s that says the government can read any email that's on hardware you don't own that's over 180 days old.

http://www.wired.com/threatlevel/2010/04/emailprivacy/

Its a much more secure approach than using full disk encrpytion, no need to have non-public-keys on an exposed system.

Your reaction makes me think you didn't even read as far as the second paragraph... Your question is answered there.

Also worth noting that the blog post doesn't tell you to do this instead of using full disk encryption. There's nothing stopping you from doing both, and you should.

Nice idea, but it breaks email search and thus is a no-go for me. I find myself seaching my mailbase quite often and if search does not work, i'd just as well delete them right after reading.

A possible solution could be to script my MUA using IMAP to decrypt incoming mail automatically and store them locally in a truecrypt container. No sure how well this would work.

Other solutions to the "search encrypted mails" problem?

Maybe Fully Homomorphic Encryption will help here? http://en.wikipedia.org/wiki/Homomorphic_encryption

Not sure how practical this is at the moment, or will be in the future. Hopefully an expert can weigh in ?

I don't consider myself an expert, but I see homomorphic encryption and secure multiparty communication trotted out as potential solutions to similar problems all the time. It (no offense) rarely seems like the speaker has more than superficial knowledge of HE and SMPC work.

I've looked into both in an extremely limited fashion, but am not an expert. And I've spent far more time looking into SMPC than HE. So take the rest of what I'm going to say with massive amounts of salt (I'd love to be corrected by an expert in any of my commentary).

Right now there are huge efficiency hurdles that must be overcome before these solutions are remotely tractable to general computation problems. All that HE and SMPC give you is an extremely expensive way to do addition and multiplication on fields. An intelligent observer may point out that's all you need to do computation. In GF(2), addition is the XOR operation and multiplication is the AND operation. Anyone that's taken a computational organization class knows these two gates are all you need to construct a general purpose computer.

The real show-stopper is the cost. SMPC requires communication between participants for all multiplication operations. This means every AND operation requires "mixing" to regain randomness and maintain secrecy. There are hundreds, if not thousands, of AND operations required for one cycle of even the most simplistic processor. That's not even touching the necessity for simulating RAM with GF(2) multiplication/addition, which would require AND operations for each multiplexing gate used.

A paper I found indicated that SMPC processor emulations are still struggling to run in the MHz range [1]. And that's without knowing what kind of communication is allowed between the participants (I'm guessing it's running on a local network).

Again, I know very little about HE. But I'm under the impression that there are still similar efficiency hurdles. I've also heard some troubling reports on patent grabs for FHE schemes [2].

1. http://u.cs.biu.ac.il/~orlandi/icassp-draft.pdf

2. http://blogs.teamb.com/craigstuntz/2012/04/04/38707/

A nice approach, I will look at implementing it on my setup at home; Probably worth noting that if you are taking these steps then running it all out of an encrypted filesystem is probably a sensible addition. Although if you are looking at doing this you probably have an encrypted filesystem already.

And likely have plain-jane, no TLS SMTP mail being delivered which means it's trivial for your upstream provider to read your (unencrypted) email.

Exactly. So why bother at all right? Root password? "root" will do. Encrypted partitions on the server? Useless. SSH keys? Silly overengineered junk.

Following the same logic, why bother setting strong passwords on Gmail? Or even bother at all with 2FA, I mean, after all, somebody can just read your unencrypted email in transit anyway, right?

This comment is not helpful at all. The original article did not mention with a single word the NSA or anything like it[1], but he is worried about things being stolen or hacked.

> So what does this get me? If somebody steals my laptop or phone, they can't access my email from my IMAP clients local store because it's all encrypted and my private PGP key is password protected. If somebody guesses my IMAP password, or uses an exploit to gain access to my account, they can't read my email because what they retrieve is encrypted.

And for both scenarios, the proposed tools are very much helpful.

[1]: Partially because the article says "Published @Thu, 13th Jan 2011"

>Exactly. So why bother at all right? Root password? "root" will do. Encrypted partitions on the server? Useless. SSH keys? Silly overengineered junk.

>Following the same logic, why bother setting strong passwords on Gmail? Or even bother at all with 2FA, I mean, after all, somebody can just read your unencrypted email in transit anyway, right?

That's not even remotely what I'm claiming. Stop being a dick. Yes, you should always have good passwords on your accounts and use 2FA. But if you want to send something secret across the Internet you might want to choose another method than (unencrypted) email.

>This comment is not helpful at all. The original article did not mention with a single word the NSA or anything like it, but he is worried about things being stolen or hacked.

If someone really wants to read your mail they'll compromise the host your mail is on and read it before you get a chance to encrypt it. In that case this "solution" does nothing. It keeps a casual person out but does nothing to stop a more advanced attacker.

Wouldn't it be way easier to just encrypt the partition? Ubuntu for example has an easy-to-use feature for that. The idea of email encryption is not least to avoid interception in the clear.

Or am I missing something?

The problem with filesystem-level encryption is that it allows the mail server to decrypt the messages. With PGP, the server is only able to encrypt messages; messages can be decrypted only by clients which have the private key.

You should do both. The solution described in the article provides several extra levels of defense against different types of attack that full disk encryption doesn't provide. If you actually read it, you'll know this...

How could this be translated to Postfix, for a Postfix novice?

If you're using procmail as your delivery agent, then adding this to your procmailrc should work:

  :0fw
  | /path/to/gpgit.pl you@example.com

Be sure to also enable opportunistic transport-layer encryption in Postfix (it's pointless to encrypt mail upon receipt if it just traveled in the clear on the Internet) by putting this in main.cf:

  smtp_tls_security_level = may
  smtpd_tls_security_level = may
  smtpd_tls_cert_file = /path/to/cert
  smtpd_tls_key_file = /path/to/key

You need a SSL cert for this, but it can be a self-signed cert. If you're on Debian (probably Ubuntu too) you can use the snakeoil cert (/etc/ssl/certs/ssl-cert-snakeoil.pem and /etc/ssl/private/ssl-cert-snakeoil.key).

What if you aren't? :)

Aren't using procmail? You could try using a Postfix content filter:

http://www.postfix.org/FILTER_README.html

I've got no experience with them though.

Indeed. Thanks a lot for the link.

Reply on news.ycombinator.com