[jira] [Commented] (CASSANDRA-9633) Add ability to encrypt sstables
[ https://issues.apache.org/jira/browse/CASSANDRA-9633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17444123#comment-17444123 ] Jeremiah Jordan commented on CASSANDRA-9633: Is there a link to the branch you have been working on? Thanks. > Add ability to encrypt sstables > --- > > Key: CASSANDRA-9633 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9633 > Project: Cassandra > Issue Type: New Feature > Components: Legacy/Core >Reporter: Jason Brown >Assignee: shylaja kokoori >Priority: Normal > Labels: encryption, security, sstable > Fix For: 4.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.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-9633) Add ability to encrypt sstables
[ https://issues.apache.org/jira/browse/CASSANDRA-9633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17438744#comment-17438744 ] Stefan Miklosovic commented on CASSANDRA-9633: -- Hey! we are working again on this, big thanks to [~skokoori] who retrofitted / refactored the code from times of 3.x to current trunk (4.x). As of now we are fixing tests which are failing due to this change. I expect to create a CEP for this ticket as there is a lot to discuss and some points are not clear yet. I should deliver that the next week. > Add ability to encrypt sstables > --- > > Key: CASSANDRA-9633 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9633 > Project: Cassandra > Issue Type: New Feature > Components: Legacy/Core >Reporter: Jason Brown >Assignee: shylaja kokoori >Priority: Normal > Labels: encryption, security, sstable > Fix For: 4.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.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-9633) Add ability to encrypt sstables
[ https://issues.apache.org/jira/browse/CASSANDRA-9633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17250665#comment-17250665 ] shylaja kokoori commented on CASSANDRA-9633: Hi All, I have ported Jason Brown's implementation to 4.0. Few related questions, 1) In cassandra.yaml file, for transparent_data_encryption_options, +keystore_password+ and +key_password+ are provided in plain text. Can we rely on Linux file system permission to protect the information? 2) During a read, when data is transferred between a node containing the data and the coordinator node, can we rely on encryption over wire to provide confidentiality? 3) I am not too familiar with streaming. When zero copy streaming is enabled and SSTables are transferred in its entirety, can I assume both the nodes have same keys or should key exchange happen? 4) Our security expert says, no more than 2^56 16 byte blocks (~1 EB) should be encrypted with a single key. Depending on the amount of writes that happen, that is probably several years of data encryption. Should that be a concern? > Add ability to encrypt sstables > --- > > Key: CASSANDRA-9633 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9633 > Project: Cassandra > Issue Type: New Feature > Components: Legacy/Core >Reporter: Jason Brown >Assignee: shylaja kokoori >Priority: Normal > Labels: encryption, security, sstable > Fix For: 4.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.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-9633) Add ability to encrypt sstables
[ https://issues.apache.org/jira/browse/CASSANDRA-9633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16771705#comment-16771705 ] Shaurya Gupta commented on CASSANDRA-9633: -- Hi [~jasobrown] Will this be included in 4.x release? Thanks > Add ability to encrypt sstables > --- > > Key: CASSANDRA-9633 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9633 > Project: Cassandra > Issue Type: New Feature > Components: Legacy/Core >Reporter: Jason Brown >Priority: Major > Labels: encryption, security, sstable > Fix For: 4.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 (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-9633) Add ability to encrypt sstables
[ https://issues.apache.org/jira/browse/CASSANDRA-9633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16632507#comment-16632507 ] Jean Duclair TAGU commented on CASSANDRA-9633: -- Hi Jason Brown, just checking if this feature is included in the 4.0 release currently being tested. Thanks > 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 >Priority: Major > Labels: encryption, security, sstable > Fix For: 4.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 (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-9633) Add ability to encrypt sstables
[ https://issues.apache.org/jira/browse/CASSANDRA-9633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16249126#comment-16249126 ] Hlaing Than commented on CASSANDRA-9633: Hi [~jasobrown], just wondering when you would have time to resume work on this ticket. I'm really looking forward to the feature. I am not familiar with Cassandra code base, but I can help with other aspects (testing, documentation, etc). Thanks. > 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: 4.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.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-9633) Add ability to encrypt sstables
[ https://issues.apache.org/jira/browse/CASSANDRA-9633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16043976#comment-16043976 ] Praveen Agrawal commented on CASSANDRA-9633: Hi Jason. I care about this feature and can contribute. Can you please point to the branch where your current changes are? Thanks. > 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: 4.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.15#6346) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-9633) Add ability to encrypt sstables
[ https://issues.apache.org/jira/browse/CASSANDRA-9633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15930670#comment-15930670 ] Vincenzo Melandri commented on CASSANDRA-9633: -- I see you are approaching "done" on both of those. I will stay tuned. > 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: 4.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.15#6346)
[jira] [Commented] (CASSANDRA-9633) Add ability to encrypt sstables
[ https://issues.apache.org/jira/browse/CASSANDRA-9633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15930445#comment-15930445 ] Jason Brown commented on CASSANDRA-9633: [~vmelandri] It's still on my radar, albeit behind CASSANDRA-8457 & CASSANDRA-12229. I don't have an ETA, but stay tuned ... > 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: 4.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.15#6346)
[jira] [Commented] (CASSANDRA-9633) Add ability to encrypt sstables
[ https://issues.apache.org/jira/browse/CASSANDRA-9633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15930422#comment-15930422 ] Vincenzo Melandri commented on CASSANDRA-9633: -- Hello, just to bump this up. I care about this feature :) Is there any movement here, is this going to be in any next release soon? Or maybe can I pitch in? > 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: 4.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.15#6346)
[jira] [Commented] (CASSANDRA-9633) Add ability to encrypt sstables
[
https://issues.apache.org/jira/browse/CASSANDRA-9633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15696103#comment-15696103
]
Stefan Podkowinski commented on CASSANDRA-9633:
---
I haven't looked specifically into how an external key management system such
as vault could be integrated by implementing {{KeyProvider}}. But your're
right, it could be an option.
What I'm wondering though is if it wouldn't be worth it to implement a two tier
encryption architecture right from the start. To me support for key rotation
and table based encryption would be a key feature that makes Cassandra at-rest
encryption really worthwhile compared to filesystem/block device based
encryption. Therefor my suggestion would be to encrypt sstables using a
intermediate, sstable specific key (derived from a master key) that would be
stored along with the sstable (in an extra component). This would only require
to re-encrypt the associated keys upon key rotation, instead of rewriting all
sstables.
> 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)
[jira] [Commented] (CASSANDRA-9633) Add ability to encrypt sstables
[
https://issues.apache.org/jira/browse/CASSANDRA-9633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15690211#comment-15690211
]
Jason Brown commented on CASSANDRA-9633:
[~spo...@gmail.com] It's already configurable for different key providers.
{{CipherFactory}} create an instance of a {{KeyProvider}}, as configured via
the yaml. The default {{KeyProvider}}, {{JKSKeyProvider}}, reads from a
keystore, but it's pluggable and you could easily add in a Vault provider, as
well.
> 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)
[jira] [Commented] (CASSANDRA-9633) Add ability to encrypt sstables
[ https://issues.apache.org/jira/browse/CASSANDRA-9633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15690122#comment-15690122 ] Stefan Podkowinski commented on CASSANDRA-9633: --- I wonder if it would make sense to use a ParameterizedClass for the cassandra.yaml configuration. The keystore based implementation is a great start, but there could be other ways to do this and maybe we'll have someone contribute say a [Vault|https://www.vaultproject.io] based implementation one day. Being able to configure a different class_name and parameters would make it easier to integrate other solutions. > 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)
[jira] [Commented] (CASSANDRA-9633) Add ability to encrypt sstables
[ https://issues.apache.org/jira/browse/CASSANDRA-9633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15675196#comment-15675196 ] Ben Bromhead commented on CASSANDRA-9633: - ok, sounds great! Thanks for the hard work on this patch :) though If I could put in a minor (very small) request that compression is off by default/user configurable. I wouldn't be comfortable with compression before encryption as it creates another avenue where it is possible to leak information and increase the possibility of a CRIME style attack. I know the accepted wisdom used to be that you should compress before you encrypt, as this is the only way to reduce the size of what you encrypt, but it has since been proven to reduce the security of the chosen encryption scheme. If a user understands the added risk or it is unlikely an attacker would have control over the plain text then they can opt in to using compression. > 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)
[jira] [Commented] (CASSANDRA-9633) Add ability to encrypt sstables
[ https://issues.apache.org/jira/browse/CASSANDRA-9633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15674998#comment-15674998 ] Jason Brown commented on CASSANDRA-9633: bq. There appears to be a bit of a stall on this ticket Yeah, I've been pulled in a couple of different directions lately. TBH, the work here is about 85-90% done, last I remember. I was just testing out a great many things. Adding compression does make the blob passed into encryption smaller, which is why I chose it (also based on previous interactions with security folks). Making it an option is certainly reasonable. Supporting compression is already easy enough - I've already done it ;). bq. Supporting cipher modes that don't use IVs allows I agree with this in general, and for most existing ciphers. However, allowing a variable length IV (per algo/key), plus [~bdeggleston]'s comment "The cipher should be reinitialized with a fresh iv for each chunk" actually made things a lot cleaner, but was a lot of work (which is what I was testing when I got diverted). I'll see if I can scrape together some time in the next week or two to rebase and continue 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)
[jira] [Commented] (CASSANDRA-9633) Add ability to encrypt sstables
[ https://issues.apache.org/jira/browse/CASSANDRA-9633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15674920#comment-15674920 ] Ben Bromhead commented on CASSANDRA-9633: - There appears to be a bit of a stall on this ticket, I'm happy to address / review / help out on any outstanding comments / nits. I've included a few of my initial thoughts on some of the above issues, however I'm still going through the code and testing: bq. Enabling encryption on a table silently discards any compression settings on the table One note on supporting compression with encryption is that it's tricky to do correctly. Performing compression on input that is potentially attacker controlled is generally a big no-no. For an example of why this is not a good idea, check out the CRIME attack against SSL, which leverages using compression influenced size as an oracle https://en.wikipedia.org/wiki/CRIME. I know this is done in DSE, I'm not familiar with the Datastax implementation as these are closed source, however I would be cautious using EncryptingSnappyCompressor et al. On the flip side performing compression after the SSTable has been encrypted tends to not be particularly effective due to apparent increase of entropy in the SSTable after encryption. Due to the above, I would not worry about supporting the ability to encrypt AND compress SSTables in this first release of the feature. bq. Not every cipher mode supports initialization vectors Supporting cipher modes that don't use IVs allows users to shoot themselves in the foot. The example given above of AES/ECB/NoPadding is definitely a cipher mode we don't want to support. See https://blog.filippo.io/the-ecb-penguin/ > 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)
[jira] [Commented] (CASSANDRA-9633) Add ability to encrypt sstables
[
https://issues.apache.org/jira/browse/CASSANDRA-9633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)
[jira] [Commented] (CASSANDRA-9633) Add ability to encrypt sstables
[ https://issues.apache.org/jira/browse/CASSANDRA-9633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)
[jira] [Commented] (CASSANDRA-9633) Add ability to encrypt sstables
[ https://issues.apache.org/jira/browse/CASSANDRA-9633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15248041#comment-15248041 ] Jason Brown commented on CASSANDRA-9633: [~iamaleksey] Please :) > 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)
[jira] [Commented] (CASSANDRA-9633) Add ability to encrypt sstables
[ https://issues.apache.org/jira/browse/CASSANDRA-9633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15247836#comment-15247836 ] Aleksey Yeschenko commented on CASSANDRA-9633: -- Thanks Jason (: Given changes to CQL and schema are involved, I'd like to review at least those before anything gets committed, if you don't mind. > 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)
[jira] [Commented] (CASSANDRA-9633) Add ability to encrypt sstables
[
https://issues.apache.org/jira/browse/CASSANDRA-9633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15247797#comment-15247797
]
Jason Brown commented on CASSANDRA-9633:
OK, so here we go with the updates [~bdeggleston] requested.
||9633||
|[branch|https://github.com/jasobrown/cassandra/tree/9633]|
|[dtest|http://cassci.datastax.com/view/Dev/view/jasobrown/job/jasobrown-9633-dtest/]|
|[testall|http://cassci.datastax.com/view/Dev/view/jasobrown/job/jasobrown-9633-testall/]|
To encrypt the (primary) index and summary sstable files, in addition to the
data file, different code paths were required.
-As the summary is the once-shot read and different from all other code paths,
I made custom classes for handling it, {{EncryptedSummaryWritableByteChannel}}
and {{EncryptedSummaryInputStream}}. As the summary is intimately linked with
the owning sstable & data file, the summary will simply inherit the
key_alias/algo from the sstable, but then has it's IV written to the front of
the summary file.
- The encrypted primary index needs to have it's own 'chunks' file, a la the
{{Component.COMPRESSION_INFO}}, so I created
{{Component.INDEX_COMPRESSION_INFO}} so that it gets the proper treatment.
Thus, we can use {{CompressedSequentialWriter}} for writing out the index
file's offsets, just like what we do for the compressed data file.
- As with the first version of this patch, encrypting the data file (and now
the primary index) is handled by {{EncryptingCompressor}}.
WRT to CQL changes, we simply do {{... WITH ENCRYPTION='true'}} to enable the
sstable encryption. All the encryption parameters are already in the yaml, so
no need to pass those in separately. Further, to disable the sstable
encryption, simple execute {{ALTER TABLE ... WITH ENCRYPTION='false'}}. As a
side effect of piggy-backing on the compression infrastructure, though, when
executing {{DESCRIBE TABLE}} in cqlsh the encryption params show up as
'compression' data, not as encryption. I believe all the code for handling the
cqlsh describe queries is largely in the python driver, afaict.
Some miscellaneous changes:
- {{ICompressor}} got some additional functions for instance-specific values as
we need to carry a unique IV for each cipher.
- {{CipherFactory}} needed a small cleanup wrt caching instances (we were
creating a crap tonne of instances on the fly)
- Apparently I messed up a small part of the merge for #11040, and thus adding
it in here ({{HintsService}}). Without this, hints don't get encrypted when
enabled.
- added some {{@SupressWarnings}} annotations
> 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)
[jira] [Commented] (CASSANDRA-9633) Add ability to encrypt sstables
[ https://issues.apache.org/jira/browse/CASSANDRA-9633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15181951#comment-15181951 ] Cyril Scetbon commented on CASSANDRA-9633: -- thank you [~jasobrown] for the heads up. Hoping to see it soon. > 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)
[jira] [Commented] (CASSANDRA-9633) Add ability to encrypt sstables
[ https://issues.apache.org/jira/browse/CASSANDRA-9633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15181945#comment-15181945 ] Jason Brown commented on CASSANDRA-9633: [~cscetbon] I couldn't get the additions [~bdeggleston] recommended before the 3.4 cutoff, so it'll have to be in 3.5/3.6. > 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)
[jira] [Commented] (CASSANDRA-9633) Add ability to encrypt sstables
[ https://issues.apache.org/jira/browse/CASSANDRA-9633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15181933#comment-15181933 ] Cyril Scetbon commented on CASSANDRA-9633: -- Hey [~bdeggleston] any news on this ? > 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)
[jira] [Commented] (CASSANDRA-9633) Add ability to encrypt sstables
[
https://issues.apache.org/jira/browse/CASSANDRA-9633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15140008#comment-15140008
]
Jason Brown commented on CASSANDRA-9633:
bq. I think adding an table parameter would make the most sense
I had thought about that, as well, so now with a second 'vote', I'll dig into
implementing it with a table parameter.
bq. doesn't seem to address the encryption of index and summary files
I was hoping to make those separate tickets, tbh - and working on those things,
I felt, depended on having a reasonable plan forward on the sstables (this
ticket). Are you good with separate tickets for that work, or does it make
sense to lump it here?
bq. adding a {{compressesIndexFiles}} to ICompressor
Not sure I understand the suggestion here. Can you clarify a bit?
> 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)
[jira] [Commented] (CASSANDRA-9633) Add ability to encrypt sstables
[ https://issues.apache.org/jira/browse/CASSANDRA-9633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15140043#comment-15140043 ] Jason Brown commented on CASSANDRA-9633: bq. I'd prefer to keep it in this ticket sgtm. will start cracking at it > 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)
[jira] [Commented] (CASSANDRA-9633) Add ability to encrypt sstables
[
https://issues.apache.org/jira/browse/CASSANDRA-9633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15139977#comment-15139977
]
Blake Eggleston commented on CASSANDRA-9633:
Agreed that the best approach implementation wise is to build on top of
ICompressor, but that configuring encryption via compression settings is a
little weird. UX wise, I think adding an table parameter would make the most
sense (ie: {{... WITH ENCRYPTION=\{...\}}} ), and then implement it as an
Encrypting ICompressor class which wraps the regular compression class.
Something like this:
{code}
ICompressor compressor = compressionParams.makeCompressor();
compressor = encryptionParams.maybeWrapCompressor(compressor);
{code}
That seems like it would be a good balance or ease of use / ease of
implementation. wdyt?
I haven't dug too deeply into your commit because it doesn't seem to address
the encryption of index and summary files. Depending on your data model, it's
possible that a decent amount of the data users are trying to protect would be
inadvertently exposed in these files. Off the top of my head, I think you could
compress these files pretty easily as well though. This would probably have
performance implications for the read path, which would only make sense if you
were using encryption, so adding a {{compressesIndexFiles}} to ICompressor
would probably have to go along with it.
> 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)
[jira] [Commented] (CASSANDRA-9633) Add ability to encrypt sstables
[ https://issues.apache.org/jira/browse/CASSANDRA-9633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15140037#comment-15140037 ] Blake Eggleston commented on CASSANDRA-9633: bq. Are you good with separate tickets for that work, or does it make sense to lump it here? I'd prefer to keep it in this ticket, only because I don't think sstable encryption should be committed without index file encryption. That said, it probably makes sense to get the sstable stuff fleshed out, then do the index files. bq. Not sure I understand the suggestion here. Can you clarify a bit? I just meant that, in my hypothetical index file compression approach, it wouldn't make sense to compress the index files unless you were encrypting them. So you'd want the compressor to tell the sstable writer whether it should compress the index file. Just getting ahead of myself :) > 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)
[jira] [Commented] (CASSANDRA-9633) Add ability to encrypt sstables
[
https://issues.apache.org/jira/browse/CASSANDRA-9633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15115270#comment-15115270
]
Jason Brown commented on CASSANDRA-9633:
Pushed a first-pass implementation
[here|https://github.com/apache/cassandra/compare/trunk...jasobrown:9633]
This submission does piggy back off the {{ICompressor}} interface, and plugs in
reasonably well. Due to the stateful nature of {{EncryptingCompressor}} (see
[the
note|https://github.com/jasobrown/cassandra/blob/9633/src/java/org/apache/cassandra/io/compress/EncryptingCompressor.java#L47]
at the top of the class file), it needs a unqiue copy of the compressor when
creating new SSTables; hence the reason for
{{CompressionParams.copyWithFreshCompressor()}}. I'm open to sugesstions on
improving this.
Through testing this, I uncovered some inefficiencies with {{CipherFactory}}
(added with CASSANDRA-9945), so I refactored it a bit to cache instances of
{{KeyProvider}}. Encrypted commit logs (CASSANDRA-6018) and hints
(CASSANDRA-11040) are not really affected by this refactor.
One oddity, though, will be for users when they do want to encrypt a table;
they will have to set the compression options on the table - which doesn't map,
in an obvious manner, to encryption. I'm wide open to suggestions on how to
improve the "UI" for this; however, I'd be a bit reticent to create a parallel
set of of classes similar to what we have for compression, as I suspect
encryption won't be as widely employed as compression (and I'm not sure the
extra infrastructure is worth it).
> 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)
