Ulrich Telle wrote: > Am 31.08.2013 22:01, schrieb Etienne: >>>> On Sat, 31 Aug 2013 17:17:23 +0200 >>>> Etienne <[email protected]> >>>> wrote: >>>> >>>> > > On the other hand removing patterns definitely cannot hurt. >>>> > >>>> > Precisely. >>>> > >>>> > The very first bytes of SQLite files are, AFAIK, well known. >>>> >>>> That's what salt is for, no? >>>> >>> "nonce", "IV", "salt" - call it whatever you want. Yes. >> >> 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 as SEE does according to the documentation to be found > here: http://www.sqlite.org/see/doc/trunk/www/readme.wiki
Funny, for all encryption modes, used in SEE (rc4, AES-OFB, AES-CCM), *any* IV reuse ends up in bad [OFB] or even catastrophic [rc4, CCM] way (you must *never* encrypt any two blocks with same IV with those modes). But that's just result of inappropriate choice of those encryption modes. There are encryption modes with *different* properties. Normally disk encryption use CBC+ESSIV, XTS or LRW, which ain't sensitive to IV reuse (unmangled/plain sector number as IV works just fine with them). > In both cases you know the IV - at least if you have access to the code > generating it (which is the case for wxSQLite3 as it is open source, but > not for SEE as it is closed source). > > 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. To get a better encryption maybe the first 16 bytes should > always be kept unencrypted to not give a clue to a known pattern. > >> 2 SQLite DBs built exactly the same way at different times are >> byte-to-byte identical. > > That's true. However, in real life it probably matters only for > read-only databases. As soon as different people start to work with such > an encrypted database, the database files will certainly deviate from > each other considerably as it is very unlikely that all users perform > their actions in exactly the same order. > > BTW, you only get identical database files if you use the same > passphrase. If the passphrase is hardcoded into the software then > certainly this may impose a problem. However, for an application with > high security demands you certainly shouldn't hardcode the passphrase > into the software. FYI: two LUKS or truecrypt containers with same passphrase *won't* be same (and they *don't* need to save per-sector nonce/IV separately, unlike SEE). _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
