Can you turn off logging and overwrite the database with unencrypted zeros or nulls; just before deleting it?
Encrypting the overwrite character(s) would give the encryption attacker a cleartext -- a bad move right out of the "Imitation Game". Jim On Wed, Apr 22, 2015 at 10:34 AM, Simon Slavin <slavins at bigfraud.org> wrote: > > On 22 Apr 2015, at 3:23pm, John McKown <john.archie.mckown at gmail.com> > wrote: > > > If it is > > a POSIX compliant, perhaps what you could do is create a "temporary" > > (mktemp) file of "appropriate" size. > > I had never considered that idea. Thank you very much. Unfortunately it > won't work in this situation because the people in control of the system > would either say "No virtual file systems" or leap at the idea and insist > that everyone uses virtual encrypted file systems for all data files at all > times. I'm not sure which would be worse. > > > On 22 Apr 2015, at 3:14pm, Richard Hipp <drh at sqlite.org> wrote: > > > Can you add the SQLITE_OPEN_MEMORY option to the sqlite3_open() call, > > forcing SQLite to keep all content exclusively in memory and never > > writing to disk? > > Sorry, the data can potentially get too big to keep it in memory (even > virtual memory). But a memory database would be a great solution if I > could rely on it being small. Thank for that too. > > I'm guessing that since you didn't point out any persistent SQLite > temporary file that I'd missed there are no obvious problems with the > procedure I included in my post. That's good enough for the SQLite-related > part of this problem. > > Simon. > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users >
