Re: Encrypted index?

> > bq: I was rather hoping that I could do the encryption and subsequent > decryption at a level below the search itself > I am not sure what "bq" standard for? Aside from the different encryption key per index (or whatever), why > does the client think this is any more secure than an

Re: Encrypted index?

wever, files that are > password protected, aren't, and that's what security experts want - that > even if an attacker stole the machine and has all the passwords and the > time in the world, without the public/private key of the encrypted index, > he won't be able to read it. I'm not justi

Re: Encrypted index?

Thanks very much Jack, I will take a look into those. On 8 September 2015 at 16:21, Jack Krupansky wrote: > Here's an old Lucene issue/patch for an AES encrypted Lucene directory > class that might give you some ideas: >

Re: Encrypted index?

> > I think you could probably add transparent encryption/decryption at the > Lucene level in a custom codec. That probably has implications for > being able to read the older index when it's time to upgrade Lucene, > with a complete reindex being the likely solution. Others will need to >

Re: Encrypted index?

Thanks Walter, that would be a neat solution if we just wanted to store values, but we also want full-text query capabilities. On 5 September 2015 at 17:56, Walter Underwood wrote: > Alternatively, do not store values in the Solr fields. Return a key and > fetch encrypted

Re: Encrypted index?

e passwords and the >> time in the world, without the public/private key of the encrypted index, >> he won't be able to read it. I'm not justifying it, just repeating what I >> was told. Even though I think it's silly - if someone managed to get a hold >> of the machine, the login

Re: Encrypted index?

Here's an old Lucene issue/patch for an AES encrypted Lucene directory class that might give you some ideas: https://issues.apache.org/jira/browse/LUCENE-2228 No idea what happened to it. An even older issue attempting to add encryption for specific fields:

Re: Encrypted index?

> The easiest way to do this is put the index over > an encrypted file system. Encrypting the actual > _tokens_ has a few problems, not the least of > which is that any encryption algorithm worth > its salt is going to make most searching totally > impossible. > I already suggested an encrypted

Re: Encrypted index?

Adam: Yeah, I've seen client requirements that cause me to scratch my head. I suppose, though, some argument can be made that having a separate encrypting key for the index itself that's completely separate from any more widely-known encryption key for a disk is a valid argument. You could even

Re: Encrypted index?

that are password protected, aren't, and that's what security experts want - that even if an attacker stole the machine and has all the passwords and the time in the world, without the public/private key of the encrypted index, he won't be able to read it. I'm not justifying it, just repeating what I was told

Encrypted index?

I wondered if there is any facility already existing in Lucene for encrypting the values stored into the index and still being able to search them? If not, I wondered if anyone could tell me if this is impossible to implement, and if not to point me perhaps in the right direction? I imagine that

Re: Encrypted index?

On 9/5/2015 5:06 AM, Adam Retter wrote: > I wondered if there is any facility already existing in Lucene for > encrypting the values stored into the index and still being able to > search them? > > If not, I wondered if anyone could tell me if this is impossible to > implement, and if not to

Re: Encrypted index?

Alternatively, do not store values in the Solr fields. Return a key and fetch encrypted data from a database or other repository. wunder Walter Underwood wun...@wunderwood.org http://observer.wunderwood.org/ (my blog) On Sep 5, 2015, at 9:40 AM, Erick Erickson wrote:

Re: Encrypted index?

The easiest way to do this is put the index over an encrypted file system. Encrypting the actual _tokens_ has a few problems, not the least of which is that any encryption algorithm worth its salt is going to make most searching totally impossible. Consider run, runner, running and runs with