[
https://issues.apache.org/jira/browse/CASSANDRA-6018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15093714#comment-15093714
]
Branimir Lambov commented on CASSANDRA-6018:
--------------------------------------------
Thank you for the update.
[{{EncryptionUtils}} (all
methods)|https://github.com/apache/cassandra/compare/trunk...jasobrown:6018#diff-7289930937dea70ad2fb73f66006d5d7R61]:
Could add comment about the expected usage to the JavaDoc. It's not obvious
that user should update its outputBuffer with the resulting value.
[encrypt|https://github.com/apache/cassandra/compare/trunk...jasobrown:6018#diff-7289930937dea70ad2fb73f66006d5d7R83]:
Could we not reserve the header bytes, i.e. provide a method to prepare
buffers for caller that take header and cipher output size into account?
Otherwise, I think it should be renamed to {{encryptAndWrite}}.
[{{addSize}} and {{maybeSwap}} in
{{EncryptedSegment.write}}|https://github.com/apache/cassandra/compare/trunk...jasobrown:6018#diff-a3015c78b233e027651f8b0be8ae22c8R130]
can be taken out of the loop.
[{{SegmentIterator}}|https://github.com/apache/cassandra/compare/trunk...jasobrown:6018#diff-4c3a8240a441cef90e68dddd0246ee64R105]:
For uncompressed <=2.1 replay we need to tolerate errors for the whole of the
last segment, as the segment could be reused and only partially overwritten and
we can't really identify where the last section is. Also found in
[{{CommitLogReplayer}}|https://github.com/apache/cassandra/compare/trunk...jasobrown:6018#diff-348a1347dacf897385fb0a97116a1b5eR390].
I realize we don't seem to have a test for this particular scenario.
I don't think the {{SegmentReadException}} can escape to
{{CommitLogReplayer.recover}} which tries to catch and act on it.
> 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)
