[
https://issues.apache.org/jira/browse/CASSANDRA-9633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15284505#comment-15284505
]
Jason Brown commented on CASSANDRA-9633:
----------------------------------------
bq. iv values shouldn't be shared between them
Hmm, I'm kind of on the fence about this one. The extra space on disk doesn't
bother me so much, but reinitializing the cipher on every chunk does. However,
the argument of simplifying the logic is quite compelling, so I'll give this a
shot and see what happens.
bq. Not every cipher mode supports initialization vectors
I'll see if resolving the above also addresses this concern. I'm not a complete
expert on security algorithms, but my understanding is you always want an IV
(and an alg that uses an IV).
bq. Enabling encryption on a table silently discards any compression settings
on the table
Yes, I was trying to reduce the complexity of setting up the encryption, but
you have a point about users using their own compression schemes. Will address
this.
bq. some higher level testing ...
Will do
bq. The key alias used to encrypt an sstable should be saved with the sstable
metadata
It already is saved. It is part of {{CompressionParams.otherOptions}}, which is
written out as part of the header of the CompressionInfo files
Will start cracking on this work.
> 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)
