SQLCipher – Full Database Encryption for SQLite | Hacker News Reader

SQLCipher – Full Database Encryption for SQLite

zetetic.net

55 pointsjonbaer22 comments

The SQLite Encryption Extension is another encryption library for SQLite (under a commercial license): http://www.hwaci.com/sw/sqlite/see.html

It's created by the authors of SQLite, so purchasing it helps support the public domain SQLite project.

Does it authenticate encrypted data?

CCM mode is an option, and is an authenticated mode. Not a great choice per se, but nothing outright wrong with it either. CCFB and GCM would be preferred alternatives.

Thank you, I somehow missed that they list CCM as one of the modes.

Tools such as keepass should move to use this layer instead of a custom format, and they should really be provided a UI around the data.

They can still continue to protect against in-memory access, etc.

I am using it in my iOS app and android app. It's great! It protects my data. But I had a problem before. The new version SQLCipher failed to read the existing encrypted database. Though it was not a big problem to me, it may be a big problem to some people. (Because my database is readonly. I can provide a new db in the new version of my iOS app.)

Used it plenty of times in the past and always been pleased with it's ease of use both in server side situations as well as mobile. More recently we've also used it in xamarin.

Is it posted here because something new has happened?

Came from watching https://www.youtube.com/watch?v=KEJGqNf2rgk (excellent talk)

From Wikipedia, use of PBKDF2 leaves this vulnerable to GPU based fast dictionary attacks (versus eg: scrypt that is a deliberate RAM hog).

While this is true, for these sorts of deployments you would use a high-entropy random key, not just a password. I guess it's different if you want to deploy this on a mobile phone or something, though.

Other than that, this strikes me as a very nice way to get seamless, strong encryption for mobile or desktop apps (where data at rest needs to be protected) without writing a single line of crypto code.

While this is true, you can tune the work factor of PBKDF2 accordingly. On the positive side, it's easier to argue for PBKDF2 in face of regulations since it's a standard while scrypt is not.

The problem with tuning it is that if you use it on a mobile, for example, tuning it enough to thwart a GPU would mean that one authentication would take 10sec on the mobile.

We have done some work on a branch in SQLCipher that allows for adaptive key derivation length based on the device it runs on. The iteration length will be computed per device where time is the constraint. We presented our initial findings last year at PasswordsCon 14.

Isn't that the standard? We always time the iterations for a specific time delay on the specific device and use that, and that's what, for example, LastPass (IIRC) does.

That still does nothing for the fact that a GPU will be thousands of times faster than a mobile.

>Isn't that the standard?

SQLCipher uses PBKDF2 as a standard mechanism to compute a key, however by default it uses a static iteration length, currently 64,000.

The problem is often that the device spread varies greatly and often a given application will target more than one device. You can watch our presentation covering the details here:

https://www.youtube.com/watch?v=b8TNHZ7fWzg&list=PLdIqs92nsI...

Oh yeah, something to read over and search for implementation flaws on the bus ride in to work. Monday is better now :)

>> "Features: Algorithms provided by the peer reviewed OpenSSL crypto library"

Did they add that on their landing page before or after Heartbleed ? (Wayback Machine only has a snapshot as early as Oct 2014)

It doesn't use SSL/TLS stack from OpenSSL, so Heartbleed doesn't apply to SQLCipher.

I'm not taking a stab at OpenSSL or SQLCipher. Very good for them not trying to roll their own and use OpenSSL.

I was just intrigued by the wording "peer reviewed OpenSSL crypto" and referred to Heartbleed because the amount of eyeballs the OpenSSL project gets, has increased since April last year ? (no, I don't have a source on that)

wxSQLite3 also has encryption available in it. You can use it without having to use the wxWidgets wrappers.

I much prefer Realm over SQLite. The interface is just so much nicer (just objects, no more SQL, yeah!) and encryption is build in from the get go.

Main benefit with SQLite is wide compatibility. If you want to use objects there are plenty of ORM solutions available which work with SQLite while not breaking generic file & SQL compatibility.

Reply on news.ycombinator.com