[Botan-devel] SQLite3 encryption codec with Botan

Jack Lloyd lloyd at randombit.net
Mon Apr 13 12:33:17 EDT 2009


On Sat, Apr 11, 2009 at 02:39:38PM +0800, Mr Diggilin wrote:

> As far as I can tell, SQLite will first call your function to provide a
> passphrase from which you create a key. Then it'll call another function
> to request encryption or decryption of a given database page. It is also
> my understanding that the key I create will be for the whole database,
> and in any case I have no information on the row or table at all. All I
> have is the given page number and page data for each encipher/decipher
> operation.

OK, I took a look at the implementation of this in SQLite's pager.c
and things are a bit more clear now.

> I intended to use the page number as the IV for the encryption operation
> however, does that sound good?

It seems to me the problem being solved here is identical to that of
disk encryption: data is encrypted to storage, with sequential block
identifiers.

This is not an area that I have studied too deeply, so it's hard for
me to make specific recommendations. Wikipedia has an overview of
disk encryption and some of the commonly accepted modes:
 http://en.wikipedia.org/wiki/Disk_encryption_theory
 http://en.wikipedia.org/wiki/IEEE_P1619

A mode like XEX or XTS might be appropriate: it seems to be well
accepted by implementors, and the IEEE has standardized XTS for disk
crypto. Another approach might be the scheme used in Microsoft's
BitLocker system
(http://download.microsoft.com/download/0/2/3/0238acaf-d3bf-4a6d-b3d6-0a0be4bbb36e/BitLockerCipher200608.pdf),
though BitLocker's threat model is specifically preventing
confidential data loss (the "lost laptop" scenario) and this may not
provide all the attributes one might desige in an encrypted db. Even
so the BitLocker paper is good about describing the general scenario
and design constraints, and has some overview of various alternative
solutions.

As best as I can tell from SQLite's code, the page size is always to a
power of 2, at least 512, and no more than 32K (and seems to be 512
bytes by default on all platforms). This fits in well with the
constraints assumed by drive encryption systems (BitLocker is only
designed to handle up to 8192 byte sectors, though)

Some of this work is probably on me: the only transofrm that even
might be well suited for length-preserving operations currently in
botan is the Lion cipher, which is very slow.

> I intend to make it something you can append to the SQLite amalgamation
> distribution (which seems to be good practice among SQLite3 codecs), and
> then to be able choose your algorithm simply by changing the const
> strings that are passed to Botan's get_cipher and get_s2k.
> The reason I ask if you'd be interested is because I don't have any
> channel for distribution, and besides, if done right it could become a
> valuable feature for Botan.

Yes I would definitely be interested in including this.

-Jack



More information about the botan-devel mailing list