hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jerry Chen (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-11343) Overflow is not properly handled in caclulating final iv for AES CTR
Date Wed, 03 Dec 2014 03:48:12 GMT

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

Jerry Chen commented on HADOOP-11343:
-------------------------------------

@Mike Yoder , When I deep further into the problem, I found that even considering only this
implementation itself, it has problem because of the fact that the Encryptor and Decryptor
underlayer uses Java Cipher or open ssl to do the encryption and decryption and  use caculateIV
method to initialize the iv to a specific position such as a seek operation.

Just described as above, combination of the current caculateIV and other Cipher counter increment
will cause problem if these two are not consistent. 

A strait forward proof of this problem is "The result stream output from CryptoOutputStream
has a possibility of not be able to decrypted by CryptoInputStream" depending on seek operations.

My previous statement "wrap around should work good for the this implementation. " assuming
that the implementation use caculateIV to calculate all the final IV for all the blocks. But
the actual situation now is interleave of caculateIV and increment algorithm of underlayer
Cipher.

Wish this makes the problem clear.

For example,  when using CryptoInputStream decrypt data, we first seek to a position which
will use calculateIV to get the final IV feeding to underlayer Cipher (either java Cipher
or openssl). If long overflow happens  at calculateIV, and the underlayer Cipher get the wrong
final IV to use. While the encryption process may follow the different pattern of calling
calculateIV.



> Overflow is not properly handled in caclulating final iv for AES CTR
> --------------------------------------------------------------------
>
>                 Key: HADOOP-11343
>                 URL: https://issues.apache.org/jira/browse/HADOOP-11343
>             Project: Hadoop Common
>          Issue Type: Bug
>          Components: security
>    Affects Versions: trunk-win
>            Reporter: Jerry Chen
>
> In the AesCtrCryptoCodec calculateIV, as the init IV is a random generated 16 bytes,

> final byte[] iv = new byte[cc.getCipherSuite().getAlgorithmBlockSize()];
>       cc.generateSecureRandom(iv);
> Then the following calculation of iv and counter on 8 bytes (64bit) space would easily
cause overflow and this overflow gets lost.  The result would be the 128 bit data block was
encrypted with a wrong counter and cannot be decrypted by standard aes-ctr.
> /**
>    * The IV is produced by adding the initial IV to the counter. IV length 
>    * should be the same as {@link #AES_BLOCK_SIZE}
>    */
>   @Override
>   public void calculateIV(byte[] initIV, long counter, byte[] IV) {
>     Preconditions.checkArgument(initIV.length == AES_BLOCK_SIZE);
>     Preconditions.checkArgument(IV.length == AES_BLOCK_SIZE);
>     
>     System.arraycopy(initIV, 0, IV, 0, CTR_OFFSET);
>     long l = 0;
>     for (int i = 0; i < 8; i++) {
>       l = ((l << 8) | (initIV[CTR_OFFSET + i] & 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);
>   }



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

Mime
View raw message