[Android] Downgrade from version 4.2.0 to 3.5.9

Hi there,

We are currently using SQLCipher version 4.2.0.
Due to some issues, we would like to downgrade the library version to 3.5.9 in our app.

Is it possible to do so? If yes, then could you give me a brief guidelines on how to do that?

I tried simply by changing the version and it just throws an exception here.


Hello @Tuan_Nguyen_Huy - It would be difficult to downgrade because the default security settings for SQLCipher 4 are not available in SQLCipher 3.x (i.e. PBKDF2-HMAC-512 and HMAC-512). Perhaps it would be better if you explained the issues you are facing with 4.2.0, as there may be ways to fix the issues that don’t involve downgrading the library?

Hi @sjlombardo,

We’ve been using SQLCipher for some time, and upgraded to 4.2.0 version recently.
However, there is an exception which happens quite randomly even with new version, which has been reported here and there by other people as well:

net.sqlcipher.database.SQLiteException: file is not a database: , while compiling: select count(*) from sqlite_master;

I’ve been investigated this and aware that it might come because of many reasons (wrong DB password, non-terminating zero byte, etc.). Unfortunately we have not been able to identify the root cause of this yet, and still this exception is causing unwanted behavior to our app.

Hence, we are thinking about using [WCDB](https://github.com/Tencent/wcdb) , which is just a wrapper of SQLCipher, but having its own error handling mechanism.

Since the WCDB lib only supports SQLCipher version 3.x backwards, we’d like to downgrade the SQLCipher verison in our app because we are using 4.2.0.

I understand that this might be out of your support zone, so just asked in case it’s possible to do the downgrade, but it’s bad to hear we can’t do it.

Thank you.

Hello @Tuan_Nguyen_Huy - thanks for clarifying. The file is not a database error is always related to the key material not matching the database content, either due to bad key material, corruption, etc. As you noted there are several reason that might occur. As a result, I’m not sure what the benefit of having wcdb’s error handling mechanism will add, since if an underlying error occurs it would still cause the same issue, though it might be caught by wcdb.

Hi @sjlombardo,
Yes, WCDB offers several benefits beside using SQLCipher data encryption, such as:

  • Concurrent access via connection pooling from modern Android framework.
  • Repair toolkit for database corruption recovery.
  • Database backup and recovery utility optimized for small backup size.
    and so on.

Hence at least it will give us an option to remove the corrupted DB and re-create to prevent unwanted crash/error without us having to write custom code for it, even though data will still be lost, while we’ll be still working on finding out the root cause of corrupted DB.

So we just do not have any way for downgrading, right?

Hello @Tuan_Nguyen_Huy - thanks for the additional details. That is correct, downgrading would not be easy, unless you want to start from scratch with new databases.

It likely be far easier to update WCDB to support SQLCipher 4 instead. This would provide all the additional security improvements.

Hi @sjlombardo, yes that would be perfect of course.
Unfortunately, SQLCipher 4 won’t seem to be supported by WCDB, according to this discussion
on their Github page:

That was why I came up with the option of downgrading, because they support SQLCipher 3 backwards.