Etienne wrote: > ----- Original message ----- > From: Paolo Bolzoni <paolo.bolzoni.br...@gmail.com> > To: General Discussion of SQLite Database <sqlite-users@sqlite.org> > Subject: Re: [sqlite] to encrypt sqlite db > Date: Sun, 1 Sep 2013 18:24:13 +0200 >> On Sun, Sep 1, 2013 at 6:10 PM, Etienne <etienne.sql...@mailnull.com> wrote: >>>> On Sun, Sep 1, 2013, at 17:50, Clemens Ladisch wrote: >>>>> Ulrich Telle wrote: >>>>>> Am 31.08.2013 22:01, schrieb Etienne: >>>>>>> I simply wanted to warn the OP that wxSQLite, while free, does NOT use >>>>>>> salts: >>>>> Well, that's not completely true. The encryption extension coming with >>>>> wxSQLite3 uses a different IV (initial vector) for each database page. >>>>> True is that the IVs are not random, but deduced from the page number. >>>>> However, I don't see much difference between generating an IV >>>>> algorithmic or using a random nonce which is stored at the end of each >>>>> database page >>>> <http://en.wikipedia.org/wiki/Initialization_vector> says: >>>> | Randomization is crucial for encryption schemes to achieve semantic >>>> | security, a property whereby repeated usage of the scheme under the >>>> | same key does not allow an attacker to infer relationships between >>>> | segments of the encrypted message. >>>> >>>> Without a random IV/nonce, every page is guaranteed to encrypt to the >>>> same data if the contents and the key have not changed. Thus, wxSQLite3 >>>> gives an attacker the ability to determine whether any particular page >>>> has changed, by comparing the old and new versions. With SEE, rewriting >>>> a page will encrypt to a different value because the IV changes even for >>>> otherwise unchanged pages. >>>>> The weak point of probably all SQLite encryption methods is that the >>>>> unencrypted content of the first 16 bytes of a SQLite database file is >>>>> well known. >>>> Many file formats have fixed parts. However, this is not a problem with >>>> properly implemented encryption algorithms. >>>> >>> >>> In this particular case, you get what you pay for. >>> >> >> Another weird sentence in the mailing list >> of probably most used DB that is really free. > > wxSQLite (relevant part) and SEE are extensions to SQLite. > > wxSQLite is free, while SEE is definitively not. > > wxSQLite means "pseudo" encryption (as formerly discussed), while SEE is real encryption. > > What is weird???
Weird is to talk about something one have little clue about? ** Have you looked at wxSQLite sources? Obviously, no. Otherwise you'd know there are more in story than just IV generation - they also alters key per-page (*edit* and, of course, wxSQLite don't use ECB!). While wxSQLite encryption have some, erm, strangely/unusually designed parts, that "strangeness" is about on par with (different) SEE's "strangeness". I don't see reason to claim SEE offers any more "real" encryption than wxSQLite (in AES256/SHA256 mode). Compare both of them with "truly real encryption" schemes, e.g. used by LUKS or truecrypt; you'll notice several differences at once (e.g. lack of key strengthening in SEE [apparently, they use password as raw encryption key - there are no other way to explain "... only the first 256 bytes (RC4) or 16 bytes (AES) will be used..."] - important when you target your product for crypto-illiterate users; plus, while "silent key truncation" is documented and can be claimed "not a bug", it can lead to nasty surprises in hands of said crypto-illiterate users; lack of password salting in both; no way to change password without re-encrypting whole database in both; very unusual/unsuitable for FDE encryption modes in SEE; unusual per-page keys and IV generation scheme in wxSQLite [it is not broken in obvious way, but "crypto" and "unusual" together sounds troubling]; unbalanced AES128/MD5 algo pair in wxSQLite; so called "random" nonce in SEE - how was that "random" generated and seeded?***; and, at last, their use of their own crypto implementations instead of optimized libraries [compare their speed with e.g. `openssl speed aes-128-cbc`, especially on CPUs with AES-NI or SSSE3 available]; and maybe more). *** Obtaining *true* randomness in naturally deterministic computers is not easy, especially on virtualized and embedded platforms; and crypto-quality PRNG is even more complex problem; Debian's openssl, sony ps3 or recent androids disasters comes to mind; FWIW, from the first look, sqlite's random.c/os_unix.c/os_win.c PRNG seems unqualified for use as "crypto RNG" (it's [always] badly seeded on windows; it can be [silently!] *very* badly seeded on some semi-broken configurations on unix; and, finally, RC4 has rather dubious reputation in crypto circles - it is very fast and trivial to implement and "can work well in right hands", but at the same time extremely quirky and easy to misuse in unsafe way; and the way it is used in sqlite PRNG induce some doubts); nothing terrible wrong in that (I don't remember it was ever claimed to be crypto-quality), but let's only hope it was NOT used in SEE for that "random nonce" generation :-) (as encryption modes used in SEE fails badly or catastrophically on *any* IV reuse). -- PS ** uh-oh, yeah, I'm guilty too, I'm not crypto expert. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
