[jira] [Comment Edited] (CASSANDRA-9945) Add transparent data encryption core classes
[ https://issues.apache.org/jira/browse/CASSANDRA-9945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15135221#comment-15135221 ] Jeff Liu edited comment on CASSANDRA-9945 at 2/5/16 11:09 PM: -- [~jasobrown] With this ticket resolved, does it mean we can do transparent data encryption in 3.2 as what we can do with datastax enterprise version? More specifically, can I run the following command to encrypt data? ALTER TABLE dept WITH compression_parameters:sstable_compression = 'Encryptor' AND compression_parameters:cipher_algorithm = 'AES/ECB/PKCS5Padding' AND compression_parameters:secret_key_strength = 128; Thanks, Jeff was (Author: jeffl): With this ticket resolved, does it mean we can do transparent data encryption in 3.2 as what we can do with datastax enterprise version? More specifically, can I run the following command to encrypt data? ALTER TABLE dept WITH compression_parameters:sstable_compression = 'Encryptor' AND compression_parameters:cipher_algorithm = 'AES/ECB/PKCS5Padding' AND compression_parameters:secret_key_strength = 128; Thanks, Jeff > Add transparent data encryption core classes > > > Key: CASSANDRA-9945 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9945 > Project: Cassandra > Issue Type: Improvement >Reporter: Jason Brown >Assignee: Jason Brown > Labels: encryption > Fix For: 3.2 > > > This patch will add the core infrastructure classes necessary for transparent > data encryption (file-level encryption), as required for CASSANDRA-6018 and > CASSANDRA-9633. The phrase "transparent data encryption", while not the most > aesthetically pleasing, seems to be used throughout the database industry > (Oracle, SQLQServer, Datastax Enterprise) to describe file level encryption, > so we'll go with that, as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-9945) Add transparent data encryption core classes
[ https://issues.apache.org/jira/browse/CASSANDRA-9945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15135221#comment-15135221 ] Jeff Liu edited comment on CASSANDRA-9945 at 2/5/16 11:09 PM: -- [~jasobrown] With this ticket being resolved, does it mean we can do transparent data encryption in 3.2 as what we can do with datastax enterprise version? More specifically, can I run the following command to encrypt data? ALTER TABLE dept WITH compression_parameters:sstable_compression = 'Encryptor' AND compression_parameters:cipher_algorithm = 'AES/ECB/PKCS5Padding' AND compression_parameters:secret_key_strength = 128; Thanks, Jeff was (Author: jeffl): [~jasobrown] With this ticket resolved, does it mean we can do transparent data encryption in 3.2 as what we can do with datastax enterprise version? More specifically, can I run the following command to encrypt data? ALTER TABLE dept WITH compression_parameters:sstable_compression = 'Encryptor' AND compression_parameters:cipher_algorithm = 'AES/ECB/PKCS5Padding' AND compression_parameters:secret_key_strength = 128; Thanks, Jeff > Add transparent data encryption core classes > > > Key: CASSANDRA-9945 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9945 > Project: Cassandra > Issue Type: Improvement >Reporter: Jason Brown >Assignee: Jason Brown > Labels: encryption > Fix For: 3.2 > > > This patch will add the core infrastructure classes necessary for transparent > data encryption (file-level encryption), as required for CASSANDRA-6018 and > CASSANDRA-9633. The phrase "transparent data encryption", while not the most > aesthetically pleasing, seems to be used throughout the database industry > (Oracle, SQLQServer, Datastax Enterprise) to describe file level encryption, > so we'll go with that, as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-9945) Add transparent data encryption core classes
[
https://issues.apache.org/jira/browse/CASSANDRA-9945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14650343#comment-14650343
]
Jason Brown edited comment on CASSANDRA-9945 at 8/1/15 2:19 PM:
committed to trunk, with absolute pathname changed in
{{EncryptionContextGenerator.createEncryptionOptions()}}. Thanks!
commit sha 37160e109ede17c8cbffd553fcb24efa8d43b141
was (Author: jasobrown):
committed to trunk, with absolute pathname changed in
{{EncryptionContextGenerator.createEncryptionOptions()}}. Thanks!
Add transparent data encryption core classes
Key: CASSANDRA-9945
URL: https://issues.apache.org/jira/browse/CASSANDRA-9945
Project: Cassandra
Issue Type: Improvement
Reporter: Jason Brown
Assignee: Jason Brown
Labels: encryption
Fix For: 3.0 beta 1
This patch will add the core infrastructure classes necessary for transparent
data encryption (file-level encryption), as required for CASSANDRA-6018 and
CASSANDRA-9633. The phrase transparent data encryption, while not the most
aesthetically pleasing, seems to be used throughout the database industry
(Oracle, SQLQServer, Datastax Enterprise) to describe file level encryption,
so we'll go with that, as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-9945) Add transparent data encryption core classes
[ https://issues.apache.org/jira/browse/CASSANDRA-9945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14649209#comment-14649209 ] Jason Brown edited comment on CASSANDRA-9945 at 7/31/15 1:39 PM: - [~tjake] no, JCE is only required if you enable transparent data encryption (of course, we'll ship with it disabled). was (Author: jasobrown): [~tjake] no, JCE is only required if you are using transparent data encryption. Add transparent data encryption core classes Key: CASSANDRA-9945 URL: https://issues.apache.org/jira/browse/CASSANDRA-9945 Project: Cassandra Issue Type: Improvement Reporter: Jason Brown Assignee: Jason Brown Labels: encryption Fix For: 3.0 beta 1 This patch will add the core infrastructure classes necessary for transparent data encryption (file-level encryption), as required for CASSANDRA-6018 and CASSANDRA-9633. The phrase transparent data encryption, while not the most aesthetically pleasing, seems to be used throughout the database industry (Oracle, SQLQServer, Datastax Enterprise) to describe file level encryption, so we're go with that, as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-9945) Add transparent data encryption core classes
[
https://issues.apache.org/jira/browse/CASSANDRA-9945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14649982#comment-14649982
]
Jason Brown edited comment on CASSANDRA-9945 at 7/31/15 11:14 PM:
--
wrt to the thread local, it looks like {{Cipher#init}} is the biggest hog,
however, there is still much to be gained by not creating a new Cipher instance
each time. Here's [my
variation|https://gist.github.com/jasobrown/99daa06776b926bdf987] on [~snazy]'s
benchmark class; this reflects a little closer the actual use pattern in my
patch. The biggest difference is I force the Cipher to {{init}} on every call,
for both thread local and non-thread local.
The results are as follows (run on my laptop, in a VM):
{code}
snazy:
Benchmark (cipher) Mode CntScore
Error Units
CipherBench.cipherGetInstance AES/CBC/PKCS5Padding thrpt50.636 ±
0.031 ops/us
CipherBench.cipherThreadLocal AES/CBC/PKCS5Padding thrpt5 594.063 ±
58.416 ops/us
CipherBench.cipherGetInstance AES/CBC/PKCS5Padding avgt54.873 ±
0.211 us/op
CipherBench.cipherThreadLocal AES/CBC/PKCS5Padding avgt50.005 ±
0.001 us/op
jasobrown:
Benchmark (cipher) Mode Cnt Score Error
Units
CipherBench.cipherGetInstance AES/CBC/PKCS5Padding thrpt5 0.402 ± 0.133
ops/us
CipherBench.cipherThreadLocal AES/CBC/PKCS5Padding thrpt5 27.989 ± 7.341
ops/us
CipherBench.cipherGetInstance AES/CBC/PKCS5Padding avgt5 8.527 ± 1.828
us/op
CipherBench.cipherThreadLocal AES/CBC/PKCS5Padding avgt5 0.093 ± 0.001
us/op
{code}
Thus, I think there's still benefit to using the thread local, to avoid the
{{Cipher#getInstance}} call, and if we check the cipher, alg, iv, and so on,
match the input params (when we fish out the Cipher instance form the thread
local), then we can avoid the {{Cipher#init}} call, as well.
was (Author: jasobrown):
wrt to the thread local, it looks like {{Cipher#init}} is the biggest hog,
however, there is still much to be gained by not creating a new Cipher instance
each time. Here's [my
variation|https://gist.github.com/jasobrown/99daa06776b926bdf987] on [~snazy]'s
benchmark class; this reflects a little closer the actual use pattern in my
patch. The biggest difference is I force the Cipher to {{init}} on every call,
for both thread local and non-thread local.
The results are as follows:
{code}
snazy:
Benchmark (cipher) Mode CntScore
Error Units
CipherBench.cipherGetInstance AES/CBC/PKCS5Padding thrpt50.636 ±
0.031 ops/us
CipherBench.cipherThreadLocal AES/CBC/PKCS5Padding thrpt5 594.063 ±
58.416 ops/us
CipherBench.cipherGetInstance AES/CBC/PKCS5Padding avgt54.873 ±
0.211 us/op
CipherBench.cipherThreadLocal AES/CBC/PKCS5Padding avgt50.005 ±
0.001 us/op
jasobrown:
Benchmark (cipher) Mode Cnt Score Error
Units
CipherBench.cipherGetInstance AES/CBC/PKCS5Padding thrpt5 0.402 ± 0.133
ops/us
CipherBench.cipherThreadLocal AES/CBC/PKCS5Padding thrpt5 27.989 ± 7.341
ops/us
CipherBench.cipherGetInstance AES/CBC/PKCS5Padding avgt5 8.527 ± 1.828
us/op
CipherBench.cipherThreadLocal AES/CBC/PKCS5Padding avgt5 0.093 ± 0.001
us/op
{code}
Thus, I think there's still benefit to using the thread local, to avoid the
{{Cipher#getInstance}} call, and if we check the cipher, alg, iv, and so on,
match the input params (when we fish out the Cipher instance form the thread
local), then we can avoid the {{Cipher#init}} call, as well.
Add transparent data encryption core classes
Key: CASSANDRA-9945
URL: https://issues.apache.org/jira/browse/CASSANDRA-9945
Project: Cassandra
Issue Type: Improvement
Reporter: Jason Brown
Assignee: Jason Brown
Labels: encryption
Fix For: 3.0 beta 1
This patch will add the core infrastructure classes necessary for transparent
data encryption (file-level encryption), as required for CASSANDRA-6018 and
CASSANDRA-9633. The phrase transparent data encryption, while not the most
aesthetically pleasing, seems to be used throughout the database industry
(Oracle, SQLQServer, Datastax Enterprise) to describe file level encryption,
so we'll go with that, as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-9945) Add transparent data encryption core classes
[ https://issues.apache.org/jira/browse/CASSANDRA-9945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14648342#comment-14648342 ] Jason Brown edited comment on CASSANDRA-9945 at 7/30/15 10:13 PM: -- Added link to the branch up on github (see above). NOTE: to test this code (there's only one test class for this submission), you need to have the Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files 8 installed. It's a jar that can be downloaded from Oracle (current link: http://www.oracle.com/technetwork/java/javase/downloads/jce8-download-2133166.html). Highlights of patch: - created new yaml section called transparent_data_encryption_options. The config allows users to set the name of the keystore as well as the key (alias) within the keystore to use. This allows multiple keys to be used from the same store, and further allows users to migrate keys. - added CipherFactory as a proxy for loading and caching keys in memory, as well as getting instances of Ciphers (using the loaded keys). - KeyProvider interface allows keys to either be loaded from a local keystore (via the default implementation, JKSKeyProvider), or to be loaded from a custom source. We need that functionality at $DAY_JOB, hence the reason for the pluggable implementation. was (Author: jasobrown): Added link to the branch up on github (see above). NOTE: to test this code (there's only one test class for this submission), you need to have the Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files 8 installed. It's a jar that can be downloaded from Oracle (current link: http://www.oracle.com/technetwork/java/javase/downloads/jce8-download-2133166.html). Highlights of patch: - created new yaml section called transparent_data_encryption_options. The config allows users to set the name of the keystore as well as the key (alias) within the keystore to use. This allows multiple keys to be used from the same store, and further allows users to migrate keys (see later). - added CipherFactory as a proxy for loading and caching keys in memory, as well as getting instances of Ciphers (using the loaded keys). - KeyProvider interface allows keys to either be loaded from a local keystore (via the default implementation, JKSKeyProvider), or to be loaded from a custom source. We need that functionality at $DAY_JOB, hence the reason for the pluggable implementation. Add transparent data encryption core classes Key: CASSANDRA-9945 URL: https://issues.apache.org/jira/browse/CASSANDRA-9945 Project: Cassandra Issue Type: Improvement Reporter: Jason Brown Assignee: Jason Brown Labels: encryption Fix For: 3.0 beta 1 This patch will add the core infrastructure classes necessary for transparent data encryption (file-level encryption), as required for CASSANDRA-6018 and CASSANDRA-9633. The phrase transparent data encryption, while not the most aesthetically pleasing, seems to be used throughout the database industry (Oracle, SQLQServer, Datastax Enterprise) to describe file level encryption, so we're go with that, as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
