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??? Regards, Etienne ----- 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 Another weird sentence in the mailing list of probably most used DB that is really free. 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. >> >> Regards, >> Clemens > > Amen. > > In this particular case, you get what you pay for. > > Regards, > Etienne _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
