On Wed, Apr 22, 2015 at 8:14 AM, Simon Slavin <slavins at bigfraud.org> wrote:
> > On 22 Apr 2015, at 2:07pm, Paul Sanderson <sandersonforensics at gmail.com> > wrote: > > > You haven't said what operating system you are using > > Sorry, but I can't. However, the OS is strongly oriented towards security > paranoia. As long as the proper OS calls are used to delete files and > release memory, you can assume that they are unrecoverable, with all the > stuff a forensic expert would hate. The same is true of any caching done > at OS level or below (e.g. device drivers, storage which automatically > manages sector usage, etc.). > > > This might be a level of access you are not concerned with - I guess > > that all depends on how sensitive sensitive is :) > > You got it. But the platform (OS and hardware) is specially designed for > this. As you suspected I'm concerned only at the level of filespace which > is still in use. > > Simon. > ?Well, it is difficult, if not completely impossible to say without knowing the OS involved. But since you indicated "strongly oriented towards security paranoia", I am certain that it cannot be from Microsoft. If it is a POSIX compliant, perhaps what you could do is create a "temporary" (mktemp) file of "appropriate" size. Now create an encrypted filesystem into that file. Mount this filesystem "somewhere". Make it the current directory. Create all your databases inside it.? # Example in Linux cd /somewhere tfile=$(mktemp -p .) #create temporary file dd if=/dev/zero of=${tfile} bs=1024 count=1048576 # 1 gig mkdir tempfs sudo mount ${tfile} tempfs #mount the temporary file system rm ${tfile} #remove temp file while leaving it mounted cd tempfs #make tempfs the working directory ... do sqlite3 program(s) here cd .. sudo umount tempfs #unmount, which will remove inode as well ?Of course, I don't know if your OS can do the above because you can't say anything about it. Also, I showed this as a shell script, but you could do the equivalent in your application program before initializing the SQLite environment. If you want/need to, you could do the unlink() (rm command) _after_ terminating the the SQLite environment, unmounting the filesystem, and overwrite the file contents before doing the unlink() to delete it.? ?In any case, even if you can't do exactly the above, perhaps it will spark some other idea for you. -- If you sent twitter messages while exploring, are you on a textpedition? He's about as useful as a wax frying pan. 10 to the 12th power microphones = 1 Megaphone Maranatha! <>< John McKown