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] [Commented] (HBASE-16414) Improve performance for RPC encryption with Apache Common Crypto
Date Tue, 30 Aug 2016 16:15:20 GMT

    [ https://issues.apache.org/jira/browse/HBASE-16414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15449418#comment-15449418
] 

Andrew Purtell commented on HBASE-16414:
----------------------------------------

I'm sorry but we can't accept this patch as-is. 

The naming of classes, like SaslAES and SaslCipherMeta and such use the term SASL but this
isn't appropriate here. SASL is a standard. What this patch proposes is injection of custom
negotiation (using protobuf of custom construction) and encryption that have nothing to do
with the SASL standard. The naming of these classes is a lie and proposed integration is not
clean. Ram's suggestion to unify this code with the SASL code in the RPC server cannot achieve
a good result because fundamentally this has nothing to do with SASL.  

While I have to veto this current proposal I do think accelerated AES encryption for HBase
RPC would be good to have. 

My suggestion for a path forward is to integrate the accelerated codec below HBase in the
JRE's SASL stack. Implement a SASL security provider (https://docs.oracle.com/javase/8/docs/technotes/guides/security/sasl/sasl-refguide.html#PROV).
Then there should be no custom messages or API needed at the HBase layer. The changes needed
would be to add configuration that tells HBase to request and use the custom provider by setting
the right system properties as defined by the Java SASL API. 

Another possible path forward is to implement connection parameter negotiation like as proposed
on HBASE-9351. Then the integration will be good. We can extend our protocol with new options
such as this cleanly without abusing (at best) the meaning of names and labels in the code.



> Improve performance for RPC encryption with Apache Common Crypto
> ----------------------------------------------------------------
>
>                 Key: HBASE-16414
>                 URL: https://issues.apache.org/jira/browse/HBASE-16414
>             Project: HBase
>          Issue Type: Improvement
>          Components: IPC/RPC
>    Affects Versions: 2.0.0
>            Reporter: Colin Ma
>            Assignee: Colin Ma
>         Attachments: HBASE-16414.001.patch, HbaseRpcEncryptionWithCrypoto.docx
>
>
> Hbase RPC encryption is enabled by setting “hbase.rpc.protection” to "privacy". With
the token authentication, it utilized DIGEST-MD5 mechanisms for secure authentication and
data protection. For DIGEST-MD5, it uses DES, 3DES or RC4 to do encryption and it is very
slow, especially for Scan. This will become the bottleneck of the RPC throughput.
> Apache Commons Crypto is a cryptographic library optimized with AES-NI. It provides Java
API for both cipher level and Java stream level. Developers can use it to implement high performance
AES encryption/decryption with the minimum code and effort. Compare with the current implementation
of org.apache.hadoop.hbase.io.crypto.aes.AES, Crypto supports both JCE Cipher and OpenSSL
Cipher which is better performance than JCE Cipher. User can configure the cipher type and
the default is JCE Cipher.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message