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