[
https://issues.apache.org/jira/browse/HDFS-6508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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)
