Re: [sqlite] equality searches and range searches with encrypteddata

2008-08-27 Thread P Kishor
On 8/27/08, Dennis Cote <[EMAIL PROTECTED]> wrote: > P Kishor wrote: > > > > > only badly written Perl, or Perl specifically written to be obfuscated > > such as in Perl golf, is inscrutable. Well written Perl (I practice as > > close to literal programming in Perl as possible) is quite pleasant >

Re: [sqlite] equality searches and range searches with encrypteddata

2008-08-27 Thread P Kishor
lovely discourse, but although I feel bad disagreeing (on a tiny point) with the otherwise very agreeable Mr. Cote... On 8/27/08, Dennis Cote <[EMAIL PROTECTED]> wrote: > Derek Developer wrote: > > Thanks for the link. Unfortunatly its a little expensive and probably > > 50% slower than my

Re: [sqlite] equality searches and range searches with encrypteddata

2008-08-27 Thread Dennis Cote
Derek Developer wrote: > Thanks for the link. Unfortunatly its a little expensive and probably > 50% slower than my implementation. > On what basis do you make that claim? > No offense, but C is a language that a lot of us tolerate and is not > the panacea that some C developers like to believe

Re: [sqlite] equality searches and range searches with encrypteddata

2008-08-26 Thread Derek Developer
Thanks for the link. Unfortunatly its a little expensive and probably 50% slower than my implementation. No offense, but C is a language that a lot of us tolerate and is not the panacea that some C developers like to believe it is. Reading C is like reading Chinese. ASM may not be a high

Re: [sqlite] equality searches and range searches with encrypteddata

2008-08-25 Thread Cory Nelson
On Mon, Aug 25, 2008 at 6:33 PM, Derek Developer <[EMAIL PROTECTED]> wrote: > Dennis thank you for taking the time to explain that. I have read the > Architecture page and I think I have a better idea. > > Since this does seem to be a viable way to protect the data I would like to > implement

Re: [sqlite] equality searches and range searches with encrypteddata

2008-08-25 Thread Derek Developer
>No, the index is stored in a separate Btree. The master table simply >stores the page number of that btree's root page. With that information >SQLite can read and decrypt the index's root page and begin a O(log N) >search for the first matching record, reading in and decrypting more >pages as

Re: [sqlite] equality searches and range searches with encrypteddata

2008-08-25 Thread Dennis Cote
Igor Tandetnik wrote: > > Since I'm not entirely clear of the set of premises you refer to as > "that", I'm not sure whether they happen to be the case or not. But > since I know the conclusion you arrived at is false, I can only assume > that one or more of those premises are incorrect,

Re: [sqlite] equality searches and range searches with encrypteddata

2008-08-25 Thread Igor Tandetnik
Derek Developer <[EMAIL PROTECTED]> wrote: > appologies, "master database" should read "MASTER TABLE" > This is where the index is stored I assume? An index is an index. It's not stored in any table, "MASTER" or otherwise. > You suggested that each record would NOT be decrypted for a SELECT >

Re: [sqlite] equality searches and range searches with encrypteddata

2008-08-25 Thread Dennis Cote
Derek Developer wrote: > appologies, "master database" should read "MASTER TABLE" This is > where the index is stored I assume? > No, the index is stored in a separate Btree. The master table simply stores the page number of that btree's root page. With that information SQLite can read and

Re: [sqlite] equality searches and range searches with encrypteddata

2008-08-25 Thread Derek Developer
appologies, "master database" should read "MASTER TABLE" This is where the index is stored I assume? You suggested that each record would NOT be decrypted for a SELECT because the INDEX would handle that work. Since the INDEX is proabably not a MAC hash of the SS# then it would be accessible

Re: [sqlite] equality searches and range searches with encrypteddata

2008-08-25 Thread Igor Tandetnik
Derek Developer <[EMAIL PROTECTED]> wrote: > So if the data is indexed prior to the encryption step, does SQLite > manage that index internally as a Btree that s stored somewhere? Is > it part of the MASTER database? I'm not sure what you mean by "MASTER database" (as opposed to which other

Re: [sqlite] equality searches and range searches with encrypteddata

2008-08-25 Thread Derek Developer
Thanks Igor, So if the data is indexed prior to the encryption step, does SQLite manage that index internally as a Btree that s stored somewhere? Is it part of the MASTER database? Obviously there would be a security issue if the index is accessible as per this:

Re: [sqlite] equality searches and range searches with encrypteddata

2008-08-25 Thread Griggs, Donald
Derek, I'm more "onlooker" than "expert" here, but I think the answers are: 1) Yes, when a full table scan is performed, the entire table data is decrypted. (If you're using a LIMIT clause without an ORDER BY, then perhaps only part is decrypted -- the point being that the same pages are read

Re: [sqlite] equality searches and range searches with encrypteddata

2008-08-25 Thread Igor Tandetnik
Derek Developer <[EMAIL PROTECTED]> wrote: > Thank you for your replys, but I am still not sure I understand how a > Query is executed on (page) encrypted data wihout either indexing the > data prior to encrption, creating a secondary hash column of the data > or simply decrypting every page to