[
https://issues.apache.org/jira/browse/HBASE-25263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mate Szalay-Beko updated HBASE-25263:
-------------------------------------
Description:
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.
was:
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 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:
2. Updating the documentation about changes introduced both by HBASE-25181 and
by this change.
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.
> 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 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)
