Qtox: Can't open history with sqlcipher 4.0

[TriKriSta]

after update sqlcipher v 4.0 (I use Arch Linux), I got the message "qtox couldn't open your chat logs, they will be disabled."

restored sqlcipher 3.4 fixed this problem.

[anthonybilinski]

I saw the same thing on Arch Linux Arm with an encrypted profile. Testing with a different unencrypted profile didn't give an error. The error I got from SQL was error 26 "Not a DB".

[sudden6]

Since it's a major version upgrade, maybe they dropped backward compatibility?

[TriKriSta]

here are updates that can break everything

Default page size for databases increased to 4096 bytes (up from 1024) *
Default PBKDF2 iterations increased to 256,000 (up from 64,000) *
Default KDF algorithm is now PBKDF2-HMAC-SHA512 (from PBKDF2-HMAC-SHA1) *
Default HMAC algorithm is now HMAC-SHA512 (from HMAC-SHA1) *
PRAGMA cipher is now disabled and no longer supported (after multi-year deprecation) *
PRAGMA rekey_cipher is now disabled and no longer supported *
PRAGMA rekey_kdf_iter is now disabled and no longer supported *

[physkets]

I have the same issue. Attaching the message I see.

[anthonybilinski]

https://www.zetetic.net/blog/2018/11/30/sqlcipher-400-release/
Basically SQLite 4.0 is compatible with 3.x, but the default parameters have changed like @TriKriSta said, causing us to fail decryption. I've tried both upgrading my db by calling PRAGMA cipher_migrate, and also keeping my db unchanged but getting sqlcipher 4.0 to use 3.x's defaults: PRAGMA cipher_page_size = 1024; PRAGMA kdf_iter = 64000; PRAGMA cipher_hmac_algorithm = HMAC_SHA1; PRAGMA cipher_kdf_algorithm = PBKDF2_HMAC_SHA1; and both work for me.

I don't see a way to check the db's SQLCipher version (not the running version) to detect if an upgrade is needed, and also am not sure if it's possible to open a db saved by 4.x with SQLCipher 3.x (I couldn't get it to work), so for now I've just manually specified the 3.x crypto defaults in my PR, which will be equivalent to before.

When we want to migrate SQLCipher to new crypto versions, possibly SQLCipher 4.x's default, in the future we can address it more thoroughly at that time.

[physkets]

Thanks for fixing it so soon!

But what if you did it this way:

1. Try opening database with default parameters
2. If it fails, attempt migration, then:
   
   
   
   • if db is v3 and sqlcipher is v4, it will be successful
   
   
   • else, set parameters to v3 and try opening db again
   
   

This should cover all cases, and make the migration smooth, shouldn't it?

[anthonybilinski]

That would work great on the computer with sqlcipher v4, but the one catch to that is if sqlcipher v3 can't open a db saved with sqlcipher v4 (not sure if that's true or not), that history will no longer be migrate-able between devices, which given the lack of multi-device support in Tox is something that I think a fair number of people do.

[physkets]

But another thing to consider is that if another Tox client creates a profile with a v4 encrypted database, then that db will not be usable via qTox.

[anthonybilinski]

There already isn't a standard history storage format between clients, so either v3 or v4 wouldn't be compatible with any other clients (though there is an option to export history into a text format from either). My concern here was just transferring from qTox on one computer to qTox on another computer, where temporarily staying at v3 gives us the best compatibility. Upgrading the DB is still something we should do, this change was just a low risk and non-persistent change to allow Arch users to access their history in the same way as before

[raingloom]

I'm still getting this error on Arch, is there a workaround to it?

[TriKriSta]

@raingloom maybe repository archlinux have old version qtox. try install qtox from github.

[raingloom]

indeed, it's a release from july, what kind of fricking rolling release is this....
edit: oh, it's because there has not been a release since then
welp...

[physkets]

@raingloom qTox hasn't had a release since then.

[raingloom]

(yes, that is what i said)

[anthonybilinski]

consider is that if another Tox client creates a profile with a v4 encrypted database, then that db will not be usable

I just reread this a few months later, and think this is still an issue. If any arch users with qTox v1.16.3 but sqlcipher 4.x created new profiles, they'll be using sqlcipher 4.x's default parameters in the save. With qTox v1.17.0, we manually specify sqlcipher 3.x parameters, so decryption will fail for them once they update.

I'll look in to opening db's saved with sqlcipher 4.x defaults using sqlcipher 3.x some more, and see if we can add that as a fallback in qTox.