Automatic encryption of stored messages

[Mikhail T.]

Reinaldo de Carvalho wrote:
>> >  Is there a way to encrypt all of the Cyrus' user-specific files on the disk?
>> >  So that somebody breaking in -- or stealing the server -- has no access to
>> >  the messages (and other data) unless a user's password is also available?
> 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 
<http://www.freebsd.org/doc/en/books/handbook/disks-encrypting.html> 
have the disadvantage of having to be /manually/ mounted. So, a server 
reboot will not restore the IMAP-service automatically. 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/.

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).

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.

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

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.andrew.cmu.edu/pipermail/cyrus-sasl/attachments/20100428/1a00315c/attachment.html