[Evolution-hackers] Cache encryption
I'm working on Enterprise use of Evolution, and one of the big requirements is encryption of data at rest. The answer just encrypt the whole of the user's home directory only puts them off for so long. So I'm looking at implementing this directly in camel-data-cache, e-cal-backend-cache, etc. I'll probably do the encryption with a randomly-generated key, which itself is stored locally, encrypted with a password. That way, changing the password doesn't involve re-encrypting the whole of the store; you only need to re-encrypt the master key. It also means that we can tie the password for the cache to the password for the server; entering one will allow access to both. Hopefully, the changes required to code that *uses* the cache functionality should be fairly limited. Mostly it should be handled by extra arguments to camel_data_cache_new(), e_cal_backend_cache_new(), camel_db_open() and similar functions. I'm hoping that it's reasonable to declare that *filenames* are not sensitive, and that we only need to encrypt the *contents* of files. Does that seem fair? Any other comments on the approach? -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Cache encryption
On Fri, 2011-03-04 at 11:40 +, David Woodhouse wrote: I'm working on Enterprise use of Evolution, and one of the big requirements is encryption of data at rest. The answer just encrypt the whole of the user's home directory only puts them off for so long. Can you go into more detail about why it's needed? Would help me to better understand the use cases. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Cache encryption
On Fri, 2011-03-04 at 12:25 +, David Woodhouse wrote: On Fri, 2011-03-04 at 07:17 -0500, Matthew Barnes wrote: Perhaps it's a different story for mobile devices? To a large extent, yes. The 'encrypt it all' solution means that you are forced to unlock the device to do *anything* with it, while from a user experience point of view we really do want to have a more fine-grained approach which allows you to easily use the device for personal things but just makes you unlock the *corporate* data before you access it. Got'cha. Seems reasonable. Thanks for humoring me. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Cache encryption
On Fri, 2011-03-04 at 07:30 -0500, Matthew Barnes wrote: Got'cha. Seems reasonable. Thanks for humoring me. No problem; thanks for paying attention to my ramblings. -- dwmw2 ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Cache encryption
I'm working on Enterprise use of Evolution, and one of the big requirements is encryption of data at rest. The answer just encrypt the whole of the user's home directory only puts them off for so long. So I'm looking at implementing this directly in camel-data-cache, e-cal-backend-cache, etc. I'll probably do the encryption with a randomly-generated key, which itself is stored locally, encrypted with a password. That way, changing the password doesn't involve re-encrypting the whole of the store; you only need to re-encrypt the master key. It also means that we can tie the password for the cache to the password for the server; entering one will allow access to both. Hopefully, the changes required to code that *uses* the cache functionality should be fairly limited. Mostly it should be handled by extra arguments to camel_data_cache_new(), e_cal_backend_cache_new(), camel_db_open() and similar functions. I'm hoping that it's reasonable to declare that *filenames* are not sensitive, and that we only need to encrypt the *contents* of files. Does that seem fair? Any other comments on the approach? Will it be not simpler if we can make Evolution use a custom location for cache, that the user/root can set ? That way, we don't have to write (and more importantly maintain) yet another encryption/decryption library and instead just use a different folder for storing all secret/confidential data, which can be a custom mount point which runs on encrypted partition. From a distro point of view, libraries with security packages usually have extra maintenance overhead (Are you sure your package is not shipped to america-banned countries ? etc.) So I believe it will be a better idea if the [en/de]cryption capable packages are less in number. Sankar http://psankar.blogspot.com ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Cache encryption
On Fri, 2011-03-04 at 07:49 -0500, Jeffrey Stedfast wrote: Easiest way to implement this feature in Camel might be to implement a CamelMimeFilter or CamelStream that encrypts/decrypts the content as it reads/writes the data. Implementing it as a CamelStream might be the best approach as it would more easily allow seeking. Yeah, absolutely. I had looked at the camel_cache_cache_get() function which returns a stream, and concluded that this made it nice and easy to just slip in a stream class which does the encryption/decryption for us. Thanks. -- dwmw2 ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Cache encryption
On Fri, 2011-03-04 at 05:47 -0700, Sankar P wrote: Will it be not simpler if we can make Evolution use a custom location for cache, that the user/root can set ? That way, we don't have to write (and more importantly maintain) yet another encryption/decryption library and instead just use a different folder for storing all secret/confidential data, which can be a custom mount point which runs on encrypted partition. I did look at that briefly. But I think it would have problems from both the implementation and the user experience point of view. With the encryption handled by e-d-s itself, it's all nice and self-contained. When it needs a password it can *ask* for it. If it wants to change the cache-encryption password to match the password for the online account, then it can handle that too. It's all integrated and works coherently. If you start trying to co-ordinate it with an external thing like an ecryptfs mount point, then there are a bunch of things you have to work with which are essentially outside your control. From a distro point of view, libraries with security packages usually have extra maintenance overhead (Are you sure your package is not shipped to america-banned countries ? etc.) So I believe it will be a better idea if the [en/de]cryption capable packages are less in number. I wasn't planning to do any of the actual crypto code directly in Evolution; I was planning to use NSS for that. The additional functionality would presumably live inside #ifdef CAMEL_HAVE_NSS, like a lot of other code in e-d-s already does. -- dwmw2 ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Cache encryption
On Fri, 2011-03-04 at 07:49 -0500, Jeffrey Stedfast wrote: Anyways, do you also plan on encrypting mbox/maildir files? Might make sense... Missed that bit; overtrimming my citations. I probably wouldn't do this *myself* in the first round, but I'd hope that someone might add it soon, and I might accidentally get drunk one night and do it anyway. These things happen... -- dwmw2 ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
