cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Brown (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-6018) Add option to encrypt commitlog
Date Sun, 23 Aug 2015 16:26:46 GMT


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:
>             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

View raw message