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:[email protected]] Im Auftrag von J Decker Gesendet: Sonntag, 14. Oktober 2018 16:57 An: General Discussion of SQLite Database <[email protected]> Betreff: [EXTERNAL] Re: [sqlite] Fill empty space with random On Sun, Oct 14, 2018 at 7:24 AM Luuk <[email protected]> wrote: > On 14-10-2018 16:17, Simon Slavin wrote: > > On 14 Oct 2018, at 12:56pm, J Decker <[email protected]> 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 > [email protected] > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list [email protected] 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 [email protected] http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
