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 Tue, 12 Jan 2016 14:55:40 GMT


Jason Brown commented on CASSANDRA-6018:

Pushed changes to a new commit on the same branch - also, [this diff|]
as a shortcut for changes wrt this update.

Added some more comments to {{EncryptionUtils}}, although I'm sure more could always be added

bq. Could we not reserve the header bytes, ...

While there's prossibly some improvements that can be taken into account, I think we might
get into trouble wrt reusing the input buffer for the output buffer on the {{Cipher.doFinal()}}
calls. Also, as I'm planning on using {{EncryptionUtils}} for encrypting sstables and hints
(already implemented, pending internal review), the structure and use of overloading encrpyt
(and using the {{WritableByteChannel}}), and other such things will become much more obvious.

bq. addSize and maybeSwap in {{EncryptedSegment.write}} can be taken out of the loop.

I don't think addSize can be taken out as we'll miscount the number of bytes written out.
I discovered this via by your handy additions to the CommitLogStressTest :)  WRT {{maybeSwap()}},
I figured out we don't need that at all as we can always safely reassign the encryptedBuffer
back to the buffer, and then compare capacity outside of the loop for the CAS.

bq. For uncompressed <=2.1 replay we need to tolerate errors for the whole of the last


bq. I don't think the {{SegmentReadException}} can escape to {[CommitLogReplayer.recover}}
which tries to catch and act on it.

Ahh, good call. Fixed by moving catching SRE in {{SegmentReader.SegmentIterator.computeNext()}}

> Add option to encrypt commitlog 
> --------------------------------
>                 Key: CASSANDRA-6018
>                 URL:
>             Project: Cassandra
>          Issue Type: New Feature
>            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