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.
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.
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?
Not sure how practical this is at the moment, or will be in the future. Hopefully an expert can weigh in ?
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].
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"
Or am I missing something?
: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).