[
https://issues.apache.org/jira/browse/HBASE-16414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15448728#comment-15448728
]
ramkrishna.s.vasudevan commented on HBASE-16414:
------------------------------------------------
The improvement looks good.
Few questions
{code}
- ch.pipeline().addLast("frameDecoder",
- new LengthFieldBasedFrameDecoder(Integer.MAX_VALUE, 0, 4, 0, 4));
+ ch.pipeline().addLast("beforeUnwrapDecoder",
+ new LengthFieldBasedFrameDecoder(Integer.MAX_VALUE, 0, 4, 0, 0));
+ ch.pipeline().addLast("afterUnwrapDecoder",
+ new LengthFieldBasedFrameDecoder(Integer.MAX_VALUE, 0, 4, 0, 4));
{code}
As am not sure on this - why is this change needed now?
{code}
+ // unwrap the SaslCipherMeta message with sasl client
+ byte[] unwrappedResponse = saslClient.unwrap(buff, 0, buff.length);
+ RPCProtos.SaslCipherMeta saslCipherMeta =
+ RPCProtos.SaslCipherMeta.parseFrom(unwrappedResponse);
+ Properties properties = new Properties();
+ // the property for cipher class
+ properties.setProperty(CryptoCipherFactory.CLASSES_KEY,
+ conf.get(HConstants.CRYPTO_SASL_ENCRYPTION_AES_CIPHER_CLASS_KEY,
+ HConstants.CRYPTO_SASL_ENCRYPTION_AES_CIPHER_CLASS_DEFAULT));
+ // create SaslAES for client
+ saslAES = new SaslAES(transformation, properties,
+ saslCipherMeta.getInKey().toByteArray(),
+ saslCipherMeta.getOutKey().toByteArray(),
+ saslCipherMeta.getInIv().toByteArray(),
+ saslCipherMeta.getOutIv().toByteArray());
+ isAesEncryption = true;
{code}
This code and its related things looks similar in HBaseSaslRpcClient.java and
SaslClientHandler.java. CAn it be unified?
Pls mark the new classes with InterfaceAudience annotation as PRivate.
So the trick on the server side is here
{code}
+ if (saslWaitAesNegotiation) {
+ // get the cipher meta data from client, the data is wrapped by
+ // sasl default encryption
+ RPCProtos.SaslCipherMeta saslCipherMeta =
+ RPCProtos.SaslCipherMeta.parseFrom(saslServer.unwrap(
+ saslToken.array(), 0, saslToken.limit()));
+ // generate the key, iv
+ byte[] saslCipherMetaBytes = negotiateAes(saslCipherMeta);
+ // send the cipher data to client to finish the aes negotiation
+ doSaslAesReply(saslCipherMetaBytes);
+ saslContextEstablished = true;
+ saslWaitAesNegotiation = false;
+ useAesWrap = true;
+ return;
+ } else {
+ replyToken = saslServer.evaluateResponse(saslToken.array());
+ }
{code}
When the saslServer.isComplete() is true you decided whether AesNegotiation has
to be done. So once it is set you do the negotiation and then after you set
saslContextIsEstablished.
{code}
private static final int SASL_AES_CALLID = -34;
{code}
This is intentional?
A server with no SASL_AES wil work with a client asking for AES negotiation?
And vice versa? Pls check this. How these things are handled in general?
Thanks. Most of them are questions and some refactoring can be done I think to
avoid duplicates.
> 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)
