(sorry for the math err s/16/32/g and s/512/256/ - I double and halfed the wrong directions.)
On Sun, Oct 14, 2018 at 7:57 AM J Decker <d3c...@gmail.com> wrote: > > > 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
