[jira] [Comment Edited] (CASSANDRA-6018) Add option to encrypt commitlog

["Jason Brown (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CASSANDRA-6018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14708426#comment-14708426 ] 

Jason Brown edited comment on CASSANDRA-6018 at 8/23/15 4:26 PM:
-----------------------------------------------------------------

bq. the way the header parameters are used by the descriptor

You are correct - the only thing I'm using the headerParameters field for is to stash the IV, so that we can get it at read-time (when replaying the commit log). I was hoping to keep EncyptionContext/TransparentDataEncryptionOptions a bit more general, and not stuff file-specific details in those classes, but perhaps somewhere in those classes is the best for the IV to go, after all. I'll think about that some more.

bq. Since you are compressing to ON_HEAP, I think it will help to use the same buffer type for the input as well

Will do. As a side note, I originally wrote this code using the byte array APIs of Cipher, so thus everything needed to be on-heap. After I discovered the ByteBuffer versions of the Cipher methods, I switched to those and honestly didn't think about the on/off heap question again. I can give a shot to trying everything off-heap vs. on-heap, but not sure there's a lot of gain in the off-heap model as, after we compress to off-heap, we would need to pull those bytes back into local process memory to encrypt. Any opinions, [~benedict]?

bq. {{doFinal}} is copy-safe

Huh, somehow I've always been using two buffers (separate in/out) with encryption operations with Cipher, and never saw that clause in the API :). I'll give that a shot and see what happens - thanks for pointing it out!

Will fix the other items, as well, in next update.


was (Author: jasobrown):
bq. the way the header parameters are used by the descriptor

You are correct - the only thing I'm using the headerParameters field for is to stash the IV, so that we can get it at read-time (when replaying the commit log). I was hoping to keep EncyptionContext/TransparentDataEncryptionOptions a bit more general, and not stuff file-specific details in those classes, but perhaps somewhere in those classes is the best for the IV to go, after all. I'll think about that some more.

bq. Since you are compressing to ON_HEAP, I think it will help to use the same buffer type for the input as well

Will do. As a side note, I originally wrote this code using the byte array APIs of Cipher, so thus everything needed to be on-heap. After I discovered the ByteBuffer versions of the Cipher methods, I switched to those and honestly didn't think about the on/off heap question again. I can give a shot to trying everything off-heap vs. on-heap, but not sure there's a lot of gain in the off-heap model as, after we compress to off-heap, we would need to pull those bytes back into local process memory to encrypt. Any opinions, [~benedict]?

bq. {{doFinal}} is copy-safe

Huh, somehow I've always been using two buffers (separate in/out) with encryption operations, and never saw that clause in the API :). I'll give that a shot and see what happens - thanks for pointing it out!

Will fix the other items, as well, in next update.

> Add option to encrypt commitlog 
> --------------------------------
>
>                 Key: CASSANDRA-6018
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-6018
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: Core
>            Reporter: Jason Brown
>            Assignee: Jason Brown
>              Labels: commit_log, encryption, security
>             Fix For: 3.x
>
>
> We are going to start using cassandra for a billing system, and while I can encrypt sstables at rest (via Datastax Enterprise), commit logs are more or less plain text. Thus, an attacker would be able to easily read, for example, credit card numbers in the clear text commit log (if the calling app does not encrypt the data itself before sending it to cassandra).
> I want to allow the option of encrypting the commit logs, most likely controlled by a property in the yaml.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)