hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Purtell (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (HBASE-12188) Use AES-GCM as the preferred cipher when encrypting HFiles
Date Tue, 07 Oct 2014 17:42:34 GMT

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

Andrew Purtell updated HBASE-12188:
    Summary: Use AES-GCM as the preferred cipher when encrypting HFiles  (was: Use AES-GCM
as the preferred mode when encrypting HFiles)

> Use AES-GCM as the preferred cipher when encrypting HFiles
> ----------------------------------------------------------
>                 Key: HBASE-12188
>                 URL: https://issues.apache.org/jira/browse/HBASE-12188
>             Project: HBase
>          Issue Type: Improvement
>            Reporter: Andrew Purtell
>            Priority: Minor
>             Fix For: 2.0.0
> Currently for encrypting HFiles we use AES in CTR mode. This protects data against plaintext
recovery but does not offer data integrity verification. We must continue to rely on HDFS
integrity protection mechanisms, or internal HFile checksums, which could be subverted. An
attacker might be able to maliciously introduce corruption that would not be detected during
> GCM mode operates as a stream cipher like CTR mode while incrementally calculating a
message authentication code (MAC) concurrent with encryption, in a way that affords efficient
high performance parallel implementation. The process of decryption also verifies the integrity
of the data in a cryptographically strong manner. Any tampering or corruption will result
in a reported decryption failure. This provides a marginal improvement in security because
tampering or corruption will be found at the HFile level and so the invalid data will not
have a chance to be passed up into higher layers.
> We needed to use AES-CTR when initially developing HFile encryption because just about
everyone was still using Java 6 in production. This has changed. We have dropped support for
Java 6 as of branch-1. Conceivably we could introduce use of the new Java 7+ APIs for working
with AEAD modes like GCM. Once doing so, the code will no longer compile if using the JDK

This message was sent by Atlassian JIRA

View raw message