You are viewing a plain text version of this content. The canonical link for it is here.
Posted to common-issues@hadoop.apache.org by "Alejandro Abdelnur (JIRA)" <ji...@apache.org> on 2014/05/28 06:17:02 UTC
[jira] [Commented] (HADOOP-10632) Minor improvements to Crypto
input and output streams
[ https://issues.apache.org/jira/browse/HADOOP-10632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14010753#comment-14010753 ]
Alejandro Abdelnur commented on HADOOP-10632:
---------------------------------------------
Yi, nice work. following some minor comments:
All crypto classes should be annotated as Private has Hadoop is not in the business of exposing crypto APIs as an available crypto library.
JCEAESCTREncryptor/JCEAESCTRDecryptor can be merged into a single class taking the cipher-mode as constructor param. and the encrypt/decrypt would delegate to a single process() method.
AESCTRCryptoCodec#calculateIV() the IV calculation can be done much more efficiently doing some byte shifting:
{code}
private static final int CTR_OFFSET = 8;
...
System.arraycopy(initIV, 0, IV, 0, 8);
long l = (initIV[CTR_OFFSET + 0] << 56)
+ ((initIV[CTR_OFFSET + 1] & 0xFF) << 48)
+ ((initIV[CTR_OFFSET + 2] & 0xFF) << 40)
+ ((initIV[CTR_OFFSET + 3] & 0xFF) << 32)
+ ((initIV[CTR_OFFSET + 4] & 0xFF) << 24)
+ ((initIV[CTR_OFFSET + 5] & 0xFF) << 16)
+ ((initIV[CTR_OFFSET + 6] & 0xFF) << 8)
+ (initIV[CTR_OFFSET + 7] & 0xFF);
l += counter;
IV[CTR_OFFSET + 0] = (byte) (l >>> 56);
IV[CTR_OFFSET + 1] = (byte) (l >>> 48);
IV[CTR_OFFSET + 2] = (byte) (l >>> 40);
IV[CTR_OFFSET + 3] = (byte) (l >>> 32);
IV[CTR_OFFSET + 4] = (byte) (l >>> 24);
IV[CTR_OFFSET + 5] = (byte) (l >>> 16);
IV[CTR_OFFSET + 6] = (byte) (l >>> 8);
IV[CTR_OFFSET + 7] = (byte) (l);
{code}
CryptoInputStream/CryptoOutputStream, besides the MIN_BUFFER_SIZE check we could floor the specified buffer size to a multiple of the CryptoCodec#getAlgorithmBlockSize()
CryptoInputStream/CryptoOutputStream, we should clone the key & initIV as well.
CryptoInputStream#read(), no need for doing {{if (usingByteBufferRead.booleanValue())}}, just do {{if (usingByteBufferRead)}}, 2 places.
CryptoInputStream#readFromUnderlyingStream(), it would be more intuitive to read if the inBuffer is passed as parameter.
CryptoInputStream, comment "\{@link #org.apache.hadoop.fs.ByteBufferReadable\}" should not have the '#'
CryptoInputStream#decrypt(long position, ...) method, given that this method does not change the current position of the stream, wouldn’t be simpler to create a new decryptor and use a different set of input/output buffers without touching the stream ones? We could also use instance vars for them and init them the first time this method is called (if it is).
> Minor improvements to Crypto input and output streams
> -----------------------------------------------------
>
> Key: HADOOP-10632
> URL: https://issues.apache.org/jira/browse/HADOOP-10632
> Project: Hadoop Common
> Issue Type: Sub-task
> Components: security
> Affects Versions: fs-encryption (HADOOP-10150 and HDFS-6134)
> Reporter: Alejandro Abdelnur
> Assignee: Yi Liu
> Fix For: 3.0.0
>
>
> Minor follow up feedback on the crypto streams
--
This message was sent by Atlassian JIRA
(v6.2#6252)