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