[Dovecot] Encryption solution for messages at rest

[Rick Romero]

  Quoting Miquel van Smoorenburg <miquels at 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:
>>
>> 1. 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.
>>
>> 2. 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