You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@kafka.apache.org by Ismael Juma <is...@juma.me.uk> on 2018/01/09 11:34:38 UTC
Re: [DISCUSS] KIP 226 - Dynamic Broker Configuration
Hi Rajini,
Quick question (sorry if this was already discussed). How were the
following chosen?
Name: password.encoder.keyfactory.algorithm Type: String Default:
PBKDF2WithHmacSHA512 if available, otherwise PBKDF2WithHmacSHA1 (e.g. Java7)
Name: password.encoder.cipher.algorithm Type: String Default:
AES/CBC/PKCS5Padding
Name: password.encoder.key.length Type: Integer Default: 128
Name: password.encoder.iterations Type: Integer Default: 2048
Also, was a AES/GCM variant considered as the default cipher algorithm?
Ismael
On Mon, Nov 20, 2017 at 1:57 PM, Rajini Sivaram <ra...@gmail.com>
wrote:
> Hi all,
>
> I have submitted KIP-226 to enable dynamic reconfiguration of brokers
> without restart:
>
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-
> 226+-+Dynamic+Broker+Configuration
>
> The KIP proposes to extend the current dynamic replication quota
> configuration for brokers to support dynamic reconfiguration of a limited
> set of configuration options that are typically updated during the lifetime
> of a broker.
>
> Feedback and suggestions are welcome.
>
> Thank you...
>
> Regards,
>
> Rajini
>
Re: [DISCUSS] KIP 226 - Dynamic Broker Configuration
Posted by Rajini Sivaram <ra...@gmail.com>.
Hi Ismael,
Thank you for reviewing the KIP.
*password.encoder.iterations: 2048*: That was a mistake in the doc, changed
to 4096, which is the minimum we use for SCRAM credentials
*password.encoder.key.length: 128: *That is a key size that works with the
default cipher algorithm. Will change if we change that.
I wasn't sure what to choose for these two, so chose common ones . Lastpass
docs say they use *PBKDF2WithHmacSHA256 with AES*
- *password.encoder.keyfactory.algorithm: **PBKDF2WithHmacSHAn: *I think
PBKDF2 is typically used as the SecretKeyFactory algorithm for password
encryption. But not sure if we should choose something different,
particularly if we want to support Java7 which doesn't support
*PBKDF2WithHmacSHA512*.
- password.encoder.cipher.algorithm: *AES/CBC/PKCS5Padding: *I haven't
looked at AES/GCM variant, do you know if that is better?
On Tue, Jan 9, 2018 at 11:34 AM, Ismael Juma <is...@juma.me.uk> wrote:
> Hi Rajini,
>
> Quick question (sorry if this was already discussed). How were the
> following chosen?
>
> Name: password.encoder.keyfactory.algorithm Type: String Default:
> PBKDF2WithHmacSHA512 if available, otherwise PBKDF2WithHmacSHA1 (e.g.
> Java7)
> Name: password.encoder.cipher.algorithm Type: String Default:
> AES/CBC/PKCS5Padding
> Name: password.encoder.key.length Type: Integer Default: 128
> Name: password.encoder.iterations Type: Integer Default: 2048
>
> Also, was a AES/GCM variant considered as the default cipher algorithm?
>
> Ismael
>
> On Mon, Nov 20, 2017 at 1:57 PM, Rajini Sivaram <ra...@gmail.com>
> wrote:
>
> > Hi all,
> >
> > I have submitted KIP-226 to enable dynamic reconfiguration of brokers
> > without restart:
> >
> > https://cwiki.apache.org/confluence/display/KAFKA/KIP-
> > 226+-+Dynamic+Broker+Configuration
> >
> > The KIP proposes to extend the current dynamic replication quota
> > configuration for brokers to support dynamic reconfiguration of a limited
> > set of configuration options that are typically updated during the
> lifetime
> > of a broker.
> >
> > Feedback and suggestions are welcome.
> >
> > Thank you...
> >
> > Regards,
> >
> > Rajini
> >
>