[
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)
