[
https://issues.apache.org/jira/browse/LUCENE-9379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17149691#comment-17149691
]
Bruno Roustant commented on LUCENE-9379:
----------------------------------------
I updated the PR. Now it is functional and complete, with javadoc.
There should be no perf issue anymore because I replaced javax.crypto.Cipher by
a much lighter code that is strictly equivalent, encryption/decryption is the
same (tested randomly by 3 different tests).
For reviewers, there are 33 changed files in the PR but only 10 source classes,
the other are for tests. Look for the classes in store package (e.g.
EncryptingDirectory, EncryptingIndexOutput, EncryptingIndexInput) and the new
util.crypto package (e.g. AesCtrEncrypter).
Now all tests pass when enabling the encryption with a test codec or a test
directory.
Next step:
* Run luceneutil benchmark to evaluate the perf impact.
> 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: 1h 40m
> 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
