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
>
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
> and easy to read.
>
This quote is from O'Reilly's Learning P
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 imple
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
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 level
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 the
>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 r
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, and/or
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
> be
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 decry
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 fro
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 data
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:
http://blogs.msdn.com/lcris/ar
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 and
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 get
15 matches
Mail list logo
