Regarding: ...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.
Both SEE and SQLCipher both mention meta-data concerns. >From SEE: http://www.hwaci.com/sw/sqlite/see.html "SEE encrypts the entire database file - both data and metadata. To an outside observer, an encrypted SQLite database file appears to be white noise. Both the database file itself and its rollback journal are encrypted. " >From SQLCipher: https://www.zetetic.net/sqlcipher/design/"Database Encryption and Temporary Files All data in the main database file is encrypted. In addtion[sic], SQLCipher encrypt[sic] data pages in journal files. Provided that you taken the important step of disabling file base temporary stores (i.e. --enable-tempstore=yes during configuration and define SQLITE_TEMP_STORE=2 during build), we are primarily concerned with the following: - Rollback journals - Pages in the rollback journal are encrypted using the same key as the main database. Note that there is an unencrypted header in a rollback journal, but it doesn't contain any data. The journal created by a vacuum run is encrypted in the same way as a rollback journal. *Verification:* create an encrypted database, start a transaction, make changes, and then inspect the -journal file using hexdump or a similar program. - Write Ahead Log Files - Using the new WAL mode (i.e. PRAGMA journal_mode = WAL;), page data stored in the WAL file is encrypted using the datbase[sic] key. Pages in the rollback journal are encrypted using the same key as the main database. *Verification:* create an encrypted database, start a transaction, make changes, and then inspect the -wal file using hexdump or a similar program. - Statement journals - Statement journals are also encrypted. This is harder to "observe" because they are only created under very limited circumstances, and even then they use temporary files that are immediately deleted after use. Note that statement journals are maintained in memory if temporary files are disabled. *Verification: *Compile a build under linux that forces a minimal temp cache size (so that pages are actually written to disk) and allows the use of temporary files, start a transaction with updates that cause a statement journal to be written, and then inspect the file descriptor of the temporary journal in the /proc//fd directory. - Master journals - The master journal does not contain data (see http://www.sqlite.org/atomiccommit.html). Unlike the rollback journals, the master journal does not contain any original database page content. Instead, the master journal contains the full pathnames for rollback journals for every database that is participating in the transaction. Other transient files are not encrypted, so you must disable file based temporary storage if your application will use temp space, as noted above."
