[
https://issues.apache.org/jira/browse/CASSANDRA-9633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15273091#comment-15273091
]
Blake Eggleston commented on CASSANDRA-9633:
--------------------------------------------
Thanks Jason. Sorry for the delay getting to this.
This is getting there, although there are a few points that can be improved:
* Since sstable chunks don't have any relation to each other (from the
perspective of encryption/decryption), iv values shouldn't be shared between
them. The cipher should be reinitialized with a fresh iv for each chunk. This
should also simplify the patch, since there's a decent amount of logic
supporting attaching ivs to sstables, copying compressors, having separate
encryption and decryption contexts, and so forth.
* Not every cipher mode supports initialization vectors. For instance, trying
to init a cipher using 'AES/ECB/NoPadding' with an iv, even one with 0 length,
will throw an exception. So there needs to be some logic determining if an iv
is required / can be used.
* Enabling encryption on a table silently discards any compression settings on
the table. Making encryption part of the compression path (and sstable
metadata) makes sense as an implementation detail, but the two should be kept
separate from the user's perspective. I know you're creating an lz4 compressor
in the encrypting compressor, but since users can (and do) create their own
ICompressor implementations, the two shouldn't be mutually exclusive.
* I'd like to see some higher level testing of this. Specifically:
** Tests demonstrating the sequence of table creation, insert, flush, and
select working properly.
** Tests demonstrating streaming works properly.
** Tests showing data can't be read if the key is removed.
* The key alias used to encrypt an sstable should be saved with the sstable
metadata, and used when decrypting. Otherwise, I don't see a way to re-encrypt
your data with another key if the existing key is compromised.
Misc nits:
* The ternary conditional logic in CompressedSegmentedFile is getting pretty
intense. Can we move that into a static method?
* The tde comments in cassandra.yaml need to be updated.
> Add ability to encrypt sstables
> -------------------------------
>
> Key: CASSANDRA-9633
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9633
> Project: Cassandra
> Issue Type: New Feature
> Reporter: Jason Brown
> Assignee: Jason Brown
> Labels: encryption, security, sstable
> Fix For: 3.x
>
>
> Add option to allow encrypting of sstables.
> I have a version of this functionality built on cassandra 2.0 that
> piggy-backs on the existing sstable compression functionality and ICompressor
> interface (similar in nature to what DataStax Enterprise does). However, if
> we're adding the feature to the main OSS product, I'm not sure if we want to
> use the pluggable compression framework or if it's worth investigating a
> different path. I think there's a lot of upside in reusing the sstable
> compression scheme, but perhaps add a new component in cqlsh for table
> encryption and a corresponding field in CFMD.
> Encryption configuration in the yaml can use the same mechanism as
> CASSANDRA-6018 (which is currently pending internal review).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
