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

Dong Chen commented on SPARK-13331:
-----------------------------------

Sorry for the confusion, below is the change would entail in Spark. Please let 
me know if any confusions.

SPARK-6229 add SASL encryption to network library. The encryption support 3DES, 
DES, and RC4. This JIRA intends to make the encryption support AES for better 
performance.

The change in Spark would involve:
* add code in {{SaslClientBootstrap.doBootstrap()}} and 
{{SaslRpcHandler.receive()}} to negotiate AES encryption.
* Then update {{SparkSaslClient}} and {{SparkSaslServer}} to {{wrap}} / 
{{unwrap}} message with AES.

SPARK-10771 and this JIRA has same point that they both use JCE or a library to 
implement AES. But have different focus in Spark. SPARK-10771 is for data 
encryption when writing / reading shuffle data to disk, and this JIRA is for 
data encryption when transfering data on wire.

> Spark network encryption optimization
> -------------------------------------
>
>                 Key: SPARK-13331
>                 URL: https://issues.apache.org/jira/browse/SPARK-13331
>             Project: Spark
>          Issue Type: Improvement
>          Components: Deploy
>            Reporter: Dong Chen
>            Priority: Minor
>
> In network/common, SASL with DIGEST­-MD5 authentication is used for 
> negotiating a secure communication channel. When SASL operation mode is 
> "auth­-conf", the data transferred on the network is encrypted. DIGEST-MD5 
> mechanism supports following encryption: 3DES, DES, and RC4. The negotiation 
> procedure will select one of them to encrypt / decrypt the data on the 
> channel.
> However, 3des and rc4 are slow relatively. We could add code in the 
> negotiation to make it support AES for more secure and performance.
> The proposed solution is:
> When "auth-conf" is enabled, at the end of original negotiation, the 
> authentication succeeds and a secure channel is built. We could add one more 
> negotiation step: Client and server negotiate whether they both support AES. 
> If yes, the Key and IV used by AES will be generated by server and sent to 
> client through the already secure channel. Then update the encryption / 
> decryption handler to AES at both client and server side. Following data 
> transfer will use AES instead of original encryption algorithm.



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

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@spark.apache.org
For additional commands, e-mail: issues-h...@spark.apache.org

Reply via email to