[
https://issues.apache.org/jira/browse/CASSANDRA-6018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14708426#comment-14708426
]
Jason Brown commented on CASSANDRA-6018:
----------------------------------------
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)
