developernotes

I received one other comment about this while we still had the survey open. I will keep that in mind for the future.

This is good feedback, I will certainly consider that for the future.

>However, I don't know how this survey was advertised, so the results may just be sampling bias.

I created this survey. I originally posted it to the CL subreddit and the CL IRC channel, so somewhat limited communication channels. Maybe there are other, better places to post it?

In the early years of Android Studio, I generally preferred IntelliJ. I have since converted our application and main library (SQLCipher for Android) to use Gradle. I have Instant Run disabled, but otherwise I haven't run into many issues with Android Studio. We still coordinate our library build with a Makefile.

This paper highlights various possible attack vectors. SQLCipher would still be vulnerable to scenarios such as an active attacker on device/machine where the key is resident in RAM. If you are interested in the design features of SQLCipher, I would recommend reading this: https://www.zetetic.net/sqlcipher/design/

>I'd like to see the same speed measurements done for mobile.

While not exactly what you are looking for I can understand the sentiment. SQLCipher provides a project to time the performance of queries when run against standard SQLite vs. SQLCipher on iOS.

https://github.com/sqlcipher/SQLCipherSpeed

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

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.