For an encryption scheme to suffer enigma machine type vulnerabilities, the 
concept behind it must predate WWII.

IIRC the last straw (apart from known clear text like all messages ending with 
the same greeting) the broke the enigma encoding was the fact that a radio 
operator on an italian ship was told to transmit a test message. Nobody 
provided an unencrypted text, and so he proceeded to transmit a message 
consisting of a long run of the letter L. Due to electricall constraints, the 
enigma machine never translated a character to itself - thus there was no L in 
the chipher text, which oddity was detected by the cryptanalyst, and led him to 
assume a clear text of all L.

-----Ursprüngliche Nachricht-----
Von: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] Im 
Auftrag von J Decker
Gesendet: Sonntag, 14. Oktober 2018 16:57
An: General Discussion of SQLite Database <sqlite-users@mailinglists.sqlite.org>
Betreff: [EXTERNAL] Re: [sqlite] Fill empty space with random

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


___________________________________________
 Gunter Hick | Software Engineer | Scientific Games International GmbH | 
Klitschgasse 2-4, A-1130 Vienna | FN 157284 a, HG Wien, DVR: 0430013 | (O) +43 
1 80100 - 0

May be privileged. May be confidential. Please delete if not the addressee.
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to