[tor-talk] Transparent e-mail encryption?

[Matej Kovacic <matej.kovacic@xxxxxxxxx>]

Hi,

I know this is a bit off-topic, but since here are people who know a lot
about security and since I was unable to find relevant answers I would
like to ask one question.

PGP Corpotation has one interesting solution, called PGP Desktop Email.
Description:

PGP Desktop Email is email encryption software that automatically
encrypts email as it is received and sent on desktops and/or laptops,
without affecting the end-user email experience. PGP Desktop Email
operates as a proxy, supports the two global email encryption standards,
OpenPGP and S/MIME and automatically discovers keys and certificates as
required.

So, my question is, is there something similar in opensource land?

What solution I am looking for?

On a server side there should be a simple script, which would
automatically encrypt all incoming e-mail with recipient public key. All
e-mail is then stored on a mail server in encrypted form.

O a client side there would be nedded an application (daemon), which
would transparent and automatic decrypt all incoming e-mail. Mail client
would connect to this daemon, and this daemon would connect to mail
server (through PO3 or IMAP), get messages, decrypt them and pass them
to mail client. If daemon receives e-mail in plain text, it should pass
warning to user. The same with GPG errors.

What we get from this setup?

First of all, mail messages are stored in encrypted form on a mail
server. It is true, that attacker could break into the server and switch
the GPG encryption off, but he cannot view already encrypted messages
(we get past security). The other option is, that e-mail server already
uses full disk encryption (TrueCrypt or LUKS), but the main password get
abused (or server hacked). In that case users still have security of
their personal mail guaranteed, at least past messages. (Analogy to LUKS
full disk encryption and EncFS encryption of user's /home folder in
Ubuntu: all users of a machine must have LUKS password to boot the
machine, but when they do that, they would still need user's password to
access his or her /home folder).

On a client side, client can use insecure protocols, but user's mail
would still be protected during transfer. Even if attacker get user's
password, he would be unable to read his emial without his private key.
This is also important when using mail client through Tor.

Another thing is that mail client will always get unencrypted mail,
which can be indexed. If decryption would be done in mail client,
indexing would not be possible. However, it is important to note, that
local storage of mail client should be enrypted (LUKS or EncFS) or
located in a trusted environment.

There is also not problematic if we receive already GPG encrypted
e-mail. Mail message would be double encrypted on a mail server, but
mail client will receive only one-time encrypted mail message and there
will be no usability problems (no need for user to run decryption second
time). There will also be no problems with GPG keys. Mail client looks
for a public key of a sender, and since mail mesage would be decrypted
by daemon, there would be no need to manually select correct key. There
will also not be a problem with replying - usually if user receive
encrypted mail, reply is also encrypted. Here behaviour of a replying
would be "normal" (however messages stored in reply folder on a server
would also be encrypted by the server), and there will be no problems
with selection of recipient's public key. This solution can also encrypt
complete message - including mail header.

The only "bad thing" is that user would need additional software
installed on his machine (this daemon), that mail admin should install
the encryption script/software and that here will be a little more
problematic to read e-mail through web interface (however, this could be
solved, but searching through web IMAP won't be possible). And of
course, this apllication should be available for different, also mobile,
operating systems.

So - is there some similar solution and if not - is there someone who
would like to help developing such a solution?

Regards,

Matej
_______________________________________________
tor-talk mailing list
tor-talk@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk