Automatic encryption of stored messages

[Dan White]

On 28/04/10 11:06 -0400, Mikhail T. wrote:
> 28.04.2010 04:27, Dan White написав(ла):
>> On 27/04/10 10:40 -0400, Mikhail T. 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?
>>
>> Interesting question! info-cyrus list is probably more appropriate for
>> this question.
> Having to subscribe to yet-another mailing list, just to be able to send  
> an occasional question or idea, is a turn-off... If this is off-topic on  
> this list, I'll just shut-up...

info-cyrus will have a lot more users of imapd subscribed to it than this
list, and should get you a lot more operational related responses.

>> The PAM requirement would force the use of saslauthd, and plaintext only
>> authentication mechanisms, which potentially degrades the over-the-wire
>> security between the client and server.
> Whichever way the user's password (or some function thereof) is  
> communicated to the server -- as long as the communicated string remains  
> constant... Use of PAM is just a possible implementation idea -- a way  
> to off-load some of the changes from the Cyrus' code into a separate  
> little tree (that of the pam-module). The only degradation I can see is  
> that the methods like OTP would no longer work... I don't think, this is  
> a big loss, if the entire traffic is SSL-protected. But that's up to the  
> admin...

PLAIN and LOGIN are the only mechanisms in which a shared secret is passed
to the server (and hence a potential security issue). In some other
mechanisms, the server knows the shared secret (digest-md5, cram-md5 and
srp?). EXTERNAL (x.509 certificate) and kerberos mechanisms don't know the
shared secret, although there potentially be room for encryption
(afs?).

>> Another opt-in approach would be for users to encrypt all private  
>> messages
>> within the MUA using PGP/GPG.
>>
> That approach exists now, but requires each user and /all of their  
> correspondents/ to set PGP for themselves. It also requires cooperation  
> from MUA, of course. My way is purely on the server and transparent to  
> the users.

-- 
Dan White