On Sat, 2011-02-19 at 17:08 -0800, Roger Binns wrote: > On 02/19/2011 03:40 PM, Robert Hairgrove wrote: > > But before I "try this at home", I thought I would ask if there are any > > caveats I should be aware of? Thanks for any helpful advice!
Thanks, Roger ... those are great links! > Unless your time has no value, I'd suggest using this: > > http://www.hwaci.com/sw/sqlite/see.html I saw that, but I find it a little intrusive, programmatically speaking, from a licensing standpoint. Although SQLite itself is PD licensed, I am using it coupled with the Qt source code which is LGPL licensed. So I'm not really not sure how this encryption add-in would play with that if I have to recompile something I got from Qt in the first place. My application is a closed-source commercial one, and linking dynamically to Qt without changing any of the Qt sources is allowed under the LGPL. If I can hook in my own read/write routines like this at runtime, I won't have to alter and/or recompile any of the library sources. I *could* build the Qt SQLite module with SEE as a plug-in, but would rather link it statically (and the SEE people apparently want it that way, too). In this case, I would need to treat the SQLite sources the same as any of the other Qt sources. But "IANAL", so maybe I am being too cautious here. > (Note that it is supported, tested and cryptographically sound. It would > take you a long time to achieve the same.) I am not starting from scratch doing my own encryption; there are enough open source libraries publicly available which are good enough for my purposes. > If you just want whole file encryption then I'd recommend using an archive > tool and storing/extracting as appropriate. For example 7zip does this well > and is open source. Compression is not the same as encryption. The application is primarily for school teachers (single-user desktop use, which is why SQLite is ideal for this) and the database might contain stuff like confidential student reports, grades, etc. Since I am not trying to protect highly sensitive government secrets or medical data here, although someone could probably use the app for that as well, I do worry that some student might get hold of the file and try to hack it. A clever student would see right away that compression and not encryption was employed -- and a student's time usually DOES come cheap! ;) > If you really want to do your own thing then beware that the encryption key > has to be where the data is encrypted/decrypted. You should carefully study > exactly what it is you a protecting, who you are protecting it from, how > long it is protected etc. These can help: > > http://www.schneier.com/paper-attacktrees-ddj-ft.html > > If you really do still want to proceed then xRead/xWrite are an appropriate > place to do it. Thanks, this is what I needed to know. > http://en.wikipedia.org/wiki/Initialization_vector > > Anyone can design a scheme they themselves cannot break. It requires far > more skill and experience to come up with something that is actually strong. > > Also consider that what you may actually need is just some obfuscation. For > example you could just XOR the database contents with deterministic bytes. > If you did this then seeing the contents would go from costing a few dollars > (load the file into the command line shell) into a few hundred or thousand > (figure out what it is you did). In any event an attacker could always > point a gun or use a hardware keylogger if they don't want to be discovered. > That would workaround any encryption scheme. I would hash the user-supplied passphrase with a value known internally to my program to create the final encryption key, so the hacker would have to have a copy of the executable of my program in addition to whatever data was gleaned by using a key logger. And each licensed copy of my program would have a unique hash value embedded within the executable. As to the gun, Bruce Schneier already pointed out that this is one of the more expensive options in the attack tree. ;) Bob _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
