[jira] [Commented] (HDFS-6508) Add an XAttr to specify the cipher mode

2014-06-10 Thread Charles Lamb (JIRA)

[ 
https://issues.apache.org/jira/browse/HDFS-6508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14026554#comment-14026554
 ] 

Charles Lamb commented on HDFS-6508:


[~tucu00] says:

Our current work is implementing standard AES-CTR streaming, this is pluggable 
to support multiple implementations (pure Java -current-, OpenSSL backed -based 
on Diceros-, etc).

We should store the encryption mode enum, for now simply AES-CTR.

To support future impls and backward/forward compatibility we should do 
something like:

* On create/open RPC request, client sends set of supported encryption modes to 
NN.
* On create RPC, if the NN does support any of the modes specified by the 
client, EXCEPTION.
* On open RPC, if the NN determines the client does not support the encryption 
mode used in the file on encryption, EXCEPTION.
* On create RPC response, NN sends back encryption initialization data (ie key, 
IV) plus the encryption mode mode the client must use.
* On open RPC response, NN send back encryption initialization data (ie key, 
IV) plus the encryption mode mode the client must use (data has been encrypted 
with this mode).
* The client would have a switch/case statement on the encryption mode to wrap 
the data streams with the right impl. At the moment here is one choice only.

Note that the implementation we use for a given encryption mode (first 
paragraph of this email) is independent of the encryption mode selection logic 
just described.

 Add an XAttr to specify the cipher mode
 ---

 Key: HDFS-6508
 URL: https://issues.apache.org/jira/browse/HDFS-6508
 Project: Hadoop HDFS
  Issue Type: Sub-task
  Components: namenode, security
Reporter: Charles Lamb
Assignee: Charles Lamb

 We should specify the cipher mode in the xattrs for compatibility sake. 
 Crypto changes over time and we need to prepare for that.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Commented] (HDFS-6508) Add an XAttr to specify the cipher mode

2014-06-10 Thread Charles Lamb (JIRA)

[ 
https://issues.apache.org/jira/browse/HDFS-6508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14026592#comment-14026592
 ] 

Charles Lamb commented on HDFS-6508:


bq. On create RPC, if the NN does support any of the modes specified by the 
client, EXCEPTION.

s/does support/does not support/


 Add an XAttr to specify the cipher mode
 ---

 Key: HDFS-6508
 URL: https://issues.apache.org/jira/browse/HDFS-6508
 Project: Hadoop HDFS
  Issue Type: Sub-task
  Components: namenode, security
Reporter: Charles Lamb
Assignee: Charles Lamb

 We should specify the cipher mode in the xattrs for compatibility sake. 
 Crypto changes over time and we need to prepare for that.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Commented] (HDFS-6508) Add an XAttr to specify the cipher mode

2014-06-10 Thread Charles Lamb (JIRA)

[ 
https://issues.apache.org/jira/browse/HDFS-6508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14027213#comment-14027213
 ] 

Charles Lamb commented on HDFS-6508:


[~tucu00] also says: The IV length may depend on the algorithm being used 
(AES-GCM allows arbitrary lengths starting a 16bytes, if 16 it does the same 
logic as AES-CTR mode -uses first 8 bytes as counter-, if greater than 16 it 
does a funny hash computation of it to get 16bytes and then the counter logic).

Building on my previous email about the enum for the encryption mode, we could 
put the length of the IV in the encryption-mode enum itself. Then we can remove 
it from the the CryptoCodec and use the constant itself.

 Add an XAttr to specify the cipher mode
 ---

 Key: HDFS-6508
 URL: https://issues.apache.org/jira/browse/HDFS-6508
 Project: Hadoop HDFS
  Issue Type: Sub-task
  Components: namenode, security
Reporter: Charles Lamb
Assignee: Charles Lamb

 We should specify the cipher mode in the xattrs for compatibility sake. 
 Crypto changes over time and we need to prepare for that.



--
This message was sent by Atlassian JIRA
(v6.2#6252)