[
https://issues.apache.org/jira/browse/HADOOP-11343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14232434#comment-14232434
]
Mike Yoder commented on HADOOP-11343:
-------------------------------------
Let's back up a bit. I don't understand what the problem is that you are
trying to address. You keep mentioning "overflow". Yes, bytes 8-15, when
treated as a long and added to the counter, can wrap around instead of carrying
the results into bytes 0-7. But what's the problem with that? The values of
the IV will still be different for each block that's encrypted. No information
is lost, and we still have to have a file larger than 2^68 bytes before we wrap
the counter.
You mention the openssl source code for AES_ctr128_encrypt() - that was exactly
the code I was referring to when I said "(As an aside, I've seen an openssl
implementation that follows the first recommendation.)" That's just one way to
handle the IV.
So I just went digging around for Java code that does AES-CTR, and found
http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8-b132/com/sun/crypto/provider/CounterMode.java#CounterMode
Look for increment(). It does the same thing as the openssl implementation
(which is actually a surprise to me, I thought it worked like calculateIV). I
might be mistaken in this, but I _thought_ that calculateIV() was written the
way it was written completely on purpose. We should seek comment from
[~tucu00] if he's still paying attention to emails that come from apache jira.
You do need to address the upgrade question: changing this code will render
useless any data encrypted with the current scheme, unless that data is first
copied out of an EZ to clear text, the upgrade performed, and then the data
copied back into the EZ. This is a *very* heavy price to pay.
I'd also like to know what the use case is. You mention the Java Cipher - is
your use case that you want to get the raw encrypted data and somehow decrypt
it by hand outside of the normal path? If so, how would you get the key to
decrypt it with? Why would you want to do this?
> 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)
