Hello Hans, On Mon, Oct 1, 2012 at 12:47 PM, Hans-Christoph Steiner <[email protected]>wrote:
> On 09/28/2012 04:23 PM, Florian Weimer wrote: > > Why isn't it implemented as a VFS plugin? > > I don't know of any other precedent for a VFS plugin for adding > encryption support, do you? Maybe Stephen can speak more to that. Yes, there have been a number of discussions on the SQLite list in the past few years about how to implement database encryption. Many posts indicate that people are building their own schemes using the VFS API. That said, in almost every case the advice to users who post these questions on the list is to buy the commercially licensed SQLite Encryption Extension (SEE) from the authors of SQLite. It uses the codec API rather than VFS, which is the same approach SQLCipher uses. Incidentally, there are also some potential implementation complexities involved with a VFS shim that may not affect trivial examples but that I suspect could become complex for a full-featured implementation (e.g. handling of attached databases, file conversion, safe rekey, offsets / paging to account for IV, MAC, database salt, etc). Also, after posting my previous reply, I realized that my message was blocked because I wasn't subscribed to the debian-security list. I've reproduced my original comments about SQLCipher's design here so it is maintained in the list archives of this conversation. My sincere apologies to those who receive this twice. SQLCipher was initially conceived as an open source alternative to the SEE. > Since SQLite includes codec hooks and API functions (sqlite3_key, pragma > key, etc) for SEE and CEROD support, we chose to use the same approach. The > codec API is narrower in scope than VFS, which has the benefit of reducing > OS-specific concerns. Finally, some of the original design and proof of > concept code for SQLCipher pre-dated a stable VFS API. > I agree that implementing SQLCipher using a VFS plugin would work, and > we've considered it in the past. However, we've decided to stick with the > codec approach for now, given that some functionality could prove more > complex to implement and a major shift / rewrite could introduce challenges > for the project. Cheers, Stephen
