[
https://issues.apache.org/jira/browse/HBASE-25263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17229408#comment-17229408
]
Andrew Kyle Purtell commented on HBASE-25263:
---------------------------------------------
I can tell you the intent of the shell facility but not what people might
actually be doing with it, my crystal ball is in the shop. :) So I suppose with
the advantage of more birthdays and maturity, I have to say I cannot say.
Worth noting that changing the algorithm does not affect existing files,
though, because each HFile has all of the necessary metadata for supporting its
decryption stored within it. As you know we don't re-transform the shell
password to read, we only use the shell password to derive a data encryption
key (DEK), which is then encrypted with the master encryption key and stored
into an HFile meta block. Whenever we need to read the HFile, the DEK is
extracted from the meta block, decrypted with the master key, and the decrypted
DEK is used to decrypt block data. Whatever the shell password is, or whatever
algorithm is used to derive a key from it, is immaterial to the decryption
process.
I don't think backwards compatibility as proposed would be meaningful to users,
because users of this feature care that their data is encrypted but are very
very unlikely to care about precisely how the DEK is derived except that the
choice of derivation function meets best practice and is sufficiently strong.
Time has moved on since the original patch landed and the derivation function
needs updating. Hence this proposal. +1 to updating the derivation function.
If our older key derivation function has been deemed insufficient then all of
the derived DEKs should probably also be treated as insufficient. The guidance
we give there is compaction will rewrite the files with newly derived DEKs.
Major compaction will rewrite most files, but not all, so there is scope for
further improvement here... We may want an unconditional major compaction to
ensure all DEKs are rotated.
> 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)
