lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hostetter <hossman_luc...@fucit.org>
Subject Re: Attached proposed modifications to Lucene 2.0 to support Field.Store.Encrypted
Date Sat, 02 Dec 2006 02:10:01 GMT

: That is a valid consideration Doron, which brings the discussion back to the
: difference between encrypton and security. I believe that security is an end
: application responsability, not Lucene's. For instance, is it possible to
: write the end application so that those stats are hidden from or
: inaccessible to users?

if you are relying on the application to provide the security (hiding the
stats that can allow you to "guess" at teh encrypted terms) then why no
rely on the application to provide the encryption as well?

you can't claim you don't trust someone and then give them your car
keys...

if the goal is to encrypt both stored fields and indexed term enums in an
index in such a way that a malicious application can't obtain the
orriginal field values or Terms then the Directory itself needs to be
encrypted (use either the lucene definition of Directory, or a filesystem
defition -- either one is fine) ... if you have faith that no malicious
applications will ever have access to your Directory then the Lucene API
layer doesn't need to care wether your data is encrypted or not -- and you
don't need to go to the effort of encrypting the TermEnums either ... let
your trust Indexing code read in the encrypted data, decrypt it, and use
IndexWriter as is, let your trusted Searching code use the IndexSearcher
as is to read plain text info and encrypt the data before returning it to
clients.



-Hoss


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message