Re: [sqlite] [EXTERNAL] Re: Fill empty space with random
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 Betreff: [EXTERNAL] Re: [sqlite] Fill empty space with random On Sun, Oct 14, 2018 at 7:24 AM Luuk wrote: > On 14-10-2018 16:17, Simon Slavin wrote: > > On 14 Oct 2018, at 12:56pm, J Decker 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
[sqlite] Missing SQLITE_OMIT_* in https://www.sqlite.org/compile.html
Hi I noticed that the recently added options SQLITE_OMIT_WINDOWFUNC and SQLITE_OMIT_UPSERT are not described at: https://www.sqlite.org/compile.html. I suppose that they should be described in that page. Perhaps there are other SQLITE_OMIT_* options missing in the page. I did not check all of them. Regards Dominique ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Fill empty space with random
> > 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… Apologies if I’m wrong or am missing something. This sounds like wrong usage of encryption (ECB). If the underlaying storage is encrypted properly ( maybe AES in counter mode with the counter being the block number or something), there is no way to recover a key from learning any other blocks. Thilo ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] SQLite mailing list [was: SQLite Windows GUI alternative to Excel?]
> On Oct 15, 2018, at 5:36 AM, Rowan Worth wrote: > > Anyway my point is I'm not seeing evidence to support the assertion that > gmail treats messages to the list in general as spammish. Ditto. ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] error message: [FireDAC][Phys][SQLite] Database is locked
> For the record, "delete the journal file" is terrible advice Agreed. In normal production environment, I wouldn't suggest that. The user was testing a database, and in my own developemtn cycle, its common when developing for a database to be in all manners of chaos states. It was purely a 'gotcha' that has caught me out before - a journal file lingers and locks the system. On Mon, Oct 15, 2018 at 4:03 AM Rowan Worth wrote: > On Sat, 13 Oct 2018 at 00:21, Chris Locke > wrote: > > > > Database is locked > > > > Close your application. Is there a xxx-journal file in the same > directory > > as the database? (where xxx is the name of the database) > > Try deleting this file. > > > > For the record, "delete the journal file" is terrible advice and a great > way to corrupt a database. In the case where a program crashes > mid-transaction, the journal contains information which is crucial for > recovering to a correct database state. And in non-crash scenarios, the > journal should be cleaned up¹. So when you can see a journal file it's > likely that either: > > 1. some program is currently using the DB, or > 2. there was a crash mid-transaction > > Either way, deleting the journal is a wrong move. > > ¹ unless the DB is configured with PRAGMA journal_mode set to TRUNCATE or > PERSIST, in which case you've asked for the rollback journal to linger > around. > > -Rowan > ___ > 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
Re: [sqlite] error message: [FireDAC][Phys][SQLite] Database is locked
On 2018/10/15 5:05 AM, Rowan Worth wrote: On Sat, 13 Oct 2018 at 02:20, Lars Frederiksen wrote: Any ideas? Not sure if this got resolved off-list, but based on the code you've posted I wonder if there is an "fdqGloser" as well as an "fdqGloser2", and if so what state it is in. Update: This was indeed resolved off-list. Thanks for the added thoughts. The problem turned out to be related to FireDAC automagic and moving some DB connecting/opening code out of the form's OnCreate and into a more sensible event call did the trick. SQLite was innocent. :) ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
