Hi Sönke, I never looked at the original version, but what you describe in the new version makes sense to me.
Here are a few things which sprang to mind while I was reading: 1. It wasn't immediately obvious why this can't be achieved using custom serializers and deserializers. 2. It would be useful to fully define the Java interfaces you're talking about. 3 Would a KeyManager implementation be provided? 4. About compression+encryption: My understanding is CRIME used a chosen plaintext attack. AFAICS using compression would potentially allow a known plaintext attack, which is a weaker way of attacking a cipher. Even without compression in the picture known plaintext attacks would be possible, for example if the attacker knew the key was JSON encoded. Kind regards, Tom On Wed, Apr 29, 2020 at 12:32 AM Sönke Liebau <soenke.lie...@opencore.com.invalid> wrote: > All, > > I've asked for comments on this KIP in the past, but since I didn't really > get any feedback I've decided to reduce the initial scope of the KIP a bit > and try again. > > I have reworked to KIP to provide a limited, but useful set of features for > this initial KIP and laid out a very rough roadmap of what I'd envision > this looking like in a final version. > > I am aware that the KIP is currently light on implementation details, but > would like to get some feedback on the general approach before fully > speccing everything. > > The KIP can be found at > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-317%3A+Add+end-to-end+data+encryption+functionality+to+Apache+Kafka > > > I would very much appreciate any feedback! > > Best regards, > Sönke >
