[jira] [Commented] (LUCENE-6966) Contribution: Codec for index-level encryption
[
https://issues.apache.org/jira/browse/LUCENE-6966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15202629#comment-15202629
]
Karl Sanders commented on LUCENE-6966:
--
{quote}Rather than implement a one-size-fits-all solution then, perhaps it
would be better not to enforce any one cipher and instead leave some
flexibility for users to choose the cipher they find more appropriate.{quote}
I think this is extremely reasonable.
I would like to ask if this patch will also provide "FSDirectory-level
encryption" like
[LUCENE-2228|https://issues.apache.org/jira/browse/LUCENE-2228].
> Contribution: Codec for index-level encryption
> --
>
> Key: LUCENE-6966
> URL: https://issues.apache.org/jira/browse/LUCENE-6966
> Project: Lucene - Core
> Issue Type: New Feature
> Components: modules/other
>Reporter: Renaud Delbru
> Labels: codec, contrib
>
> We would like to contribute a codec that enables the encryption of sensitive
> data in the index that has been developed as part of an engagement with a
> customer. We think that this could be of interest for the community.
> Below is a description of the project.
> h1. Introduction
> In comparison with approaches where all data is encrypted (e.g., file system
> encryption, index output / directory encryption), encryption at a codec level
> enables more fine-grained control on which block of data is encrypted. This
> is more efficient since less data has to be encrypted. This also gives more
> flexibility such as the ability to select which field to encrypt.
> Some of the requirements for this project were:
> * The performance impact of the encryption should be reasonable.
> * The user can choose which field to encrypt.
> * Key management: During the life cycle of the index, the user can provide a
> new version of his encryption key. Multiple key versions should co-exist in
> one index.
> h1. What is supported ?
> - Block tree terms index and dictionary
> - Compressed stored fields format
> - Compressed term vectors format
> - Doc values format (prototype based on an encrypted index output) - this
> will be submitted as a separated patch
> - Index upgrader: command to upgrade all the index segments with the latest
> key version available.
> h1. How it is implemented ?
> h2. Key Management
> One index segment is encrypted with a single key version. An index can have
> multiple segments, each one encrypted using a different key version. The key
> version for a segment is stored in the segment info.
> The provided codec is abstract, and a subclass is responsible in providing an
> implementation of the cipher factory. The cipher factory is responsible of
> the creation of a cipher instance based on a given key version.
> h2. Encryption Model
> The encryption model is based on AES/CBC with padding. Initialisation vector
> (IV) is reused for performance reason, but only on a per format and per
> segment basis.
> While IV reuse is usually considered a bad practice, the CBC mode is somehow
> resilient to IV reuse. The only "leak" of information that this could lead to
> is being able to know that two encrypted blocks of data starts with the same
> prefix. However, it is unlikely that two data blocks in an index segment will
> start with the same data:
> - Stored Fields Format: Each encrypted data block is a compressed block
> (~4kb) of one or more documents. It is unlikely that two compressed blocks
> start with the same data prefix.
> - Term Vectors: Each encrypted data block is a compressed block (~4kb) of
> terms and payloads from one or more documents. It is unlikely that two
> compressed blocks start with the same data prefix.
> - Term Dictionary Index: The term dictionary index is encoded and encrypted
> in one single data block.
> - Term Dictionary Data: Each data block of the term dictionary encodes a set
> of suffixes. It is unlikely to have two dictionary data blocks sharing the
> same prefix within the same segment.
> - DocValues: A DocValues file will be composed of multiple encrypted data
> blocks. It is unlikely to have two data blocks sharing the same prefix within
> the same segment (each one will encodes a list of values associated to a
> field).
> To the best of our knowledge, this model should be safe. However, it would be
> good if someone with security expertise in the community could review and
> validate it.
> h1. Performance
> We report here a performance benchmark we did on an early prototype based on
> Lucene 4.x. The benchmark was performed on the Wikipedia dataset where all
> the fields (id, title, body, date) were encrypted. Only the block tree terms
> and compressed stored fields format were tested at that time.
> h2. Indexing
> The indexing throughput slightly decreased and is roughly 15% less than with
> the
[jira] [Commented] (LUCENE-6966) Contribution: Codec for index-level encryption
[ https://issues.apache.org/jira/browse/LUCENE-6966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15192849#comment-15192849 ] Karl Sanders commented on LUCENE-6966: -- There's an apparently abandoned project that might be of interest: https://code.google.com/archive/p/lucenetransform/ It appears to be implementing compression and encryption for Lucene indexes. I also found a couple of related links. - Some considerations about how it's being used in another project: https://github.com/muzima/documentation/wiki/Security-regarding-stored-data-by-using-Lucene - A discussion about ensuring that indexes aren't tampered with: http://permalink.gmane.org/gmane.comp.jakarta.lucene.user/50495 > Contribution: Codec for index-level encryption > -- > > Key: LUCENE-6966 > URL: https://issues.apache.org/jira/browse/LUCENE-6966 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/other >Reporter: Renaud Delbru > Labels: codec, contrib > > We would like to contribute a codec that enables the encryption of sensitive > data in the index that has been developed as part of an engagement with a > customer. We think that this could be of interest for the community. > Below is a description of the project. > h1. Introduction > In comparison with approaches where all data is encrypted (e.g., file system > encryption, index output / directory encryption), encryption at a codec level > enables more fine-grained control on which block of data is encrypted. This > is more efficient since less data has to be encrypted. This also gives more > flexibility such as the ability to select which field to encrypt. > Some of the requirements for this project were: > * The performance impact of the encryption should be reasonable. > * The user can choose which field to encrypt. > * Key management: During the life cycle of the index, the user can provide a > new version of his encryption key. Multiple key versions should co-exist in > one index. > h1. What is supported ? > - Block tree terms index and dictionary > - Compressed stored fields format > - Compressed term vectors format > - Doc values format (prototype based on an encrypted index output) - this > will be submitted as a separated patch > - Index upgrader: command to upgrade all the index segments with the latest > key version available. > h1. How it is implemented ? > h2. Key Management > One index segment is encrypted with a single key version. An index can have > multiple segments, each one encrypted using a different key version. The key > version for a segment is stored in the segment info. > The provided codec is abstract, and a subclass is responsible in providing an > implementation of the cipher factory. The cipher factory is responsible of > the creation of a cipher instance based on a given key version. > h2. Encryption Model > The encryption model is based on AES/CBC with padding. Initialisation vector > (IV) is reused for performance reason, but only on a per format and per > segment basis. > While IV reuse is usually considered a bad practice, the CBC mode is somehow > resilient to IV reuse. The only "leak" of information that this could lead to > is being able to know that two encrypted blocks of data starts with the same > prefix. However, it is unlikely that two data blocks in an index segment will > start with the same data: > - Stored Fields Format: Each encrypted data block is a compressed block > (~4kb) of one or more documents. It is unlikely that two compressed blocks > start with the same data prefix. > - Term Vectors: Each encrypted data block is a compressed block (~4kb) of > terms and payloads from one or more documents. It is unlikely that two > compressed blocks start with the same data prefix. > - Term Dictionary Index: The term dictionary index is encoded and encrypted > in one single data block. > - Term Dictionary Data: Each data block of the term dictionary encodes a set > of suffixes. It is unlikely to have two dictionary data blocks sharing the > same prefix within the same segment. > - DocValues: A DocValues file will be composed of multiple encrypted data > blocks. It is unlikely to have two data blocks sharing the same prefix within > the same segment (each one will encodes a list of values associated to a > field). > To the best of our knowledge, this model should be safe. However, it would be > good if someone with security expertise in the community could review and > validate it. > h1. Performance > We report here a performance benchmark we did on an early prototype based on > Lucene 4.x. The benchmark was performed on the Wikipedia dataset where all > the fields (id, title, body, date) were encrypted. Only the block tree terms > and compressed stored fields format were tested at that
[jira] [Commented] (LUCENE-6966) Contribution: Codec for index-level encryption
[ https://issues.apache.org/jira/browse/LUCENE-6966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15189316#comment-15189316 ] Karl Sanders commented on LUCENE-6966: -- I would like to let you know that I made the H2 and HSQLDB communities aware about this interest in providing a secure backend for Lucene. H2's author, Thomas Mueller, has already been so kind as to provide his feedback. Both these databases provide encryption at the file level. In both cases I mentioned the possibility to use the database as an encrypted storage for Lucene data. Or even to go as far to add (or improve, in the case of H2) Lucene integration. Maybe some of the companies interested in adding this capability to Lucene might want to reach out to them too, showing that there's the concrete possibility for a partnership or to simply do some contract work. I sincerely hope that Lucene file-level encryption can become a reality. > Contribution: Codec for index-level encryption > -- > > Key: LUCENE-6966 > URL: https://issues.apache.org/jira/browse/LUCENE-6966 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/other >Reporter: Renaud Delbru > Labels: codec, contrib > > We would like to contribute a codec that enables the encryption of sensitive > data in the index that has been developed as part of an engagement with a > customer. We think that this could be of interest for the community. > Below is a description of the project. > h1. Introduction > In comparison with approaches where all data is encrypted (e.g., file system > encryption, index output / directory encryption), encryption at a codec level > enables more fine-grained control on which block of data is encrypted. This > is more efficient since less data has to be encrypted. This also gives more > flexibility such as the ability to select which field to encrypt. > Some of the requirements for this project were: > * The performance impact of the encryption should be reasonable. > * The user can choose which field to encrypt. > * Key management: During the life cycle of the index, the user can provide a > new version of his encryption key. Multiple key versions should co-exist in > one index. > h1. What is supported ? > - Block tree terms index and dictionary > - Compressed stored fields format > - Compressed term vectors format > - Doc values format (prototype based on an encrypted index output) - this > will be submitted as a separated patch > - Index upgrader: command to upgrade all the index segments with the latest > key version available. > h1. How it is implemented ? > h2. Key Management > One index segment is encrypted with a single key version. An index can have > multiple segments, each one encrypted using a different key version. The key > version for a segment is stored in the segment info. > The provided codec is abstract, and a subclass is responsible in providing an > implementation of the cipher factory. The cipher factory is responsible of > the creation of a cipher instance based on a given key version. > h2. Encryption Model > The encryption model is based on AES/CBC with padding. Initialisation vector > (IV) is reused for performance reason, but only on a per format and per > segment basis. > While IV reuse is usually considered a bad practice, the CBC mode is somehow > resilient to IV reuse. The only "leak" of information that this could lead to > is being able to know that two encrypted blocks of data starts with the same > prefix. However, it is unlikely that two data blocks in an index segment will > start with the same data: > - Stored Fields Format: Each encrypted data block is a compressed block > (~4kb) of one or more documents. It is unlikely that two compressed blocks > start with the same data prefix. > - Term Vectors: Each encrypted data block is a compressed block (~4kb) of > terms and payloads from one or more documents. It is unlikely that two > compressed blocks start with the same data prefix. > - Term Dictionary Index: The term dictionary index is encoded and encrypted > in one single data block. > - Term Dictionary Data: Each data block of the term dictionary encodes a set > of suffixes. It is unlikely to have two dictionary data blocks sharing the > same prefix within the same segment. > - DocValues: A DocValues file will be composed of multiple encrypted data > blocks. It is unlikely to have two data blocks sharing the same prefix within > the same segment (each one will encodes a list of values associated to a > field). > To the best of our knowledge, this model should be safe. However, it would be > good if someone with security expertise in the community could review and > validate it. > h1. Performance > We report here a performance benchmark we did on an early prototype
