e the
>individual
>messages without the server knowing the encryption keys or scheme?
>
>Is this a case where multiple logical messages (when combined together)
>are
>treated by Kafka as a single message, and it's up to the consumer to
>separate them?
>
>--Tom
>
>On Mo
wait for additional
>>messages and send a non-full batch ? Not that obvious.
>MG>Bruno can you describe kafka criteria for a Full Batch?MG>can you
>elucidate kafka criteria for a non Full-Batch?
>>
>> Ideally, we would like kafka clients to encrypt/decrypt the compre
I'm hesitant to cite it because it wasn't really a proper benchmark, but
with the end-to-end encryption through Kafka proof of concept described at
http://symc.ly/1pC2CEG, doing the encryption added only 26% to the time
taken to send messages and only 6% to the time taken to consume messages.
This
t info would know how to update their
>attack vectors
>MG>has anyone worked out a changeable cipher for Kafka Broker?
>> >>>
>> >>> Have I left out a scenario?MG>majority of financial institutions
>>implement cipher-aware proxy servers like cisco
&
Another option is to encrypt the data before you hand it to Kafka and have
the downstream decrypt it. This takes care of on-disk on on-wire
encryption. We did a proof of concept of this:
http://www.symantec.com/connect/blogs/end-end-encryption-though-kafka-our-p
roof-concept
(
ment by just exposing pluggability of codec and JMX for
>cleaner thread invocation and things will be taken care of transparently?
>
>Any interesting from other users of this proposal?
>
>Thanks,
>Josh
>
>
>
>
>From: Jim Hoagland &
You could do this with (I expect) reasonable efficiency and with no
changes to Kafka code by using multiple topics.
You can have a script that in a streaming manner reads out all messages in
a topic, decrypts them with the old key, encrypts them with the new key,
and adds them to a new topic. At
still believe we could improve by
>batch compressing + batch encrypting.
>
>Can you confirm that in your tests batch compression was disabled ?
>
>Thanks,
>Bruno
>
>
>> On 14 Jan 2016, at 23:47, Jim Hoagland <jim_hoagl...@symantec.com>
>>wrote:
>>
what you
did. In our tests, the encryption didn't add as much overhead as we
thought it would.
-- Jim
--
Jim Hoagland, Ph.D.
Sr. Principal Software Engineer
Big Data Analytics Team
Cloud Platform Engineering
On 1/14/16, 2:23 PM, "Bruno Rassaerts" <bruno.rassae...@novazone.be>
have any thoughts or questions.
Thanks,
Jim
--
Jim Hoagland, Ph.D.
Sr. Principal Software Engineer
Big Data Analytics Team
Cloud Platform Engineering
Symantec Corporation
http://cpe.symantec.com
10 matches
Mail list logo
