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

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

Thanks Alejandro Abdelnur for suggestion.
As far as I see, the current issue is not a pure compatibility issue. A 
compatibility issue can be solved by using a different crypto SUITE. While the 
data corruption identified here can happen even if using this crypto SUITE 
only. This crypto SUITE itself is broken (generate corrupted data cannot be 
decrypted by itself) when IV + counter overflows on 8 bytes happens. 

This issue can be work rounded externally by fill lower 8 bytes with random IV 
and the higher 8 bytes (for counter) with zero. (To avoid overflow situation). 

But the current default KMS iv generation function will random the whole 16 
bytes which makes to trigger condition of this issue much easier to satisfy.






> 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
>            Assignee: 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)

Reply via email to