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

["Peter Somogyi (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/HBASE-25263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Peter Somogyi resolved HBASE-25263.
-----------------------------------
    Fix Version/s: 2.4.0
                   3.0.0-alpha-1
       Resolution: Fixed

Pushed to branch-2 and master.
[~symat], could you fill in the Release Note field?

> 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
>             Fix For: 3.0.0-alpha-1, 2.4.0
>
>
> This PR is a follow-up of HBASE-25181 (#2539), 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). We are changing it to {{PBKDF2WithHmacSHA384}}. It will not break backward-compatibility, as even the tables created by the shell using the new algorithm will be able to load (e.g. during bulkload / replication) the HFiles serialized with the key generated by an old algorithm, as the HFiles themselves already contain the key necessary for their decryption.
> Smaller issues to be fixed:
> 2. Improve the documentation e.g. with the changes introduced by HBASE-25181 and also by some points discussed on the Jira ticket of HBASE-25263.
> 3. In {{EncryptionUtil.createEncryptionContext}} the various encryption config checks should throw {{IllegalStateExceptions}} instead of {{RuntimeExceptions}}.
> 4. Test cases in {{TestEncryptionTest.java}} should be broken down into smaller tests.
> 5. {{TestEncryptionDisabled.java}} should use {{ExpectedException}} JUnit rule to validate exceptions.



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