
Automatically Encrypting all Incoming Email - Gygash
https://grepular.com/Automatically_Encrypting_all_Incoming_Email
======
johnny_maxwell
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.

~~~
sarba
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/](http://www.wired.com/threatlevel/2010/04/emailprivacy/)

------
jsilence
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?

~~~
knotty66
Maybe Fully Homomorphic Encryption will help here?
[http://en.wikipedia.org/wiki/Homomorphic_encryption](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 ?

~~~
AnIrishDuck
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](http://u.cs.biu.ac.il/~orlandi/icassp-draft.pdf)

2\.
[http://blogs.teamb.com/craigstuntz/2012/04/04/38707/](http://blogs.teamb.com/craigstuntz/2012/04/04/38707/)

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

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

~~~
rmk2
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"

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

------
frank_boyd
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?

~~~
mike-cardwell
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...

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

~~~
agwa
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).

~~~
nilved
What if you aren't? :)

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

[http://www.postfix.org/FILTER_README.html](http://www.postfix.org/FILTER_README.html)

I've got no experience with them though.

~~~
nilved
Indeed. Thanks a lot for the link.

