Automatic encryption of stored messages

[Reinaldo de Carvalho]

On Wed, Apr 28, 2010 at 2:03 PM, Mikhail T. <mi+thun at aldan.algebra.com> wrote:
>> Reinaldo de Carvalho wrote:
>>
>> Use a encrypted file system to protect data from steal. GPG is the
>> real solution because any server encryption suffers chicken and egg
>> problem.
>>
>
> Encrypted file systems have the disadvantage of having to be manually
> mounted. So, a server reboot will not restore the IMAP-service
> automatically.

Yes, the symetric key is in your mind.

> This is not a limitation of a particular implementation, but
> simply an inevitable part of the requirement -- any automatic procedure will
> leave the data just as open as with an unencrypted FS, because a stolen
> server will repeat the procedure upon boot in whosoever's hands it is
> booting. You could only hack something together by storing the procedure
> (or a key-component thereof) on a different system, but even then convincing
> (or coercing) the admin would give access to all e-mails at once...
>
> The other disadvantage of relying only on the encrypted FS for this purpose
> is that all messages are open, while the FS is mounted, so a successful
> hacker (or coercer) penetrating the server at runtime would have access to
> everything.
>

This is another problem, but server can't encrypt messages because it
should have access to a symetric or assymetric keys saved on the
server. Then you back to the problema, the hacker may access the key
and decrypt messages (this chicken and egg problem).

> The proposed method uses each user's own password to encrypt their mails --
> only the mailboxes of the currently-connected users would be exposed to a
> hacker (or coercer).
>

If the hacker owned the server he can
- use "tcpdump -s 0 -A | grep --line-buffered -e LOGIN -e USER -e
PASS" to get password in next user authentication.
- read TLS private key file and look traffic with tcpdump.
- read TLS private key from memory.
- switch imapd daemon to a version that save user/password on a file.


> PGP, while great, is not an all-covering solution, because it requires users
> -- and all their correspondents (!) -- to switch to PGP as well. That's not
> an option for many, if only because Yahoo!'s and Google's services don't
> support it. Neither do any of the online merchants, for another example of a
> substantial source of e-mails today.
>

Server should't encrypt data. Root can do anything.

> The proposed method would be entirely on the server, requiring no
> cooperation from the user nor their MUA.
>

Server should't encrypt data.

> I'm unaware of the "chicken and egg problem" inherent in server encryption.
> Perhaps, you can expand on it? If that's what I think you are referring to,
> my proposal deals with it -- newly arrived messages remain unencrypted until
> the next time the user logs in. However, they are no worse off, than while
> still traveling over the Internet, but the user's archives are now
> protected.
>
> I think, my proposed method should be viewed as complimenting the measures
> you mention. A particular setup can combine any subset of them.
>
> Yours,
>
> -mi
>



-- 
Reinaldo de Carvalho
http://korreio.sf.net
http://python-cyrus.sf.net

"Don't try to adapt the software to the way you work, but rather
yourself to the way the software works" (myself)