On Sun, Oct 14, 2018 at 7:24 AM Luuk <luu...@gmail.com> wrote: > On 14-10-2018 16:17, Simon Slavin wrote: > > On 14 Oct 2018, at 12:56pm, J Decker <d3c...@gmail.com> wrote: > > > >> Is there maybe a compile option for sqlite to fill empty space in a db > with random data rather than 0 ? > > There is not. But > > > > (A) It may be an easy change to the source code > > (B) Your operating system may have a setting to do this automatically to > freed blocks on a storage device. > > (C) Your device driver may have a setting to do this automatically to > freed blocks on the device. > > > > That type of security is normally done at OS or device level, not by > each individual app. > > > > Simon. > > > Can you give any hints on why it would be a security issue to fill > 'empty space' with 0, and why 'random data' should be used? > > ? > I hesitate to describe the real scenario; and want to instead manufacture one; but in either case I feel there will be more comments about the underlaying system than on Sqlite itself.
In the simple case, the VFS that the sqlite Db is mounted in is encrypted with a long key. The key has cycles at 4096(A) and 16(B1-Bn) bytes (4096/16 = 256 cycles of Bn); such that each sector is masked with A^B1(256x), A^B2(256x), ... all together there is no repetition because the change from Bn to B(n+1) at the 4096 boundary makes the stream overall appear continuously random. Only data that is written is actually masked... Sqlite likes to write 0's in large splotches (in my usage); which leaks key information; (only slightly more than the data stored in tables typically, which is a lot of the same bytes (0, 1 for instance and A-Z, a-z less-so; but all of that has upper bit(s) that are 0... ) And even is a specific sector (or several) is 'cracked' it doesn't do any good for any other page... but if LOTS of pages are found, it becomes easier to find what the overall A key is, which makes finding sector keys that you only need a few 32-64 bytes of 0's to reveal the sector specific key (for later use?) The keys are a procedurally generated with a PRNG sha2 bit streams based; so 512 bits (16 bytes) at a time; and sha algorithms generates VERY good PR numbers. which can be consumed as end-to-end bit streams. I might look into it; there are certainly a great test suite available to reveal issues; but I expect Sqlite 'expects' memory to be 0 initialized (even when filled from disk) and that it will be a HUGE can of worms. > > _______________________________________________ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
