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
