[Ssc-dev] Fwd: Re: Moving Funf to SQLCipher

[Nathan of Guardian]

Will fwd my reply as well. Interesting perception about performance
issues of SQLCipher.

-------- Original Message --------
Subject: 	Re: Moving Funf to SQLCipher
Date: 	Thu, 26 Apr 2012 11:00:40 -0700
From: 	Nadav <nadava at gmail.com>
Reply-To: 	funf-developer at googlegroups.com
To: 	funf-developer at googlegroups.com



Hi Nathan! 

We actually really like SQLCypher and considered doing this about a year
ago, but at least at the time SQLCypher was encrypting the entire
database every time, and not doing per-field encryption (and field
names) - so we could not efficiently use it with the amount of
read/writes that we did. I haven't checked the updates recently - Does
it support this type of functionality? (if so that's really great, if
not - consider it a feature request :).
Funf does encrypt the full databases when we are done writing to one
with a user specified key, but that's mostly for when we back them up on
the phone or transport them to the back-end. SQLCypher could be very
useful for apps that actually use this data while its on the phone so
we'd would love to be able to add it as a type of local storage maybe
(and if it had the per-field capabilities it might be able to be the
default mode of storage).

Nadav



On Thu, Apr 26, 2012 at 10:43 AM, Nathan of Guardian
<nathan at guardianproject.info <mailto:nathan at guardianproject.info>> wrote:

    Hey guys! Great progress, and really neat hack on the Dropbox APK
    Builder thing.

    You shoulder really consider using our SQLCipher for Android library
    instead of plain ol' SQLite in order to safeguard all the sensor
    data you are gathering. It is ridiculously easy to implement, as the
    API is 99% compatible with android.database.*.

    https://guardianproject.info/code/sqlcipher/

    SQLCipher is not just for Android, either... there are libraries and
    source for a wide variety of devices and OSes: http://sqlcipher.net/

    Cheers from the Guardian Project team!


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mayfirst.org/pipermail/ssc-dev/attachments/20120426/03e051f5/attachment.htm>