Yes, the master thing is what i tried with the previous version.
I guess i'll use it on the newest dll again.
Not so important from now on.
----- Original Message -----
From: "Drew, Stephen" <[EMAIL PROTECTED]>
To: <sqlite-users@sqlite.org>; <sqlite-users@sqlite.org>
Sent: Tuesday, August 23, 2005 1:02 AM
Subject: RE: [sqlite] Why can i open a textfile?
Point taken about viruses perhaps, but there are other reasons one might
want to encrypt data - which by its very nature could be related to
anything.
For example, in a commercially competitive environment, it might be easy
for a competitor to gain access to files, or even colleagues within the
same organisation who do not have the privilege to see such data. A file
that can be easily read, often will be - whereas an encrypted file, of any
reasonable level, will often be enough to deter prying eyes.
If one needs to know whether a file is a database or not immediately after
opening it, surely a user-written wrapper function around sqlite(3)_open
which does a simple select on sqlite_master is the way to go? Keeps
everybody happy.... Personally I'd wrap the calls to sqlite anyway but C++
sort of suggests doing this regardless....
Steve
-----Original Message-----
From: Edwin Knoppert [mailto:[EMAIL PROTECTED]
Sent: Mon 22/08/2005 23:20
To: sqlite-users@sqlite.org
Cc:
Subject: Re: [sqlite] Why can i open a textfile?
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. :)
>
>
>
