[
https://issues.apache.org/jira/browse/LUCENE-9379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17354275#comment-17354275
]
Bruno Roustant commented on LUCENE-9379:
----------------------------------------
_RE AES-XTS vs AES-CTR:_
In the case of Lucene, we produce read-only files per index segment. And if we
have a new random IV per file, we don't repeat the same (AES encrypted) blocks.
So we are in a safe read-only-once case where AES-XTS and AES-CTR have the same
strength [1][2]. Given that CTR is simpler, that's why I chose it for this
patch.
[1]
https://crypto.stackexchange.com/questions/64556/aes-xts-vs-aes-ctr-for-write-once-storage
[2]
https://crypto.stackexchange.com/questions/14628/why-do-we-use-xts-over-ctr-for-disk-encryption
> 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: 2.5h
> Remaining Estimate: 0h
>
> +Important+: This Lucene Directory wrapper approach is to be considered only
> if an OS level encryption is not possible. OS level encryption better fits
> Lucene usage of OS cache, and thus is more performant.
> But there are some use-case where OS level encryption is not possible. This
> Jira issue was created to address those.
> ____________________________________________
>
> 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: [email protected]
For additional commands, e-mail: [email protected]
