On 14-10-2018 17:07, J Decker wrote: > (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. >> >> >>
Thanks for the explanation ... I never would have guessed that you "I double and halfedthe wrong directions. " 😊😊 _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
