Quoting Miquel van Smoorenburg miquels@cistron.nl:
On 28/10/13 23:22, Frerich Raabe wrote:
On 2013-10-28 20:23, Reindl Harald wrote:
Am 28.10.2013 20:14, schrieb Douglas Mortensen:
However, it would be nice to know that even if we were breached, the emails on the server were encrypted and would be completely useless to an attacker. This type of encryption is ideal and some regulations prefer (although don't require) it
impossible and useless if someone comes that far he can also read whatever configuration containing the keys
In principle, this can be addressed by employing asymmetric key encryption.
You could imagine a system which requires users to generate a key pair and then submit their public key. The mail system will encrypt all mail received for a user with that users public key. When accessing the mail, the user configures his user agent to use the private key to decrypt the mail.
In practice, it's probably not that easy:
I suppose you'd have to be careful to not break features like server-side searching though. If you only store encrypted mail, the only moment where the system sees the plain mail is when it's received. So you'd probably need to index it at that point and then use that index for subsequent queries. Once the mail is written to disk, the server never sees the real data anymore.
Different mail storage formats probably work differently well. mbox is right out, with Maildir it might not be acceptable to encode the raw mail file - I don't know whether Dovecot uses any actual contents of files with Maildir (as opposed to the Dovecot-specific indices and the file name). If it does, then you should maybe just encrypt just the body but no headers or similiar.
There's surely more to consider, but I think this is anything but "impossible and useless". Accessing sensitive data which is stored on an untrusted system is an old and solved problem, I wouldn't be surprised if you just have to consider implementation details in the case of a mail server.
Well you can generate the public and private key on the server, then set the users password as the keyphrase, and leave it stored on the server.
Incoming mail would be automatically encrypted with the public key, then stored.
When the user logs in to imap/pop the password is not only used for authentication, but also to unlock the private key. Dovecot can then decrypt the messages on the fly.
Basically this is how Lavamail worked. It is reasonably secure, but doesn't help against a hostile root user on the server that hacks dovecot to just log the password when a user logs in. Or someone who has acquired your SSL keys and taps your internet connection. Mike.
Or someone that has your email password. Basically, it's no different than unencrypted mail on an encrypted filesystem. Doing more work != more secure - that's why Lavamail was nothing more than a marketing ploy. Imagine going to your bank to put things in your lockbox, and giving your personal items to the teller who then runs an obstacle course before getting to the vault. Are your things more secure than you putting the items in the lockbox you have the key for?
Use GPG, and make sure the user understands that full text search is not available. For the client, either they run it locally, use the gpg Chrome plug-in, or the site implements opengpg.js. Then all decryption occurs client-side. http://openpgpjs.org/
You could come up with some custom public/private key exchange, but why? If you're going to encrypt and decrypt it locally anyways, what does it matter? The equivalent to the Lavabit hack, without the pointless runaround, would be to use the Dovecot zip module to encrypt the data so only the Dovecot process can read it - though you could still trivially log the user's password for direct data access. IMHO, logging a password you receive in plain text is far from a hack. To me a hack requires a little complexity or inginuity.
Rick