You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@kylin.apache.org by Rumen Paletov <ru...@gmail.com> on 2018/04/15 01:02:38 UTC

Initializing SecretKeySpec with a constant key is insecure

Hello,

As part of some research about the common crypto mistakes that developers
make <https://cs.ucsb.edu/~chris/research/doc/ccs13_cryptolint.pdf>, I
noticed that your application has one of them.

In particular, there's a violation of Rule 3 in
org.apache.kylin.common.util.EncryptUtil
<https://github.com/apache/kylin/blob/5552164ba09eba989b9ddccdf3f1e4f83ed0b799/core-common/src/main/java/org/apache/kylin/common/util/EncryptUtil.java#L36>.
That is, SecretKeySpec is being initialized with a constant key
<https://github.com/apache/kylin/blob/5552164ba09eba989b9ddccdf3f1e4f83ed0b799/core-common/src/main/java/org/apache/kylin/common/util/EncryptUtil.java#L30>
instead of a randomly generated one.

One solution would be to generate a key using SecureRandom:

> byte[] key = new byte[16];
> new SecureRandom.nextBytes(key);

Re: Initializing SecretKeySpec with a constant key is insecure

Posted by Li Yang <li...@apache.org>.
Thanks Rumen. JIRA is created to track this improvement.

https://issues.apache.org/jira/browse/KYLIN-3356

On Sun, Apr 15, 2018 at 9:02 AM, Rumen Paletov <ru...@gmail.com>
wrote:

> Hello,
>
> As part of some research about the common crypto mistakes that developers
> make <https://cs.ucsb.edu/~chris/research/doc/ccs13_cryptolint.pdf>, I
> noticed that your application has one of them.
>
> In particular, there's a violation of Rule 3 in
> org.apache.kylin.common.util.EncryptUtil
> <https://github.com/apache/kylin/blob/5552164ba09eba989b9ddccdf3f1e4
> f83ed0b799/core-common/src/main/java/org/apache/kylin/
> common/util/EncryptUtil.java#L36>.
> That is, SecretKeySpec is being initialized with a constant key
> <https://github.com/apache/kylin/blob/5552164ba09eba989b9ddccdf3f1e4
> f83ed0b799/core-common/src/main/java/org/apache/kylin/
> common/util/EncryptUtil.java#L30>
> instead of a randomly generated one.
>
> One solution would be to generate a key using SecureRandom:
>
> > byte[] key = new byte[16];
> > new SecureRandom.nextBytes(key);
>