On Wed, Jan 13, 2010 at 04:07:19PM -0800, Roger Binns scratched on the wall: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Jay A. Kreibich wrote: > > All you really need to do is splice your code between the VFS that > > the SQLite engine sees and the native VFS layer that comes with the > > distribution, adding a bit of extra code to xRead() and xWrite() to > > munge the data. > > It is certainly possible to do it this way. It is however a really bad idea > to write your own encryption scheme.
Absolutely. I never meant to imply someone should write the actual encryption algorithm, only the glue to attach SQLite's pager to an existing crypto library. Anything else would be utterly foolish. Even then, mistakes with key management and proper defensive coding can frequently allow back-door attacks. For example, since the most obvious choice is a stream cypher that works on a per database-page basis, it would be advisable to use larger pages to avoid constantly re-starting the stream. One might also consider transforming the key based off page position so that you don't have any page headers or structure that could be analyzed as semi-known plain-text. You would also want to alter the new-page allocator to scramble any unused part of the page for the same reasons. > Consequently it would be foolish to not use the SEE extension, and pay the > small fee for it. As I said before, I think SEE is a great choice. It is a fantastic value and a logical first choice for anyone looking to evaluate encrypted databases. That said, it doesn't fit every need. Most notably, it isn't practical to use within an open-source project, commercial or otherwise. SEE may be very reasonably priced and come with a full source license, but it also comes with an NDA and a specific limitation on redistribution of the source code. Plus, if everyone would remember, the original poster specifically asked about alternatives to the SEE extension. I think dismissing SEE is a mistake, but that's their business, not mine. I'd like to assume they know what they're doing and have their reasons for looking elsewhere. I seriously doubt anyone could replicate the functionality of the SEE extension for less than the cost of a license. In fact, I suspect this is the main reason why there isn't a popular open-source alternative-- the real deal is a fantastic value. But there are still situations were SEE is simply not a feasible choice. I would also guess most of those situations are going to involve reasons and decisions that are firmly based in the realm of business, license, and political issues, and not technical issues. I have full confidence in the technical capabilities of SEE. But the world does not run on technical decisions alone. -j -- Jay A. Kreibich < J A Y @ K R E I B I.C H > "Our opponent is an alien starship packed with atomic bombs. We have a protractor." "I'll go home and see if I can scrounge up a ruler and a piece of string." --from Anathem by Neal Stephenson _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
