I think you misunderstood. If you do not have encrypted swap (like
OSX provides for) then you encryption is pointless as anyone can
inspect the data as it it loaded into the heap by lucene - bypassing
the encryption.
I also think you underestimated the impact on the size of the
indexes, as most secure encryption schemes are going to pad the
payloads to a minimum of 128 bits, and usually much more.
This is going to make a HUGE difference in the size of the index.
On Dec 1, 2006, at 2:00 PM, negrinv wrote:
Good news for OSX users! but what about all the others, should I
say the
majority??
One more reason for encrypting at field level.
Victor
Robert Engels wrote:
Not if running under OSX with encrypted swap turned on ! :)
-----Original Message-----
From: Nicolas Lalev�e <[EMAIL PROTECTED]>
Sent: Dec 1, 2006 4:49 AM
To: java-dev@lucene.apache.org
Subject: Re: Attached proposed modifications to Lucene 2.0 to
support
Field.Store.Encrypted
Le Vendredi 1 D�cembre 2006 11:10, negrinv a �crit�:
Nicolas Lalev�e-2 wrote:
Le Vendredi 1 D�cembre 2006 01:33, negrinv a �crit :
Thank you Robert for your commnets. I am inclined to agree
with you,
but
I
would like to establish first of all if simplicity of
implementation
is
the
overriding consideration. But before I dwell on that let me
say that
i
have
discovered that I am not a master of DIFF file creation with
Eclipse.
The diff file attachement to my original posting is absurdly
large
and
not correct. I have therefore attached a zip file containing the
complete source code of the classes I modified. I leave it to
others
to
extract the
diffs properly.
Back to the issue. So far the implementation has not been
difficult
considering that I knew nothing about Lucene internals before I
started.
The reason is that Lucene is very well structured and the changes
just
fitted nicely by adding some code in the right place with minimal
changes to the existing code. But I admit that the proposed
implementation so far is not complete and more work is
required to
overcome some of its restrictions. While I like your idea I
believe
that
it imposed too large a
granularity on the encrypted data, all fields will all kinds
of data
will be encrypted including images and others which normally
would
be
left alone, thus adding to the performance penalty due to
encryption.
I don't agree with you here. In Lucene, you will encrypt the field
data,
the
field names, and the tokens : I would say that is represents at
least
2/3
of
the index size. Then, with the implementation you suggest, I think
(sorry
I
didn't took time to see you patch) that every time a lucene
data need
to
be
read, it is decrypted each time. With an encrypted FS, your kernel
will
maintain a cache in RAM for you, so it won't hurt so much.
It needs some bench to see what is effectively the best, but I
have
doubt
that
your solution will be faster.
Nicolas.
Nicolas, I am all in favour of some tests to establish which
solution is
best, but I have to say that I don't believe file system or
directory
encryption in Lucene is really justified. Most operating system
already
provide this feature, although they are system-wide or policy-based
solution, hence not always within individual user control.
But if the issue is user control, then I believe Lucene should
provide
maximum granularity when it comes to choice of data to encrypt.
The issue I believe is whether some form of encryption should be
provided
within Lucene to enable application developers to create
applications
which
offer some data protection under user control, with a minimum of
impact,
where by impact I mean both on peformance and workload either in
Lucene
code or user code.
In fact you mean a user that has no control of it's machine, and
that
cannot
encrypt his partition. Here you will have the issue with the
swap : Lucene
will decrypt the data in RAM, that can possibly pushed on the
swap... I
know
this is extreme, but it's a security hole.
--
Nicolas LALEV�E
Solutions & Technologies
ANYWARE TECHNOLOGIES
Tel : +33 (0)5 61 00 52 90
Fax : +33 (0)5 61 00 51 46
http://www.anyware-tech.com
--------------------------------------------------------------------
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context: http://www.nabble.com/Attached-
proposed-modifications-to-Lucene-2.0-to-support-
Field.Store.Encrypted-tf2727614.html#a7645198
Sent from the Lucene - Java Developer mailing list archive at
Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
