Re: [Evolution-hackers] Cache encryption
- From: "Sankar P" <psankar novell com>
- To: <evolution-hackers gnome org>, "David Woodhouse" <dwmw2 infradead org>
- Subject: Re: [Evolution-hackers] Cache encryption
- Date: Fri, 04 Mar 2011 05:47:31 -0700
> 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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]