[
https://issues.apache.org/jira/browse/CASSANDRA-9633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17980040#comment-17980040
]
Jeremiah Jordan commented on CASSANDRA-9633:
--------------------------------------------
One idea that came up in the ML thread for how things could be done in a way
that did not require decrypting data when it was streamed between nodes, or
pre-sharing a common decryption key, would be to use a hierarchical model with
key encrypting keys and data encrypting keys.
An idea for how that could work would be that each node could have a
public/private key pair pkN/skN that are used as key encrypting keys. The
public keys could be exchanged as part of the internode handshake on initial
connection, or on demand during streaming session setup.
On a given node n1, the data encryption key dk1 would be stored beside the
sstable wrapped by being encrypted with n1s key encrypting key pk1.
To access the sstable data n1 would first decrypt dk1 with the private key sk1,
then use dk1 to decrypt the sstable data.
When transmitting data to another node n2 with key encrypting key pair pk2/sk2,
n1 would first decrypt dk1 with sk1 and then re-encrypt dk1 with the n2s pk2.
The now pk2 wrapped dk1 can be sent to n2 along with the dk1 encrypted sstable
data (which does not need to be modified so could even be zero copy streamed).
n2 can use sk2 to unwrap dk1 and then use dk1 to get access to the data in the
sstables.
> Add ability to encrypt sstables
> -------------------------------
>
> Key: CASSANDRA-9633
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9633
> Project: Apache Cassandra
> Issue Type: New Feature
> Components: Legacy/Core
> Reporter: Jason Brown
> Assignee: shylaja kokoori
> Priority: Normal
> Labels: encryption, security, sstable
> Fix For: 5.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
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
