[
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)
