Mike Shaver wrote:
On 8/22/05, Edwin Knoppert <[EMAIL PROTECTED]> wrote:
Hmm, but every known file format has an header.
Sqlite has a string, not really a header as it seems.
Maybe for v4 to implement a real header (if not yet)
A header doesn't need to be encrypted.
(A bit for testing if it's encrypted might have it use as well)
In fact, I was wondering about this very issue when I was working on
my own encryption layer for Mozilla's storage use. Does the reliable
format of the first page (known sqlite header string, various other
fields that are very likely to be zero or in some way related to the
size of the DB file) not make known-plaintext attacks on the encrypted
database much easier? Given that the encryption is limited to a page
at a time due to the pager implementation (and placement of the hooks
in sqlite), it would seem that that would be fairly worrisome.
I can mitigate it a bit by having the page number affect the key
selection, but I'm still sort of nervous about it.
Mike
I hope that I don't spill too many beans here....
My company has licensed the RC4 encryption add-on for sqlite.
RC4 is basically an XOR against a huge one-time pad. That pad is
creating using a "key scheduling algorithm". The key state for the
random number generator is 256 bytes of data and two 8-bit indicies.
There are several attacks that can be used to derive the original key
state, but they all require huge samples of data to analyze. RC4 is not
the strongest encryption available, but for most of us, it is good enough.
The best way to attack any system using sqlite w/ the crypto extension
is to hook the call to "sqlite3_key()" and just steal the rc4 key
directly. Much easier than crunhcing numbers on a super computer.
http://en.wikipedia.org/wiki/Rc4
