Nikolay, Could you help again? I looked at the WalRecordCacheGroupAware, and found that the DataRecord doesn't implement it. This record type doesn't encrypt, does it? Is it a problem?
чт, 31 янв. 2019 г. в 18:23, Максим Степачёв <maksim.stepac...@gmail.com>: > Nikolay, > It's my mistake. You're right. > Thanks for answering. > > чт, 31 янв. 2019 г. в 17:50, Nikolay Izhikov <nizhi...@apache.org>: > >> Maxim, >> >> > I suppose the AES algorithm work with blocks by 16 bytes for encryption >> data + 2 bytes for padding in AES_WITH_PADDING mode >> >> Why do you make this conclusion? >> >> Actually, in AES_WITH_PADDING mode we should add 2 more *BLOCK*: for IV >> and >> for padding info. >> You can find sanity check in KeystoreEncryptionSpiSelfTest. >> Please, take a look into KeystoreEncryptionSpiSelfTest#testEncryptDecrypt >> which check the case you described. >> >> чт, 31 янв. 2019 г. в 17:08, Максим Степачёв <maksim.stepac...@gmail.com >> >: >> > >> > Nikolay, >> > I see. We should close IGNITE-11129 as invalid. I'm going to ask the >> > reporter, what he means. >> > >> > > Please, explain, why do you think so? >> > I answered to Dmitriy Pavlov with explaining. >> > >> > In short, your method encryptedSize(int dataSize) returns the *"*wrong >> > result*"* when I call it with dataSize = 20. >> > I suppose the AES algorithm work with blocks by 16 bytes for >> > encryption data + 2 bytes for padding in AES_WITH_PADDING mode. >> > The current implementation works for dataSize = 20: ( (20 / 16) + 2 ) * >> > 16. " 20 / 16 = 1." , Are we lost one block for 4 bytes? Or is it fine? >> > >> > >> > >> > >> > >> > >> > чт, 31 янв. 2019 г. в 16:15, Nikolay Izhikov <nizhi...@apache.org>: >> > >> > > Hello, Maxim. >> > > >> > > > IGNITE-11129 >> > > >> > > Do we have reproducer for this ticket? >> > > WalRecord will be encrypted only if record class >> > > implements WalRecordCacheGroupAwarei.e it contains some cache data >> that >> > > should be protected with encryption. >> > > Please, look into private boolean needEncryption(WALRecord rec). >> > > SwitchSegmentRecord does not implement WalRecordCacheGroupAware, so >> not >> > > encryption would be applied for this types of records. >> > > >> > > I think we should close IGNITE-11129 as invalid. >> > > >> > > > Should we use this code: >> > > >> > > Please, explain, why do you think so? >> > > Do you find some bug? >> > > Can you send a reproducer? >> > > >> > > You can find details of encrypted data size calculation in AES >> algorithm >> > > description. >> > > >> > > чт, 31 янв. 2019 г. в 15:24, Максим Степачёв < >> maksim.stepac...@gmail.com >> >: >> > > >> > > > Dmitriy Pavlov, >> > > > >> > > > Your statement about page size is true. But our case about plainSize >> of >> > > > serialized record in bytes. This method calculates it: >> > > plainSize(WALRecord >> > > > record). For example, if you look in this method, you will see >> > > > DATA_PAGE_UPDATE_RECORD section. A size of record calculates a sum >> of: 4 >> > > + >> > > > 8 + 2 + 4 + uRec.payload().length where a length is an arbitrary >> number. >> > > > >> > > > чт, 31 янв. 2019 г. в 14:54, Dmitriy Pavlov <dpav...@apache.org>: >> > > > >> > > >> Hi Maxim, why do you think that data size can be divided to cipher >> block >> > > >> size with 0 remainder. >> > > >> >> > > >> I used to think that page size 4096 is always divisible by a usual >> block >> > > >> cipher block size, e.g 32, 16 or 8 bytes >> > > >> >> > > >> чт, 31 янв. 2019 г. в 13:11, Максим Степачёв < >> > > maksim.stepac...@gmail.com >> > > >> >: >> > > >> >> > > >> > Hi, I have been trying to solve a problem with calculation size >> for >> > > >> > encryption mode, it's ticket IGNITE-11129. But I found an >> additional >> > > >> place >> > > >> > for wrong behavior. I'm confused, Is it fine or wrong? Look at >> > > >> > *KeystoreEncryptionSpi#encryptedSize*, the result calculation >> works as >> > > >> > >> > > >> > (dataSize / BLOCK_SZ + cntBlocks) * BLOCK_SZ; >> > > >> > >> > > >> > But we don't have a guarantee that dataSize is multiple of >> BLOCK_SZ. >> > > >> > Should we use this code: >> > > >> > >> > > >> > ((dataSize + BLOCK_SZ - 1) / BLOCK_SZ + cntBlocks) * BLOCK_SZ; >> > > >> > >> > > >> > If yes, I'll fix it. >> > > >> > >> > > >> >> > > > >> > > >> >
