SQLCipher Future Features


#1

What would you like to see in future SQLCipher releases?


#2

I’m not sure if this is a “feature” or just a blog post, but a recipe for using SQLCipher for Android with the Android KeyStore provider would be handy. I’m assuming the answer is to use the KeyStore to sign an app-generated passphrase for use with SQLCipher, but if there are other/better solutions, that’d be cool to know.


#3

Hi Mark,

That would be interesting to see, we don’t use the KeyStore within our
own product but there may be folks out there interested in seeing how
the two would integrate. Is that something you use often?


#4

No, in part because apparently there are bugs that means that it is only a practical solution on Android 5.0+. IIRC, on earlier versions, if you changed your lockscreen type (e.g., PIN->password), it would wipe out the secure element, and you’d lose your keys.

However, it would be useful to have a hardware-backed key for SQLCipher, at least as an option. For users who steadfastly refuse to provide their own passphrase, a hardware-backed key means having a generated passphrase isn’t completely ridiculous.


#5

Hi Mark,

With regard to hardware backed key support, we did some work on this
over the summer, as part of one of our presentations at PasswordsCon.
The vfs branch [1] of SQLCipher includes support for persisting
SQLCipher configuration data directly within the SQLCipher database
header. We have built on top of this to have sample integrations with
both Yubikey and DaPlug. Note this feature is not complete, however it
is functional.

We have other features included within that branch such as computing a
KDF iteration length constrained by time. These are topics we would
like to delve into further with the SQLCipher community in the near future.

[1] https://github.com/sqlcipher/sqlcipher/tree/vfs