Hi Avarinth,
There is an open issue to encrypt index files using AES, don't know if
that would fit your requirements:
https://issues.apache.org/jira/browse/LUCENE-2228
Regards,
András
On Tue, Feb 6, 2018 at 8:32 AM, Michael Wilkowski wrote:
> Hi,
> sorry to say that, but your encryp
Hi,
sorry to say that, but your encryption is not secure at all. Actually it is
very weak. Since you encrypt tokens only (and apply padding) then it is
very easy based on the examples above to actually reverse engineer your
text. If somebody understands the domain, has text distribution and may
Kindly post your suggestions.
On Mon, Dec 4, 2017 at 11:27 PM, aravinth thangasami <
aravinththangas...@gmail.com> wrote:
> Hi all,
>
> To support Encryption at Rest, We have written a custom analyzer, that
> encrypts every token in the Input string and proceeds to the defaul
Hi all,
To support Encryption at Rest, We have written a custom analyzer, that
encrypts every token in the Input string and proceeds to the default
indexing chain
We are using AES/CTR/NoPadding with unique Key Per User.
This helps that the input string with common prefix, the encrypted strings
I got it Erick.. Thank you..
-
Kumaran R
On Fri, Aug 11, 2017 at 10:35 PM, Erick Erickson
wrote:
> Encrypting the _tokens_ inevitably leads to reduced capabilities BTW.
> Trivial example:
> I have these tokens in my index
> run
> runner
> running
> runs
>
>
Encrypting the _tokens_ inevitably leads to reduced capabilities BTW.
Trivial example:
I have these tokens in my index
run
runner
running
runs
Any non-trivial encryption algorithm will not encrypt the first three
letters "run" identically in all three so searching for run* simply
won&#
Hi Ishan, thank you :-)
-
-
Kumaran R
On Mon, Aug 7, 2017 at 10:53 PM, Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:
> Harry Ochiai (Hitachi) has some index encryption solution,
> https://www.slideshare.net/maggon/securing-solr-search-data-in-the-cloud
> I think it
Harry Ochiai (Hitachi) has some index encryption solution,
https://www.slideshare.net/maggon/securing-solr-search-data-in-the-cloud
I think it is proprietary, but I'm not sure. Maybe more googling might help
find the exact page where his solution is described.
On Mon, Aug 7, 2017 at 9:
On Mon, Aug 7, 2017 at 9:52 PM, Erick Erickson
wrote:
> No, since you haven't defined what you want to encrypt, what your
> requirements are, what you hope to get out of "encryption" etc.
>
> Put the index on an encrypting filesystem and forget about it if you
> possi
No, since you haven't defined what you want to encrypt, what your
requirements are, what you hope to get out of "encryption" etc.
Put the index on an encrypting filesystem and forget about it if you
possibly can, because anything else is a significant amount of work.
To encrypt
Hi Erick,
Thanks for the information. Any pointers about encryption options in
solr?
--
Kumaran R
On Mon, Aug 7, 2017 at 9:17 PM, Erick Erickson
wrote:
> Encryption in Solr has a bunch of ramifications. Do you care about
>
> - encryption at rest or in memory?
> - en
Encryption in Solr has a bunch of ramifications. Do you care about
- encryption at rest or in memory?
- encrypting the _searchable_ tokens?
- encrypting the searchable tokens per-user?
- encrypting the stored data (which a filter won't do BTW).
It's actually a fairly complex topic the
Hi All,
After looking at all below discussions, i have one doubt which may be silly
or novice but i want to throw this to lucene user list.
if we have encryption layer included in our analyzer's flow of filters like
EncryptionFilter to control field-level encryption. what are the
consequ
You can do it.
Choose reasonable alogrith.
Analyzer written by self is needed also.
--
View this message in context:
http://lucene.472066.n3.nabble.com/Encryption-tp539373p4133687.html
Sent from the Lucene - Java Users mailing list archive at Nabble.com
You might try searching JIRA, I believe there is an issue in there that
attempts to provide an encrypted Directory implementation. You might also
just use file system encryption.
On Aug 12, 2011, at 8:09 PM, Chris Zakian wrote:
> Hey, thanks for your reply Shaneal,
>
> I do have a
ndexes so that
> > unauthorized people don't have access to them by bypassing the system's
> > database security. I was wondering if anyone had a) implemented a
> security
> > measure that encrypts the indexes or b) if I were to write my own
> > encryption, what
that
> unauthorized people don't have access to them by bypassing the system's
> database security. I was wondering if anyone had a) implemented a security
> measure that encrypts the indexes or b) if I were to write my own
> encryption, what classes actually handle all the I
a security
measure that encrypts the indexes or b) if I were to write my own
encryption, what classes actually handle all the IO to and from the indexes.
In praticular, where would I get the Input/Output Streams in order to
encrypt them.
Thanks,
Chris.
GSOC intern with OpenMRS
On Mon, May 11, 2009 at 2:06 PM, Babak Farhang wrote:
> I am not familiar with the details of CFS, but I didn't interpret
> Michael's comment to mean that there is actually any rewriting going
> on here. The problem here appears to be one of translating the
> encrypted/compressed file position to
On Mon, May 11, 2009 at 12:19 AM, Andrzej Bialecki wrote:
>
> Unfortunately, current Lucene IndexWriter implementation uses seek /
> overwrite when writing term info dictionary. This is described in more
> detail here:
>
> https://issues.apache.org/jira/browse/LUCENE-532
>
Thanks for the enlight
Babak Farhang wrote:
If "position" is the only thing Lucene needs during writing, then that
is good news: seeking backwards and overwriting what's already
written--that would be difficult to implement. If Lucene employs a
write once strategy for file I/O (w/ no exceptions), then we wont
really
Seems to me this discussion is not necessarily limited to
*encryption*: if you can implement encryption, you can also implement
compression--which is perhaps interesting for archiving purposes (at
access time, faster than unzipping an entire archived Directory and
loading it, for example
whether it is from the Lucene index, or the
original source like and SQL table or a decrypted PDF file.
However, if the file or the computer is stolen, an encrypted index would
be useless because of the encryption would presumably match that of the
original source.
Other system tools outside of the
ttle tougher, but not impossible.
>> I was searching last night and there have been a couple of papers
>> written on the topic of Encrypted Random Access files at MIT.
>>
>> I haven't finished reading all of them yet, but they suggest ways of
>> solving the Encrypt
it
up.
This makes the project a little tougher, but not impossible.
I was searching last night and there have been a couple of papers
written on the topic of Encrypted Random Access files at MIT.
I haven't finished reading all of them yet, but they suggest ways of
solving the Encryption
ic of Encrypted Random Access files at MIT.
I haven't finished reading all of them yet, but they suggest ways of
solving the Encryption problems for Random Access Files.
http://groups.csail.mit.edu/cis/theses/fu-masters.pdf
I am going to spend a few day looking at the various papers before I
ic of Encrypted Random Access files at MIT.
I haven't finished reading all of them yet, but they suggest ways of
solving the Encryption problems for Random Access Files.
http://groups.csail.mit.edu/cis/theses/fu-masters.pdf
I am going to spend a few day looking at the various papers before I
waste
> Lucene needs to be able to ask a RAF opened for writing what it's
> current "position" is during indexing, which it then stores away, and
> later during searching it needs to ask a RAF opened for reading to
> seek back to that position so it can read bytes from the
Would you encrypt at the file level? Ie, the encryption would live
"under" a RandomAccessFile (RAF) and otherwise feel "normal" to
Lucene?
(I think I remember others exploring encryption at the individual term
level, which is interesting but does leak information in that yo
hat ask a question about
> Lucene Index Encryption. In both cases, I think that the conservation
> was dropped or the feature put off.
>
> Basically, I am asking for comments on the topic. I might consider
> coding the feature, but I would only do it if I am sure that the feature
>
Index Encryption. In both cases, I think that the conservation
was dropped or the feature put off.
Basically, I am asking for comments on the topic. I might consider
coding the feature, but I would only do it if I am sure that the feature
would be useful and accepted back into the core codebase of
Washington [mailto:[EMAIL PROTECTED]
Sent: 7 May, 2006 03:38
To: java-user@lucene.apache.org
Subject: Re: Encryption
Thank you all for your replies (and Otis and John for your lively sense
of humour as well).
I obviously accept the need to encrypt the index, but am not sure that
using the Windows (or
Thank you all for your replies (and Otis and John for your lively sense of
humour as well).
I obviously accept the need to encrypt the index, but am not sure that using
the Windows (or Linux) file system encryption will solve the problem. My
understanding is that both cannot be under my
On Sat, May 06, 2006 at 01:16:43AM +, George Washington wrote:
> I am using Lucene to index as well as to store complete source documents
> (typically few tens of thousands of documents, not millions). I would like
> to protect the source documents with encryption but have the
George Washington wrote:
Is it possible to reconstruct a complete source document from the data
stored in the index, even if the fields are only indexed but not
stored? Because if the answer is "yes" there is no point in
encrypting, unless the index itself can be encrypted. Is it feasible
to e
On Samstag 06 Mai 2006 03:16, George Washington wrote:
> Is it possible to reconstruct a complete source document from the data
> stored in the index, even if the fields are only indexed but not stored?
Yes, although stopwords etc get lost. You can use Luke's "Reconstruct &
Edit" feature to see
I am using Lucene to index as well as to store complete source documents
(typically few tens of thousands of documents, not millions). I would like
to protect the source documents with encryption but have the following
questions:
Is it possible to reconstruct a complete source document from the
I am using Lucene to index as well as to store complete source documents
(typically few tens of thousands of documents, not millions). I would like
to protect the source documents with encryption but have the following
questions:
Is it possible to reconstruct a complete source document from the
38 matches
Mail list logo
