[
https://issues.apache.org/jira/browse/HBASE-13002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14316513#comment-14316513
]
Andrew Purtell edited comment on HBASE-13002 at 2/11/15 4:55 PM:
-----------------------------------------------------------------
bq. Yes, the new configuration hbase.crypto.key.algorithm is introduced for
that. So whichever user configures it to will be used for key wrapping.
Yes, but the default is {{HConstants.DEFAULT_CIPHER}} which currently is "AES"
but could change. Introduce something like {{HConstants.CIPHER_AES}} and use
that as the default config value for "hbase.crypto.key.algorithm" and this
should be good to go.
Also, after this change, when the cipher for key wrapping is changed then all
existing encrypted HFiles and WALs are immediately unreadable. If you follow
where the EncryptionUtil methods for key unwrapping are used, you'll note that
the other situation where that could happen: When the master key is changed we
allow the administrator to specify a fallback. Then when writing new files the
new master key will be used but if decryption doesn't work with the new master
key we can fall back to the old. This allows for migration on-demand of
existing data from encryption with the old master key to the new. Eventually
the fallback configuration can be removed. I think we need to do something like
this when changing the cipher used for key wrapping.
was (Author: apurtell):
bq. Yes, the new configuration hbase.crypto.key.algorithm is introduced for
that. So whichever user configures it to will be used for key wrapping.
Yes, but the default is {{HConstants.DEFAULT_CIPHER}} which currently is "AES"
but could change. Introduce something like {{HConstants.CIPHER_AES}} and use
that as the default config value for "hbase.crypto.key.algorithm" and this
should be good to go.
Also, after this change, when the cipher for key wrapping is changed then all
existing encrypted HFiles and WALs are immediately unreadable. If you follow
where the EncryptionUtil methods for key unwrapping are used, you'll note that
the other situation where that could happen, when the master key is changed, we
allow the administrator to specify a fallback: When writing new files always
use the new master key but if decryption doesn't work with the new master key,
fall back to the old. This allows for migration of existing data from
encryption with the old master key to the new. I think we need to do something
like this when changing the cipher used for key wrapping.
> Make encryption cipher configurable
> -----------------------------------
>
> Key: HBASE-13002
> URL: https://issues.apache.org/jira/browse/HBASE-13002
> Project: HBase
> Issue Type: Improvement
> Reporter: Ashish Singhi
> Assignee: Ashish Singhi
> Fix For: 2.0.0, 1.0.1, 1.1.0, 0.98.11
>
> Attachments: HBASE-13002-v1.patch, HBASE-13002.patch
>
>
> Make encryption cipher configurable currently it is hard coded to AES, so
> that user can configure his/her own algorithm.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
