[ 
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 strength:
> * 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
(v6.3.4#6332)

Reply via email to