[ 
https://issues.apache.org/jira/browse/LUCENE-9379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17143886#comment-17143886
 ] 

Bruno Roustant commented on LUCENE-9379:
----------------------------------------

First PR, functional but incomplete. The idea of using a pool of Cipher does 
not work in Lucene.

To run the tests, two options:

test -Dtests.codec=Encrypting
It executes the tests with the EncryptingCodec in test-framework. Currently it 
encrypts a delegate PostingsFormat. This option shows how to provide the 
encryption key depending on the SegmentInfo.

test 
-Dtests.directory=org.apache.lucene.codecs.encrypting.SimpleEncryptingDirectory
It executes the tests with the SimpleEncryptingDirectory in test-framework. 
This option is the simplest; it shows how to provide the encryption key as a 
constant (could be a property) or only depending on the name of the file to 
encrypt (no SegmentInfo).

 

There is a performance issue because of too many new Ciphers when slicing 
IndexInput.
javax.crypto.Cipher is heavy weight to create and is stateful. I tried a 
CipherPool, but actually there are many cases where we need to get lots of 
slices of the IndexInput so we have to create lots of new stateful Cipher. The 
pool turns out to be a no-go, there are too many Cipher in it.

TODO:
 * find a lighter alternative to Cipher if it exists.
 * fix a couple of tests still failing because of unclosed IndexOutput.

> Directory based approach for index encryption
> ---------------------------------------------
>
>                 Key: LUCENE-9379
>                 URL: https://issues.apache.org/jira/browse/LUCENE-9379
>             Project: Lucene - Core
>          Issue Type: New Feature
>            Reporter: Bruno Roustant
>            Assignee: Bruno Roustant
>            Priority: Major
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> The goal is to provide optional encryption of the index, with a scope limited 
> to an encryptable Lucene Directory wrapper.
> Encryption is at rest on disk, not in memory.
> This simple approach should fit any Codec as it would be orthogonal, without 
> modifying APIs as much as possible.
> Use a standard encryption method. Limit perf/memory impact as much as 
> possible.
> Determine how callers provide encryption keys. They must not be stored on 
> disk.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

Reply via email to