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. > > >> > > > >> > > > > >
