You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Bryan Beaudreault (Jira)" <ji...@apache.org> on 2022/07/21 10:55:00 UTC

[jira] [Resolved] (HBASE-27094) Encryption data contains checksum

     [ https://issues.apache.org/jira/browse/HBASE-27094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bryan Beaudreault resolved HBASE-27094.
---------------------------------------
    Resolution: Duplicate

> Encryption data contains checksum
> ---------------------------------
>
>                 Key: HBASE-27094
>                 URL: https://issues.apache.org/jira/browse/HBASE-27094
>             Project: HBase
>          Issue Type: Bug
>            Reporter: wenweijian
>            Priority: Minor
>
> in HFileBlockDefaultDecodingContext.prepareDecofing, we decoding data from onDiskBlock.
> The onDiskBlock contains byte iv length, iv data and encrypted block data if cryptoContext is not null.
> The encrypted block data contains two part, first part is the real encrypted block data, the second part is checksum.
> when we the decrypt method(BlockIOUtils.readFullyWithHeapBuffer),the checkSum will be put into the decryptionStream. if we use others padding mode which likes pkcs5padding, the decrytion will throw an error "Input Length must be a multiple of 16 when decrypting with a padded cipher", because of the checkSum is not a multiple of 16.
> so we need to remove the checksum when we doing decrytion. 
> why we will not get error when we use AES/CTR/NOPPDING, because CTR is not sensitive about the block size. but the other alg such as CBC or ECB, they are sensitive about block size.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)