[
https://issues.apache.org/jira/browse/CASSANDRA-6018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15094004#comment-15094004
]
Jason Brown commented on CASSANDRA-6018:
----------------------------------------
Pushed changes to a new commit on the same branch - also, [this
diff|https://github.com/apache/cassandra/commit/cbc36f629a3fe5ad537f57a4c24e437052772178]
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 segment...
Done.
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: https://issues.apache.org/jira/browse/CASSANDRA-6018
> 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
(v6.3.4#6332)
