[
https://issues.apache.org/jira/browse/HADOOP-11343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14232637#comment-14232637
]
Haohui Mai edited comment on HADOOP-11343 at 12/3/14 6:14 AM:
--------------------------------------------------------------
bq. 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.
While any codecs can produce and consume encrypted texts, there are some
questions to be answered to bridge the gap from encryption and security. For
example, does the codec faithfully implement the algorithm? How well does it
defend against timing attack? (some architecture will generate exception during
overflow) What are the possible covert channels in the generated assembly?
Much effort in crypto libraries are to analyze and to address these problems.
Though miscalculating the IV may or may not be a big deal, I don't know how it
can affect the answers of the above questions, as well as the security
assurance.
bq. So this fix would not be a pure improvement, but a crucial fix for
unrecoverable data corrutption caused by encryption.
Agreed. I think this should be a blocker.
was (Author: wheat9):
bq. 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.
While any codecs can produce and consume encrypted texts, there are some
questions to be answered to bridge the gap from encryption and security. For
example, does the codec faithfully implement the algorithm? How well does it
defend against timing attack? What are the possible covert channels in the
generated assembly?
Much efforts in crypto libraries, such as Java cipher and OpenSSL are to
analyze and to address these problems. The efforts are parts of the security
assurance. As we current don't have the same level of assurance in the current
diverged codec, personally I think that it should be treated as a potential
security vulnerability.
bq. So this fix would not be a pure improvement, but a crucial fix for
unrecoverable data corrutption caused by encryption.
Agreed. I think this should be a blocker.
> 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, 2.7.0
> Reporter: Jerry Chen
> Priority: Blocker
>
> 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)
