Protecting SQLite Data

[stampede]

Somehow the db is unencrypted.

Using windows xp, got the same issue, compiled sqlcipher and could open "encrypted" databases created with sqlcipher/sqlite3.exe with any sqlite browser.
This is important how do you configure the sqlcipher, when I've followed the tutorial it wasn't working, but then I reconfigured using additional options:

configure --disable-tcl --disable-amalgamation --prefix=/c/qt/src/plugins/sqldrivers/sqlcipher CFLAGS="-DSQLITE_HAS_CODEC" LDFLAGS="-LC:/OpenSSL-Win -leay32"

configure --disable-tcl --disable-amalgamation --prefix=/c/qt/src/plugins/sqldrivers/sqlcipher CFLAGS="-DSQLITE_HAS_CODEC" LDFLAGS="-LC:/OpenSSL-Win -leay32"

To copy to clipboard, switch view to plain text mode 

After make I get sqlite3.exe which I can use to create really encrypted databases ( as in ChrisW67 post ).

------------------------------
edit:
just tested the sqlcipher plugin for Qt, works ok too

[ChrisW67]

I just read the thread and I'm still not convinced this whole approach is safe. At some point there will be a plaintext version of the password somewhere in the process memory and no executable mangling will prevent that.

This is the perpetual problem of any DRM scheme... you are giving the attacker both the encrypted data and the key. There's no way around it. All you can do is make it difficult to extract. For example, the Armadillo wrapper includes anti-dumping measures, anti-debugger measures, on-the-fly encryption of code segments, object file rearrangement and other things. Properly used the key is very hard to get at and you have to weigh the effort required to attack the protections against the value of the thing being protected.

[wysota]

The key can can be embedded in hardware in such a way that it never leaves the sillicon. Of course you can still try to copy the chip.

[ChrisW67]

We might have to wait until Qt 6.0 for the addition of the QtSilicon module