You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@lucene.apache.org by Rafaela Voiculescu <ra...@gmail.com> on 2013/06/23 15:39:03 UTC
Securing stored data using Lucene
Hi,
My name is Rafaela and I am just starting to work with Lucene for a project
that involves quite a few security aspects.
I am working on an app that aims to manage data by using Lucene on a mobile
device. However, my application will require data to be confidential (users
will need to be logged in and have certain permissions regarding the data).
I am currently trying to find a way to make this possible and still keep
using Lucene without having a very high performance drop-down.
I was searching around and I found the patch from
https://issues.apache.org/jira/browse/LUCENE-2228. Since it seems to be
quite a bit old and the issue is not marked as resolved, I wanted to ask
about the status of this. Is this something that could work for securing
the information? Or is there another better solution already implemented?
I've wrote the same question before to the general@lucene.apache.org but
didn't get any replies there, so I thought that maybe I wrote to the wrong
mailing list. Hope I'm writing to the right one now (please let me know if
not and if I should redirect the mail to another list).
Thanks,
Rafaela
Re: Securing stored data using Lucene
Posted by Erick Erickson <er...@gmail.com>.
Security has at least two parts. First, allowing users access to
specific documents, for which Alon's comments are the "usual"
way to do this in Solr/Lucene.
But the patch you referenced doesn't address this,
it's all about encrypting the data stored on disk. This is useful
for keeping people who can copy the index from reading the
raw format of the stored data, i.e. the fields for which
' stored="true" ' is set. This data is stored verbatim in *.fdt
files with *.fdx files providing pointers into the *.fdt file for
particular documents.
Which are you concerned about? It sounds like the former....
Best
Erick
On Sun, Jun 23, 2013 at 7:02 AM, Alon Muchnick <al...@datonics.com> wrote:
> hi Rafaela,
>
> one option you can try and look at is to do the below :
>
> 1.add an additional "permissions" field to each of the document you are
> indexing , this field can contain a string representing a specific "user
> id" or a "user group/s" that will have permission to read this document.
> 2.when running a search , on top of the original search query , add a
> filter on the permission field and insert the users id/group , that way the
> search result will only contain documents the user has permissions to .
>
> Alon
>
>
>
> On Sun, Jun 23, 2013 at 4:39 PM, Rafaela Voiculescu <
> rafaela.voiculescu@gmail.com> wrote:
>
>> Hi,
>>
>> My name is Rafaela and I am just starting to work with Lucene for a project
>> that involves quite a few security aspects.
>>
>> I am working on an app that aims to manage data by using Lucene on a mobile
>> device. However, my application will require data to be confidential (users
>> will need to be logged in and have certain permissions regarding the data).
>> I am currently trying to find a way to make this possible and still keep
>> using Lucene without having a very high performance drop-down.
>>
>> I was searching around and I found the patch from
>> https://issues.apache.org/jira/browse/LUCENE-2228. Since it seems to be
>> quite a bit old and the issue is not marked as resolved, I wanted to ask
>> about the status of this. Is this something that could work for securing
>> the information? Or is there another better solution already implemented?
>>
>> I've wrote the same question before to the general@lucene.apache.org but
>> didn't get any replies there, so I thought that maybe I wrote to the wrong
>> mailing list. Hope I'm writing to the right one now (please let me know if
>> not and if I should redirect the mail to another list).
>>
>> Thanks,
>> Rafaela
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
Re: Securing stored data using Lucene
Posted by Alon Muchnick <al...@datonics.com>.
hi Rafaela,
one option you can try and look at is to do the below :
1.add an additional "permissions" field to each of the document you are
indexing , this field can contain a string representing a specific "user
id" or a "user group/s" that will have permission to read this document.
2.when running a search , on top of the original search query , add a
filter on the permission field and insert the users id/group , that way the
search result will only contain documents the user has permissions to .
Alon
On Sun, Jun 23, 2013 at 4:39 PM, Rafaela Voiculescu <
rafaela.voiculescu@gmail.com> wrote:
> Hi,
>
> My name is Rafaela and I am just starting to work with Lucene for a project
> that involves quite a few security aspects.
>
> I am working on an app that aims to manage data by using Lucene on a mobile
> device. However, my application will require data to be confidential (users
> will need to be logged in and have certain permissions regarding the data).
> I am currently trying to find a way to make this possible and still keep
> using Lucene without having a very high performance drop-down.
>
> I was searching around and I found the patch from
> https://issues.apache.org/jira/browse/LUCENE-2228. Since it seems to be
> quite a bit old and the issue is not marked as resolved, I wanted to ask
> about the status of this. Is this something that could work for securing
> the information? Or is there another better solution already implemented?
>
> I've wrote the same question before to the general@lucene.apache.org but
> didn't get any replies there, so I thought that maybe I wrote to the wrong
> mailing list. Hope I'm writing to the right one now (please let me know if
> not and if I should redirect the mail to another list).
>
> Thanks,
> Rafaela
>
Re: Securing stored data using Lucene
Posted by Jack Krupansky <ja...@basetechnology.com>.
Is your device patient data for a single patient or is it for potentially a
large number of patients (on a single device)?
Generally, the proper way to "secure" a Lucene/Solr server and its data is
to keep the server and data behind a firewall and also behind an application
layer so that no outside process can directly talk to Solr. If you are
developing a custom server based only on Lucene, then it is up to you to
assure that your server is secure and Lucene has no role in that security.
Or... are you actually thinking of running Lucene on the device? If so, and
security is a concern, then you are in UNCHARTED TERRITORY and really on
your own.
In that case, you probably need to be talking about custom codecs for
encrypted data for all of your fields. Even then, the in-memory
representation of the field values would be unencrypted and hence insecure
if someone took a stolen device and directly examined the memory.
How much "Rich Lucene Search" do you need to do on the device itself, as
opposed to just looking for "(encrypted) blob storage"? If you want Lucene
to do your searching on field values, the field values will be exposed in
memory. If all you want is to retrieve an encrypted blob based on an
encrypted key, why are you even considering Lucene?
-- Jack Krupansky
-----Original Message-----
From: Rafaela Voiculescu
Sent: Wednesday, June 26, 2013 5:06 AM
To: java-user@lucene.apache.org
Subject: Re: Securing stored data using Lucene
Hello,
Thank you all for your help and the suggestions. They are very useful. I
wanted to clarify more aspects of the project, since I overlooked them in
my previous mails.
To explain the use case exactly, the application should work like this:
- The application works with patient data and that's why we want to keep
things confidential. We are downloading patient data that can go to the
mobile device (it should even work on desktop in a similar way really)
- We have to keep the data in the device due to internet connection
limitation. The device will get, if lucky, internet connection once or
twice per week, hence us needing to keep the patient data locally
- The thing I forgot to mention is that the structure of the patient
data is kept in json format
- Currently, there is no plan for using database because the structure
of the patient stored locally might need to change (so we want to store
the
json as document in Lucene).
- And we need to achieve the part with not having someone who, for
instance steals the device, able to access the data unless they have the
encryption key and mechanism and not having someone who's not supposed to
access the data do that.
This is why we're trying to find a way to encrypt somehow the json
documents and still use Lucene or try not to have the index stored as
plaintext, if it would be possible.
Thank you again for all your help and in case this mail has given more
useful details and there are other suggestions or comments, I would be very
happy to read them.
Have a nice day,
Rafaela
On 25 June 2013 20:59, SUJIT PAL <su...@comcast.net> wrote:
> Hi Rafaela,
>
> I built something along these lines as a proof of concept. All data in the
> index was unstored and only fields which were searchable (tokenized and
> indexed) were kept in the index. The full record was encrypted and stored
> in a MongoDB database. A custom Solr component did the search against the
> index, gathered up unique ids of the results, then pulled out the
> encrypted
> data from MongoDB, decrypted it on the fly and rendered the results.
>
> You can find the (Scala) code here:
> https://github.com/sujitpal/solr4-extras
> (under the src/main/scala/com/mycompany/solr4extras/secure folder).
>
> More information (more or less the same as what I wrote but probably a bit
> more readable with inlined code):
>
> http://sujitpal.blogspot.com/2012/12/searching-encrypted-document-collection.html
>
> There are some obvious data sync concerns with this sort of setup, but as
> Adrian points out, you can't index encrypted data.
>
> HTH
> Sujit
>
> On Jun 25, 2013, at 4:17 AM, Adrien Grand wrote:
>
> > On Tue, Jun 25, 2013 at 1:03 PM, Rafaela Voiculescu
> > <ra...@gmail.com> wrote:
> >> Hello,
> >
> > Hi,
> >
> >> I am sorry I was not a bit more explicit. I am trying to find an
> acceptable
> >> way to encrypt the data to prevent any access of it in any way unless
> the
> >> person who is trying to access it knows how to decrypt it. As I
> mentioned,
> >> I looked a bit through the patch, but I am not sure of its status.
> >
> > You can encrypt stored fields, but there is no way to do it correctly
> > with fields that have positions indexed: attackers could infer the
> > actual terms based on the order of terms (the encrypted version must
> > sort the same way as the original terms), frequencies and positions.
> >
> > --
> > Adrien
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: java-user-help@lucene.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-user-help@lucene.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
Re: Securing stored data using Lucene
Posted by Rafaela Voiculescu <ra...@gmail.com>.
Hi,
Thank you very much for the suggestion. Indeed lucene transform seems to be
something that could meet the requirements for the project.
Thank you all for your help and fast answers.
Rafaela
On 4 July 2013 08:52, VIGNESH S <vi...@gmail.com> wrote:
> Hi Rafaela,
>
> Look at Lucene Transform.It might help to encrypt lucene documents.
>
> https://code.google.com/p/lucenetransform/
>
>
> On Wed, Jun 26, 2013 at 2:36 PM, Rafaela Voiculescu <
> rafaela.voiculescu@gmail.com> wrote:
>
> > Hello,
> >
> > Thank you all for your help and the suggestions. They are very useful. I
> > wanted to clarify more aspects of the project, since I overlooked them in
> > my previous mails.
> >
> > To explain the use case exactly, the application should work like this:
> >
> > - The application works with patient data and that's why we want to
> keep
> > things confidential. We are downloading patient data that can go to
> the
> > mobile device (it should even work on desktop in a similar way really)
> > - We have to keep the data in the device due to internet connection
> > limitation. The device will get, if lucky, internet connection once or
> > twice per week, hence us needing to keep the patient data locally
> > - The thing I forgot to mention is that the structure of the patient
> > data is kept in json format
> > - Currently, there is no plan for using database because the structure
> > of the patient stored locally might need to change (so we want to
> store
> > the
> > json as document in Lucene).
> > - And we need to achieve the part with not having someone who, for
> > instance steals the device, able to access the data unless they have
> the
> > encryption key and mechanism and not having someone who's not supposed
> > to
> > access the data do that.
> >
> > This is why we're trying to find a way to encrypt somehow the json
> > documents and still use Lucene or try not to have the index stored as
> > plaintext, if it would be possible.
> >
> > Thank you again for all your help and in case this mail has given more
> > useful details and there are other suggestions or comments, I would be
> very
> > happy to read them.
> >
> > Have a nice day,
> > Rafaela
> >
> >
> > On 25 June 2013 20:59, SUJIT PAL <su...@comcast.net> wrote:
> >
> > > Hi Rafaela,
> > >
> > > I built something along these lines as a proof of concept. All data in
> > the
> > > index was unstored and only fields which were searchable (tokenized and
> > > indexed) were kept in the index. The full record was encrypted and
> stored
> > > in a MongoDB database. A custom Solr component did the search against
> the
> > > index, gathered up unique ids of the results, then pulled out the
> > encrypted
> > > data from MongoDB, decrypted it on the fly and rendered the results.
> > >
> > > You can find the (Scala) code here:
> > > https://github.com/sujitpal/solr4-extras
> > > (under the src/main/scala/com/mycompany/solr4extras/secure folder).
> > >
> > > More information (more or less the same as what I wrote but probably a
> > bit
> > > more readable with inlined code):
> > >
> > >
> >
> http://sujitpal.blogspot.com/2012/12/searching-encrypted-document-collection.html
> > >
> > > There are some obvious data sync concerns with this sort of setup, but
> as
> > > Adrian points out, you can't index encrypted data.
> > >
> > > HTH
> > > Sujit
> > >
> > > On Jun 25, 2013, at 4:17 AM, Adrien Grand wrote:
> > >
> > > > On Tue, Jun 25, 2013 at 1:03 PM, Rafaela Voiculescu
> > > > <ra...@gmail.com> wrote:
> > > >> Hello,
> > > >
> > > > Hi,
> > > >
> > > >> I am sorry I was not a bit more explicit. I am trying to find an
> > > acceptable
> > > >> way to encrypt the data to prevent any access of it in any way
> unless
> > > the
> > > >> person who is trying to access it knows how to decrypt it. As I
> > > mentioned,
> > > >> I looked a bit through the patch, but I am not sure of its status.
> > > >
> > > > You can encrypt stored fields, but there is no way to do it correctly
> > > > with fields that have positions indexed: attackers could infer the
> > > > actual terms based on the order of terms (the encrypted version must
> > > > sort the same way as the original terms), frequencies and positions.
> > > >
> > > > --
> > > > Adrien
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
> > > > For additional commands, e-mail: java-user-help@lucene.apache.org
> > > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
> > > For additional commands, e-mail: java-user-help@lucene.apache.org
> > >
> > >
> >
>
>
>
> --
> Thanks and Regards
> Vignesh Srinivasan
> 9739135640
>
Re: Securing stored data using Lucene
Posted by VIGNESH S <vi...@gmail.com>.
Hi Rafaela,
Look at Lucene Transform.It might help to encrypt lucene documents.
https://code.google.com/p/lucenetransform/
On Wed, Jun 26, 2013 at 2:36 PM, Rafaela Voiculescu <
rafaela.voiculescu@gmail.com> wrote:
> Hello,
>
> Thank you all for your help and the suggestions. They are very useful. I
> wanted to clarify more aspects of the project, since I overlooked them in
> my previous mails.
>
> To explain the use case exactly, the application should work like this:
>
> - The application works with patient data and that's why we want to keep
> things confidential. We are downloading patient data that can go to the
> mobile device (it should even work on desktop in a similar way really)
> - We have to keep the data in the device due to internet connection
> limitation. The device will get, if lucky, internet connection once or
> twice per week, hence us needing to keep the patient data locally
> - The thing I forgot to mention is that the structure of the patient
> data is kept in json format
> - Currently, there is no plan for using database because the structure
> of the patient stored locally might need to change (so we want to store
> the
> json as document in Lucene).
> - And we need to achieve the part with not having someone who, for
> instance steals the device, able to access the data unless they have the
> encryption key and mechanism and not having someone who's not supposed
> to
> access the data do that.
>
> This is why we're trying to find a way to encrypt somehow the json
> documents and still use Lucene or try not to have the index stored as
> plaintext, if it would be possible.
>
> Thank you again for all your help and in case this mail has given more
> useful details and there are other suggestions or comments, I would be very
> happy to read them.
>
> Have a nice day,
> Rafaela
>
>
> On 25 June 2013 20:59, SUJIT PAL <su...@comcast.net> wrote:
>
> > Hi Rafaela,
> >
> > I built something along these lines as a proof of concept. All data in
> the
> > index was unstored and only fields which were searchable (tokenized and
> > indexed) were kept in the index. The full record was encrypted and stored
> > in a MongoDB database. A custom Solr component did the search against the
> > index, gathered up unique ids of the results, then pulled out the
> encrypted
> > data from MongoDB, decrypted it on the fly and rendered the results.
> >
> > You can find the (Scala) code here:
> > https://github.com/sujitpal/solr4-extras
> > (under the src/main/scala/com/mycompany/solr4extras/secure folder).
> >
> > More information (more or less the same as what I wrote but probably a
> bit
> > more readable with inlined code):
> >
> >
> http://sujitpal.blogspot.com/2012/12/searching-encrypted-document-collection.html
> >
> > There are some obvious data sync concerns with this sort of setup, but as
> > Adrian points out, you can't index encrypted data.
> >
> > HTH
> > Sujit
> >
> > On Jun 25, 2013, at 4:17 AM, Adrien Grand wrote:
> >
> > > On Tue, Jun 25, 2013 at 1:03 PM, Rafaela Voiculescu
> > > <ra...@gmail.com> wrote:
> > >> Hello,
> > >
> > > Hi,
> > >
> > >> I am sorry I was not a bit more explicit. I am trying to find an
> > acceptable
> > >> way to encrypt the data to prevent any access of it in any way unless
> > the
> > >> person who is trying to access it knows how to decrypt it. As I
> > mentioned,
> > >> I looked a bit through the patch, but I am not sure of its status.
> > >
> > > You can encrypt stored fields, but there is no way to do it correctly
> > > with fields that have positions indexed: attackers could infer the
> > > actual terms based on the order of terms (the encrypted version must
> > > sort the same way as the original terms), frequencies and positions.
> > >
> > > --
> > > Adrien
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
> > > For additional commands, e-mail: java-user-help@lucene.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: java-user-help@lucene.apache.org
> >
> >
>
--
Thanks and Regards
Vignesh Srinivasan
9739135640
Re: Securing stored data using Lucene
Posted by Rafaela Voiculescu <ra...@gmail.com>.
Hello,
Thank you all for your help and the suggestions. They are very useful. I
wanted to clarify more aspects of the project, since I overlooked them in
my previous mails.
To explain the use case exactly, the application should work like this:
- The application works with patient data and that's why we want to keep
things confidential. We are downloading patient data that can go to the
mobile device (it should even work on desktop in a similar way really)
- We have to keep the data in the device due to internet connection
limitation. The device will get, if lucky, internet connection once or
twice per week, hence us needing to keep the patient data locally
- The thing I forgot to mention is that the structure of the patient
data is kept in json format
- Currently, there is no plan for using database because the structure
of the patient stored locally might need to change (so we want to store the
json as document in Lucene).
- And we need to achieve the part with not having someone who, for
instance steals the device, able to access the data unless they have the
encryption key and mechanism and not having someone who's not supposed to
access the data do that.
This is why we're trying to find a way to encrypt somehow the json
documents and still use Lucene or try not to have the index stored as
plaintext, if it would be possible.
Thank you again for all your help and in case this mail has given more
useful details and there are other suggestions or comments, I would be very
happy to read them.
Have a nice day,
Rafaela
On 25 June 2013 20:59, SUJIT PAL <su...@comcast.net> wrote:
> Hi Rafaela,
>
> I built something along these lines as a proof of concept. All data in the
> index was unstored and only fields which were searchable (tokenized and
> indexed) were kept in the index. The full record was encrypted and stored
> in a MongoDB database. A custom Solr component did the search against the
> index, gathered up unique ids of the results, then pulled out the encrypted
> data from MongoDB, decrypted it on the fly and rendered the results.
>
> You can find the (Scala) code here:
> https://github.com/sujitpal/solr4-extras
> (under the src/main/scala/com/mycompany/solr4extras/secure folder).
>
> More information (more or less the same as what I wrote but probably a bit
> more readable with inlined code):
>
> http://sujitpal.blogspot.com/2012/12/searching-encrypted-document-collection.html
>
> There are some obvious data sync concerns with this sort of setup, but as
> Adrian points out, you can't index encrypted data.
>
> HTH
> Sujit
>
> On Jun 25, 2013, at 4:17 AM, Adrien Grand wrote:
>
> > On Tue, Jun 25, 2013 at 1:03 PM, Rafaela Voiculescu
> > <ra...@gmail.com> wrote:
> >> Hello,
> >
> > Hi,
> >
> >> I am sorry I was not a bit more explicit. I am trying to find an
> acceptable
> >> way to encrypt the data to prevent any access of it in any way unless
> the
> >> person who is trying to access it knows how to decrypt it. As I
> mentioned,
> >> I looked a bit through the patch, but I am not sure of its status.
> >
> > You can encrypt stored fields, but there is no way to do it correctly
> > with fields that have positions indexed: attackers could infer the
> > actual terms based on the order of terms (the encrypted version must
> > sort the same way as the original terms), frequencies and positions.
> >
> > --
> > Adrien
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: java-user-help@lucene.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-user-help@lucene.apache.org
>
>
Re: Securing stored data using Lucene
Posted by SUJIT PAL <su...@comcast.net>.
Hi Rafaela,
I built something along these lines as a proof of concept. All data in the index was unstored and only fields which were searchable (tokenized and indexed) were kept in the index. The full record was encrypted and stored in a MongoDB database. A custom Solr component did the search against the index, gathered up unique ids of the results, then pulled out the encrypted data from MongoDB, decrypted it on the fly and rendered the results.
You can find the (Scala) code here:
https://github.com/sujitpal/solr4-extras
(under the src/main/scala/com/mycompany/solr4extras/secure folder).
More information (more or less the same as what I wrote but probably a bit more readable with inlined code):
http://sujitpal.blogspot.com/2012/12/searching-encrypted-document-collection.html
There are some obvious data sync concerns with this sort of setup, but as Adrian points out, you can't index encrypted data.
HTH
Sujit
On Jun 25, 2013, at 4:17 AM, Adrien Grand wrote:
> On Tue, Jun 25, 2013 at 1:03 PM, Rafaela Voiculescu
> <ra...@gmail.com> wrote:
>> Hello,
>
> Hi,
>
>> I am sorry I was not a bit more explicit. I am trying to find an acceptable
>> way to encrypt the data to prevent any access of it in any way unless the
>> person who is trying to access it knows how to decrypt it. As I mentioned,
>> I looked a bit through the patch, but I am not sure of its status.
>
> You can encrypt stored fields, but there is no way to do it correctly
> with fields that have positions indexed: attackers could infer the
> actual terms based on the order of terms (the encrypted version must
> sort the same way as the original terms), frequencies and positions.
>
> --
> Adrien
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-user-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
Re: Securing stored data using Lucene
Posted by Adrien Grand <jp...@gmail.com>.
On Tue, Jun 25, 2013 at 1:03 PM, Rafaela Voiculescu
<ra...@gmail.com> wrote:
> Hello,
Hi,
> I am sorry I was not a bit more explicit. I am trying to find an acceptable
> way to encrypt the data to prevent any access of it in any way unless the
> person who is trying to access it knows how to decrypt it. As I mentioned,
> I looked a bit through the patch, but I am not sure of its status.
You can encrypt stored fields, but there is no way to do it correctly
with fields that have positions indexed: attackers could infer the
actual terms based on the order of terms (the encrypted version must
sort the same way as the original terms), frequencies and positions.
--
Adrien
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
Re: Securing stored data using Lucene
Posted by Rafaela Voiculescu <ra...@gmail.com>.
Hello,
Thank you for the answers.
I am sorry I was not a bit more explicit. I am trying to find an acceptable
way to encrypt the data to prevent any access of it in any way unless the
person who is trying to access it knows how to decrypt it. As I mentioned,
I looked a bit through the patch, but I am not sure of its status.
Also, in case someone has experimented with this previously, I am very
interested in the approach and results as far as performance goes when
using encryption/decryption additional to Lucene.
Thank you very much for the help,
Rafaela