transparently?
> >
> >Any interesting from other users of this proposal?
> >
> >Thanks,
> >Josh
> >
> >
> >
> >
> >From: Jim Hoagland
> >Sent: Wednesday, January 20, 2016 11:00 AM
> >
users@kafka.apache.org; Josh Wo
Subject: Re: security: encryption at rest and key rotation idea
For the offset, at the start of topic (and perhaps periodically in the
topic), the script could make a note of the corresponding offset in the
previous topic. The consumer could then see the correspondence betwee
ds. When key is lost, we will invalid
>>the old key so message encrypted by old message will not be able to
>>decrypt if we don't re-encrypt them also.
>>
>>Josh
>>
>>From: Jens Rantil
>>Sent: Tuesday, January 1
>
>From: Jens Rantil
>Sent: Tuesday, January 19, 2016 11:48 PM
>To: users@kafka.apache.org
>Cc: users@kafka.apache.org
>Subject: Re: security: encryption at rest and key rotation idea
>
>Hi Josh,
>
>
>Kafka will/can expire messag
il
>Sent: Tuesday, January 19, 2016 11:48 PM
>To: users@kafka.apache.org
>Cc: users@kafka.apache.org
>Subject: Re: security: encryption at rest and key rotation idea
>
>Hi Josh,
>
>
>Kafka will/can expire message logs after a certain TTL. You can't simply
>rel
to decrypt if we don't
re-encrypt them also.
Josh
From: Jens Rantil
Sent: Tuesday, January 19, 2016 11:48 PM
To: users@kafka.apache.org
Cc: users@kafka.apache.org
Subject: Re: security: encryption at rest and key rotation idea
Hi Josh,
Kafka wil
Hi Josh,
Kafka will/can expire message logs after a certain TTL. You can't simply rely
on expiration for key rotation? That is, you start to produce messages with a
different key while your consumer temporarily handles the overlap of keys for
the duration of the TTL.
Just an idea,
Jens
