On Wed, Feb 23, 2011 at 1:03 AM, H. Phil Duby <phild...@phriendly.net>wrote:
> On Tue, Feb 22, 2011 at 9:07 AM, Philip Graham Willoughby > <phil.willoug...@strawberrycat.com> wrote: > > > > On 22 Feb 2011, at 15:41, Max Vlasov wrote: > > > The obvious solution is public-key cryptography. The question is about > > > different ways how it could be implemented with sqlite. The requirement > for > > > this system is that it should operate in two modes: > > > - insert-only when no reading operation is used. This mode uses public > key > > > to store the data > > > - full-mode when the private key is supplied and any operation is > possible. > > > > It might work, but it wouldn't be quick. Public-key cryptography is very > slow. There are benchmarks on this page ( > http://www.cryptopp.com/benchmarks.html) but most of what you need to know > is in the choice of scale: AES and other shared key systems are in > cycles-per-byte and RSA/friends are in megacycles-per-operation. > > The simple answer to 'public-key' cryptography is very slow', so to > not encrypt the complete text. Instead you generate a random key for > one of the good [and fast] symmetric encryption implementations, > encrypt the complete text with that, and encrypt only the symmetric > key using public-key encryption. > > Good point, Phil. In case of virtual tables and insert-only mode there might be some intermediate caching (for example based on the boundaries of transaction) that uses the same random key. When the transaction ends the random key will be saved encrypted. In the worst case when a single record inserted wrapped in a transaction, one will get worst performance, but inserting a bunch of records will give a performance boost. Thanks for the idea, Max _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
