Performance drops on 4.6.1

[jcrabanal]

Hello, this is related to https://github.com/sqlcipher/sqlcipher-android/issues/27, but I'm adding new info. It seems like simply opening the database is enough to trigger the JNI warning. Using the byte array password constructor or disabling WAL did not help.

JNI critical lock held for 451.804ms on Thread[43,tid=12140,Runnable,Thread*=0x7b64527350,peer=0x13a83b18,"LoadMappings"]

SQLiteDatabase.openDatabase(sPath,
    sPassword,
    null,
    nFlags,
    dbCorrupted -> errorHandler.onCorruption(new Database(dbCorrupted)),
    null);

[developernotes]

Hi @jcrabanal,

Unfortunately, the timing from the JNI log isn't quite enough to determine an overall issue. Both the hardware you run the operation on, and whether your are using the Community vs. Commercial edition of SQLCipher for Android will have an impact on the time required to derive an encryption key. Additionally, it would be beneficial to run this same test using the older android-database-sqlcipher library on the same hardware for comparison purposes. There are options to adjust key derivation to improve the performance, however, you should be aware that doing so may impact the overall level of security provided by the library.

[jcrabanal]

Hello, I've run my tests on a Pixel 7, a fairly decent device. I've tried android-database-sqlcipher and sqlcipher-android back and forth several times (changing a few things because of the API changes). The difference is pretty big.

It definitely seems related to opening/closing the databases. I am going to try providing raw keys, to see if it makes a difference.

[developernotes]

Hi @jcrabanal,

The difference is pretty big.

What was the actual difference? Was the test using the same database?

It definitely seems related to opening/closing the databases. I am going to try providing raw keys, to see if it makes a difference.

Please make sure you secure the raw key material if you choose to continue with this approach.

[jcrabanal]

Same database. I have run tests with databases created on 4.6.1 and 4.5.4 and tested each one on both versions. Version 4.6.1 was always slower, with naked eye noticeable hiccups.