The only way SQLite can get to the disk is using the vfs, so if the vfs encrypts things, all of the files (main db, temp db, journal, everything) will be encrypted.
I think in your case you can probably even get away without the more elaborate encrypted systems, because it sounds like you don't want things to be persistent across app restarts. So you can just use a random key at startup, and implement xRead and xWrite in the obvious way without needing additional SQLite-level changes. You can initialize the random key before telling SQLite about the VFS. You can either not use additional per-page data, or if you do, you can ignore the page atomicity issues because you don't want the data to be persistent. Another option might be to implement a proxy VFS to wrap the default VFS, and whitelist only the files you have written code to handle. If SQLite wants to create db-random-made-up-file, it will fail because it isn't on the list. WRT your concerns about having it all be in-memory, short of that you could use PRAGMA journal_mode = MEMORY (-journal file in memory) and PRAGMA temp_store = MEMORY (temp tables and the like in memory). IMHO WAL journaling probably doesn't make sense, here, but if it does, I think you need the -wal file on disk, but you can set PRAGMA locking_mode = EXCLUSIVE to have the WAL's index kept in memory without an anonymous shm file. -scott On Wed, Apr 22, 2015 at 8:56 AM, Simon Slavin <slavins at bigfraud.org> wrote: > On 22 Apr 2015, at 4:46pm, Michael Stephenson <domehead100 at gmail.com> > wrote: >> Simon, if the data in the database is sensitive, could you encrypt the >> database (ala something like https://www.zetetic.net/sqlcipher/)? > > Unfortunately, this doesn't help. I'm not concerned with the database file > itself. I know exactly what that's called, and I can check it has been > correctly deleted. I'm concerned with the data in several external files > that SQLite creates and deletes as it does its work. Some of those would > contain unencrypted data. And some of them have unpredictable names, or, at > least since the filenames are not documented they may change in future > versions of SQLite. > > You have made me realise, however, that a nice attack against encrypted > SQLite databases might be to crash a SQLite application while it's processing > and examine any journal files, shared memory file and temporary index files. > It might be interesting to review the various encryption systems widely > available for SQLite and figure out which of them would be vulnerable to such > an attack. > > By the way, if you want good (paid, not free) SQLite encryption you want to > check out > > <http://www.hwaci.com/sw/sqlite/see.html> > > Simon. > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
