hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Nauroth (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-6606) Optimize HDFS Encrypted Transport performance
Date Mon, 08 Sep 2014 17:26:29 GMT

    [ https://issues.apache.org/jira/browse/HDFS-6606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14125778#comment-14125778

Chris Nauroth commented on HDFS-6606:

bq. But the obtained key is still used while a cipher option is being negotiated, we use it
to encrypt the negotiated cipher key (using sasl wrap/unwrap)...

Thanks for clarifying, Yi.  I missed the significance of this part.  One additional note though:
in the case of setting {{dfs.data.transfer.protection}} to {{privacy}}, the client will not
fetch an encryption key from the NameNode.  Instead, the SASL handshake password is based
on the block access token password.  The main difference here compared to {{dfs.encrypt.data.transfer}}
is the lack of a "per-session" nonce and the ability to control the encryption algorithm used
by setting {{dfs.encrypt.data.transfer.algorithm}}.  In that sense, {{dfs.encrypt.data.transfer}}
still has some capabilities that you can't get by using {{dfs.data.transfer.protection}}.

I agree now that existing tests cover it, and you can disregard my earlier suggestions.  I
don't see any additional configuration variations to test.

I'm +1 for patch v3, pending resolution of feedback from [~tucu00] too.  Thanks again!

> Optimize HDFS Encrypted Transport performance
> ---------------------------------------------
>                 Key: HDFS-6606
>                 URL: https://issues.apache.org/jira/browse/HDFS-6606
>             Project: Hadoop HDFS
>          Issue Type: Improvement
>          Components: datanode, hdfs-client, security
>            Reporter: Yi Liu
>            Assignee: Yi Liu
>         Attachments: HDFS-6606.001.patch, HDFS-6606.002.patch, HDFS-6606.003.patch, OptimizeHdfsEncryptedTransportperformance.pdf
> In HDFS-3637, [~atm] added support for encrypting the DataTransferProtocol, it was a
great work.
> It utilizes SASL {{Digest-MD5}} mechanism (use Qop: auth-conf),  it supports three security
> * high                      3des   or rc4 (128bits)
> * medium             des or rc4(56bits)
> * low                       rc4(40bits)
> 3des and rc4 are slow, only *tens of MB/s*, 
> http://www.javamex.com/tutorials/cryptography/ciphers.shtml
> http://www.cs.wustl.edu/~jain/cse567-06/ftp/encryption_perf/
> I will give more detailed performance data in future. Absolutely it’s bottleneck and
will vastly affect the end to end performance. 
> AES(Advanced Encryption Standard) is recommended as a replacement of DES, it’s more
secure; with AES-NI support, the throughput can reach nearly *2GB/s*, it won’t be the bottleneck
any more, AES and CryptoCodec work is supported in HADOOP-10150, HADOOP-10603 and HADOOP-10693
(We may need to add a new mode support for AES). 
> This JIRA will use AES with AES-NI support as encryption algorithm for DataTransferProtocol.

This message was sent by Atlassian JIRA

View raw message