[jira] [Commented] (HBASE-25263) Change encryption key generation algorithm used in the HBase shell

["Mate Szalay-Beko (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/HBASE-25263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17229080#comment-17229080 ] 

Mate Szalay-Beko commented on HBASE-25263:
------------------------------------------

regarding changing {{PBKDF2WithHmacSHA1}} to {{PBKDF2WithHmacSHA384}}:

[~apurtell] I saw you did something similar in HBASE-10951. On that ticket the assumption was that there is no compatibility issue with simply changing this algorithm:
{quote}No compatability issues that I can see given this isn't the way to generate data keys for production. This is so one can use the shell to create a schema with all encryption related attributes set up properly for basic functional testing or integration tests.
{quote}
Do you think this is still true? Isn't is possible that someone is relying in production on the schema defined with the HBase shell?

Alternatively (instead of simply changing this argument) I can introduce a configuration variable, defaulting to the old algorithm.

What do you think?

> Change encryption key generation algorithm used in the HBase shell
> ------------------------------------------------------------------
>
>                 Key: HBASE-25263
>                 URL: https://issues.apache.org/jira/browse/HBASE-25263
>             Project: HBase
>          Issue Type: Improvement
>          Components: encryption, shell
>            Reporter: Mate Szalay-Beko
>            Assignee: Mate Szalay-Beko
>            Priority: Major
>
> This ticket is a follow-up of HBASE-25181, where several issues were discussed on the PR:
> 1. Currently we use {{PBKDF2WithHmacSHA1}} key generation algorithm to generate a secret key for HFile / WalFile encryption, when the user is defining a string encryption key in the hbase shell. This algorithm is not secure enough and not allowed in certain environments (e.g. on FIPS compliant clusters). Our plan is to change it to e.g.  {{PBKDF2WithHmacSHA384}}. If this would break backward compatibility, then we should make this algorithm configurable.
> Smaller issues:
> 2. In {{EncryptionUtil.createEncryptionContext}} the various encryption config checks should throw IllegalStateExceptions instead of RuntimeExceptions.
> 3. Test cases in {{TestEncryptionTest.java}} should be broken down into smaller tests.
> 4. {{TestEncryptionDisabled.java}} should use {{ExpectedException}} JUnit rule to validate exceptions.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)