At the other hand, this is database stuff, what on earth would you encrypt
in real life business databases.
No one cares, except for a few purposes.
(Now i done it :) )
Encrypting a header, like if any virus writer is busy with a tool like
sqlite..
pfffttt.
----- Original Message -----
From: "Dennis Jenkins" <[EMAIL PROTECTED]>
To: <sqlite-users@sqlite.org>
Sent: Tuesday, August 23, 2005 12:07 AM
Subject: Re: [sqlite] Why can i open a textfile?
Mike Shaver wrote:
On 8/22/05, Dennis Jenkins <[EMAIL PROTECTED]> wrote:
I very much disagree. I want the entire file, header included, to be
encrypted. Sometimes you don't want anyone to know what the file type
is. Security through obscurity is not secure. However, you don't want
to give the bad guys a road map either...
Finding out that it's a sqlite file is not a hard problem for an
attacker who has any interesting access to your machine, since your
programs must find that file somehow. Once they find it, are you not
concerned about lightening their cryptanalysis burden through
known-plaintext attacks?
Mike
No, not really. The sqlite crypto engine consumes the first several
hundred bytes of the rc4 random number generator output. It is my
understanding that this would significantly complicate the plain-text
attack. But I'm not a crytologist. I do find it facinating though.
I do not understand how "finding the file" would give the attackers any
clue to what kind of file it is (unless I make the filename something like
"sqlite3.db3"). If the file were named "jimbob.dat", and the contents
looked like gibberish, then what do they know? They must analyze the
program that accesses the file.
I once thought that I could remove all text strings from the sqlite code
that would give the attacker any clues. I then realized that the strings
are important to the proper functioning. The ones that need to be left
behind are significant enough to be good clues that the program uses
sqlite technology. So, I do agree with you, that it is not too difficult
to determine if a data file _might_ be an sqlite database, even if it in
encrypted.
That being said, I still like having the header encrypted as it is. Maybe
it just makes me feel warm and fuzzy on the inside :)
In the end, I feel that our software is much more vulnerable to someone
attacking it with a debugger than with crypto analytic attacks. At some
point, you must call "sqlite3_key()" and pass it three things: the sqlite
handle, a void* to the key initializer and an "int" (# of bytes in the
key). All the attacker has to do is locate that code and determine what
those last two arguments are. Personally, I find this to be an easier
approach. But then, I've been coding in assembly since I was 8 and C for
the last 10 years. I'm not much of a mathematician or code breaker.
I have often wondered how difficult it would be to derive the rc4
initialization key given a known plain text and a known cipher text
generated from the unknown key and known plain text. I imagine it as a
breadth-first search of the key space.
Lets say that it is computationally feasible to do just that. The sqlite
header string is.. um, heck, I don't know, let's say 20 bytes. Then you
can derive the exact values for at most 20 values of the key state vector
(it might be less if a value gets muted more than once). What do you know
about the remaining bytes of the first 256 bytes of the sqlite file? Some
of those bytes have "sane" values or other constraints. I think that it
would be too difficult to fully derive the key b/c you don't know much of
the plain text.
This is the extent of what I know about rc4. If someone else knows more,
please enlighten me. :)
