[Botan-devel] SQLite3 encryption codec with Botan
mr.diggilin at gmail.com
Mon Apr 13 22:48:51 EDT 2009
> 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:
> 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
> 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
> 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.
That's all very interesting, and clears up some questions I had on the
whole theory of things.
Only one thing I'm a little unclear on at this point...
As I understand one key constraint is that the page size must be
preserved. What I don't understand is what the options are for doing so:
What block ciphers can fulfill this requirement? And what modes (if any)
are unusable because of this?
In the Bitlocker paper, they discuss AES, Bear and Lion as the only
secure block ciphers that fulfill the requirements. They dismiss Lion
and Bear as too slow, then they go on to see what modes would provide
their "poor man's authentication" with AES. After all is said and done
they settle on what they call diffusion.
Then there's the question of XEX/XTS, which they don't discuss at all in
the paper (didn't exist yet?). Are these modes the solution to what they
used diffusion for?
You mention that you'll probably have to add something (another cipher?)
to Botan because Lion is too slow... but everyone seems to be saying
that AES is the only alternative, and of course AES is in Botan. What am
I missing here? Is AES a "length-preserving" cipher? Are there any
others that aren't too 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.
Sounds like it would have to limit the options of cipher/mode, but other
> Yes I would definitely be interested in including this.
> botan-devel mailing list
> botan-devel at randombit.net
More information about the botan-devel