Open SQLCipher with raw key does not work

[rlatapy-luna]

I cannot manage to open my sqlite database encrypted by sqlcipher with a raw key.
The database is dumped from Android (mode WAL) and use a 32 bytes key, transformed to a 64 chars strings. I suppose the transformation is ok because I'm able to export the database by using sqlcipher_export in both way (encrypt/decrypt). Of course I'm also able to (re)open it on my app by using the raw byte[] key.
For the export I followed the example from https://github.com/sqlcipher/sqlcipher-android-tests/blob/master/app/src/main/java/net/zetetic/tests/ImportUnencryptedDatabaseTest.java, and as said everything looks ok.

When I then try to open the dumped database on db browser, it asks for the key, but it does not open when providing my "0x" + 64 hexa chars key (lower case or upper case). Am I missing something?
It works great if I use a passphrase instead of the raw key in sqlcipher_export, so the encryption params are ok.
I also tried to use my 64 chars as passphrase as if it was interpreted as a passphrase instead of raw key by sqlcipher.

[justinclift]

Which version of our application are you using?

I faintly remember seeing someone else have a similar problem a while ago, and it turned out to be a bug that has been fixed since.

If it's the same bug, then try a development build:

https://github.com/sqlitebrowser/sqlitebrowser/releases/tag/continuous

They're pretty stable. 😄

[rlatapy-luna]

@mgrojo Same result (both stable & dev)
There is no other feedback than the SQLCipher encryption prompt when opening the database, so maybe my dotenv is wrong?

./.env
./bc9fe798-a4f0-402e-9f5b-80339d87a041
./bc9fe798-a4f0-402e-9f5b-80339d87a041-shm
./bc9fe798-a4f0-402e-9f5b-80339d87a041-wal

bc9fe798-a4f0-402e-9f5b-80339d87a041=0xadf901f16f28e4903294ee6c6a4edebf3fcc46ec48304c20f0b7bbce61cef11f
bc9fe798-a4f0-402e-9f5b-80339d87a041_keyformat=1
bc9fe798-a4f0-402e-9f5b-80339d87a041_pageSize = 4096
bc9fe798-a4f0-402e-9f5b-80339d87a041_kdfIter = 256000
bc9fe798-a4f0-402e-9f5b-80339d87a041_hmacAlgorithm = SHA512
bc9fe798-a4f0-402e-9f5b-80339d87a041_kdfAlgorithm = SHA512
bc9fe798-a4f0-402e-9f5b-80339d87a041_plaintextHeaderSize = 0

I also trie with only keyFormat and password params, and with another filename like cipher.sqlite

[mgrojo]

This might not be your problem, but you've written above your_db_keyformat and not your_db_keyFormat as expected by the parser.

In any case, I've found a problem in loading the .env file under my platform and Qt version, so I'm going to make a fix. I don't know how long is this happening, but the suspicious code is there since the original implementation. It might have appeared after a Qt change.

[mgrojo]

Hi @revolter,
Regarding (#1404), any particular reason to use a custom format for the .env instead of the Qt-implemented IniFormat? I don't know since when, but the custom format is not working for me, and IniFormat works just as expected. I'll make a pull request with my change so you can see exactly what I have changed.

[mgrojo]

Pull request in #3594

[revolter]

From what I know, the actual format of dotenv files is a subset of the format of INI files.

From what I remember, there was no reason for using a custom regex for parsing them. Most probably, I just didn't think of parsing them as INI files.

As such, I'm all up for it, although I would check if the sections support of INI files (https://en.wikipedia.org/wiki/INI_file#Sections) doesn't break our use case.