[jira] [Updated] (SPARK-13331) Spark network encryption optimization
[ https://issues.apache.org/jira/browse/SPARK-13331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dong Chen updated SPARK-13331: -- Description: 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. was: 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 proposal 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. > 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
[jira] [Updated] (SPARK-13331) Spark network encryption optimization
[ https://issues.apache.org/jira/browse/SPARK-13331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dong Chen updated SPARK-13331: -- Description: 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 proposal 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. was: 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 proposal is: When "auth-conf" is enabled, at the end of original negotiation, one more step is added. If client is configured to support AES, it will send request to server > 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 proposal 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
[jira] [Updated] (SPARK-13331) Spark network encryption optimization
[ https://issues.apache.org/jira/browse/SPARK-13331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dong Chen updated SPARK-13331: -- Description: 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 proposal is: When "auth-conf" is enabled, at the end of original negotiation, one more step is added. If client is configured to support AES, it will send request to server was: In network/common, SASL encryption uses DIGEST-MD5 mechanism, which supports: 3DES, DES, and RC4 3des and rc4 are slow relatively. We could make it support AES for more secure and performance. > 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 proposal is: > When "auth-conf" is enabled, at the end of original negotiation, one more > step is added. If client is configured to support AES, it will send request > to server -- 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
[jira] [Updated] (SPARK-13331) Spark network encryption optimization
[ https://issues.apache.org/jira/browse/SPARK-13331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Owen updated SPARK-13331: -- Priority: Minor (was: Major) Component/s: Deploy > 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 encryption uses DIGEST-MD5 mechanism, which supports: > 3DES, DES, and RC4 > 3des and rc4 are slow relatively. We could make it support AES for more > secure and performance. -- 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
