Configuring encryption per table (TDE) 

Configure transparent data encryption (TDE) on a per table basis. You can configure encryption with or without compression.

Designate transparent data encryption (TDE) on a per table basis. Using encryption, your application can read and write to SSTables that use different encryption algorithms or use no encryption at all.

You must login as a superuser to encrypt data. For example:

$ cqlsh -u cassandra -p cassandra

Example of configuring encryption per table 

Create two system key files:
$ sudo dsetool createsystemkey 'AES/ECB/PKCS5Padding' 128 system_key
$ sudo dsetool createsystemkey 'AES/ECB/PKCS5Padding' 128 system_key_2
Verify that the system keys have read write permissions:
$ la -l
-rw------- 1 cassandra cassandra 50 May 19 10:54 system_key
-rw------- 1 cassandra cassandra 50 May 19 11:20 system_key_2
Create a table that specifies to use the system_key_2 file as the encryption key for this specific table:
create table users (name text PRIMARY key, bio text ) 
    with compression = { 'sstable_compression' : 'EncryptingSnappyCompressor',   
    'cipher_algorithm' : 'AES/ECB/PKCS5Padding',   
    'secret_key_strength' : 128,   
    'chunk_length_kb' : 128, 
    'system_key_file':'system_key_2' };

Encrypting table data with encryption and compression 

You can use a single CREATE TABLE or ALTER TABLE statement to set encryption and compression. The single CQL statement is:
  WITH compression =
  { 'sstable_compression' : 'EncryptingSnappyCompressor',
  'cipher_algorithm' : 'AES/ECB/PKCS5Padding',
  'secret_key_strength' : 128,
  'chunk_length_kb' : 128 };
Note: Designating data for encryption using ALTER TABLE does not encrypt existing SSTables, just new SSTables that are generated.
After you alter a table for encryption, force a re-write of existing SSTables into encrypted format:
$ nodetool upgradesstables -a
For encryption keys on an external key server, see Encrypting table data with KMIP encryption keys.

Encrypting table data with encryption, but no compression 

When setting up data to be encrypted, but not compressed, set the chunk_length_kb option to the lowest possible value. Setting this option to a low value such as 1 improves read performance by limiting the data that needs to be decrypted for each read operation to 1 KB.

Encryption/compression options and sub-options 

Using encryption, your application can read and write to SSTables that use different encryption algorithms or no encryption at all. Using different encryption algorithms to encrypt SSTable data is similar to using different compression algorithms to compress data.

The high-level container options for encryption and/or compression that can be used in the CREATE TABLE and ALTER TABLE statements are:
Encryptor Encrypts table data.
EncryptingDeflateCompressor Encrypts table data using the Deflate compression algorithm.
EncryptingLZ4Compressor Encrypts table data using the LZ4 compression algorithm.
EncryptingSnappyCompressor Encrypts table data and uses Snappy compression algorithm.
DeflateCompressor Does not encrypt table data, uses Deflate compression algorithm.
SnappyCompressor Does not encrypt table data, uses Snappy compression algorithm.
LZ4Compressor (default) Does not encrypt table data, uses LZ4 compression algorithm.
If defining a table with the Encryptor encryptor, set the young generation heap (-Xmn) parameter to a larger space to improve garbage collection (GC).

For example if running cassandra-stress, set : -Xmn1600M. The encryption and compression sub-options are:

cipher-algorithm sub-option  

When Java Cryptography Extension (JCE) is installed, the cipher_algorithm options and acceptable secret_key_strength values for the algorithms are:
cipher_algorithm secret_key_strength
AES/CBC/PKCS5Padding 128, 192, or 256
AES/ECB/PKCS5Padding 128, 192, or 256
DES/CBC/PKCS5Padding 56
DESede/CBC/PKCS5Padding 112 or 168
Blowfish/CBC/PKCS5Padding 32-448
RC2/CBC/PKCS5Padding 40-128
When JCE is installed, the following encryption options are valid:
  • sstable_compression = EncryptingDeflateCompressor
  • cipher_algorithm = 'AES/CBC/PKCS5Padding'
  • secret_key_strength = 256
  • chunk_length_kb = 128
  • key_provider = KmipKeyProviderFactory
  • kmip_host = kmip_group2

You can install custom providers for your JVM. The AES-512 is not supported out-of the box.

Specify KmipKeyProviderFactory to use the KMIP key server for encryption.
The name of the KMIP key server group set in the kmip_hosts section in dse.yaml.
The key location sub-option

Create global encryption keys using the dsetool createsystemkey command. You can create a global encryption key in the location that is specified by system_key_directory in the dse.yaml file. This default global encryption key is used when the system_key_file subproperty is not specified.

To use a specific encryption key, use:
The chunk_length_kb sub-option

On disk, SSTables are encrypted and compressed by block (to allow random reads). This subproperty of compression defines the size (in KB) of the block and is a power of 2. Values larger than the default value might improve the compression rate, but increases the minimum size of data to be read from disk when a read occurs. While the default value (64) is a good middle-ground for compressing tables, the maximum key size for Data Encryption Standard (DES) is 64 and the maximum key size for all other encryption algorithms is 128. For stronger encryption, install Java Cryptography Extension (JCE).

Using just encryption and no compression, the size of SSTables are larger than they would be if you combined compression. During creation of the table, DataStax Enterprise looks for the system key as specified in dse.yaml. You do not need to specify the location of keytab file that contains the system key.

The iv_length sub-option

Not all algorithms allow you to set this sub-option, and most complain if it is not set to 16 bytes. Either use 16 or accept the default.

The syntax for setting this sub-option is similar to setting a compression algorithm to compress data.

  WITH compression =
  { 'sstable_compression' : 'EncryptingSnappyCompressor',
  'cipher_algorithm' : 'AES/ECB/PKCS5Padding',
  'secret_key_strength' : 128,
  'iv_length' : 16 };

Using SolrJ Auth to implement encryption 

To use the SolrJ-Auth libraries to implement encryption, follow instructions in the file.

The default location of the file depends on the type of installation:
Debian installations /usr/share/doc/dse-libsolr*
RHEL-based installations /usr/share/doc/dse-libsolr
Binary installations resources/solr

These SolrJ-Auth libraries are included in the clients directory in DataStax Enterprise distribution. The SolrJ-Auth code is public.

The default location of the clients directory depends on the type of installation:
Debian installations /usr/share/dse/clients
Binary installations install_location/clients