[nzlug] encrypted IMAP storage?

[Guy K. Kloss]

Thanks so far for the made suggestions. Unfortunately it's not really what I 
was looking for. But what did I expect, web searches didn't reveal anything 
so far either ...

On Mon, 10 Dec 2007 2:20:50 pm Steve Holdoway wrote:
> ISFR an user-space mounter for gmail, built on top of fuse??? Yup, google
> suggests that gmailfs is available...
> http://richard.jones.name/google-hacks/gmail-filesystem/gmail-filesystem-in
>stalling.html may help. Follow that up with a quick dose of
> http://gentoo-wiki.com/HOWTO_GmailFS to encrypt on the fly and you should
> be good.

Have been thinking about GoogleFS together with encryption before, too. The 
solution I was *hoping* to find somehow would have been some configuration 
that would wrap all IMAP4 entries and store them transparently encrypted for 
me on the IMAP4 server. Of course then the client would know how to decrypt 
the content, and the client would need to be able to handle the content ...

On Mon, 10 Dec 2007 5:53:34 pm Andrew Simpson wrote:
> I'm using S3 as a backup with Duplicity.  Duplicity supports PGP encryption
> out of-the-box.  My only issue was the complete lack of documentation with
> Duplicity and S3. The other issue is the incredibly slow upload speed of NZ
> broadband...

Same as with above solution. Speed and simplicity through a direct IMAP 
integration without the need of a remote file system backend would have made 
the charm of an encrypted IMAP storage backend. I just want Google, Yahoo, my 
university, my future employer, ... NOT to have total access to my content.

On Mon, 10 Dec 2007 1:51:30 pm Jim Cheetham wrote:
> The email provider will always have to have the ability to decrypt
> your messages when interacting with your IMAP client, in which case
> the presence of an encrypted filesystem becomes irrelevant. The only
> way around this would be to try and make sure that all messages going
> into Gmail were encrypted first, e.g. by PGP.

Something along those lines was what I hoped for: OpenPGP or whatever 
open/good encryption of the content before it gets dumped into the IMAP 
server's hand. But ideally also encrypting mail header information (e. g. 
recipients, senders, date, ...), not just the content body.

> You couldn't enforce this at the Gmail end, because inherently all the
> non-encrypted messages would have been received by them first and are
> therefore compromised (and form a great corpus for a plaintext
> attack); therefore you have to enforce this policy at the sending end.

Absolutely true. That's why I'm not sending/receiving mails through Gmail. But 
I've got a Gmail account, and it's just sitting there with no content, even 
though I believe 2.8 gigs or something like that would be possible. So my 
idea was to just shove my content onto the Gmail IMAP server. I use IMAP  
heavily for mails, contact information/address book, calendar, etc. And I 
love it for its simplicity with regards of multiple points of access with its 
synchronisation characteristics between various computers.

So in the end it would be just a storage backend, not for receiving/sending 
it. Therefore that big company could not harvest all my traffic for "their" 
purposes, or the purposes of a government in the company's home country.

Guy

-- 
Guy K. Kloss
Institute of Information and Mathematical Sciences
Te Kura Putaiao o Mohiohio me Pangarau
Room 2.63, Quad Block A Building
Massey University, Auckland, Albany
Private Bag 102 904, North Shore Mail Centre
voice: +64 9 414-0800 ext. 9585   fax: +64 9 441-8181
eMail: G.Kloss at massey.ac.nz  http://www.massey.ac.nz/~gkloss/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://www.linux.net.nz/pipermail/nzlug/attachments/20071210/98b33438/attachment.pgp