SQLCipher – Full Database Encryption for SQLite • Hacker News Board

Re: SQLCipher – Full Database Encryption for SQLite

#11

Post by StavrosK » Mon, Feb 09, 2015, 11:13 AM UTC

JulianMorrison wrote: post #9

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.

Re: SQLCipher – Full Database Encryption for SQLite

#12

Post by Xylakant » Mon, Feb 09, 2015, 12:03 PM UTC

JulianMorrison wrote: post #9

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, 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.

Re: SQLCipher – Full Database Encryption for SQLite

#13

Post by StavrosK » Mon, Feb 09, 2015, 12:24 PM UTC

Xylakant wrote: post #12

JulianMorrison wrote: post #9

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, 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.

Re: SQLCipher – Full Database Encryption for SQLite

#14

Post by mmozeiko » Mon, Feb 09, 2015, 12:28 PM UTC

toong wrote: post #8

>> "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.

Re: SQLCipher – Full Database Encryption for SQLite

#15

Post by jonbaer » Mon, Feb 09, 2015, 12:58 PM UTC

social_quotient wrote: post #2

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)

Re: SQLCipher – Full Database Encryption for SQLite

#16

Post by toong » Mon, Feb 09, 2015, 1:02 PM UTC

mmozeiko wrote: post #14

toong wrote: post #8

>> "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)

Re: SQLCipher – Full Database Encryption for SQLite

#17

Post by developernotes » Mon, Feb 09, 2015, 2:17 PM UTC

StavrosK wrote: post #13

Xylakant wrote: post #12

Earlier quoted context omitted.

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.

Re: SQLCipher – Full Database Encryption for SQLite

#18

Post by foolinaround » Mon, Feb 09, 2015, 2:17 PM UTC

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.

Re: SQLCipher – Full Database Encryption for SQLite

#19

Post by vinceyuan » Mon, Feb 09, 2015, 2:27 PM UTC

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.)

Re: SQLCipher – Full Database Encryption for SQLite

#20

Post by StavrosK » Mon, Feb 09, 2015, 2:36 PM UTC

developernotes wrote: post #17

StavrosK wrote: post #13

Earlier quoted context omitted.

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.