Hello, Maxim. > This record type doesn't encrypt, does it?
DataRecord includes collection of DataEntry. DataEntry that belongs to encrypte cache is encrypted. Please, take a look at RecordDataV1Serializer#putEncryptedDataEntry пт, 1 февр. 2019 г. в 12:54, Максим Степачёв <[email protected]>: > 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, Максим Степачёв <[email protected]>: > >> Nikolay, >> It's my mistake. You're right. >> Thanks for answering. >> >> чт, 31 янв. 2019 г. в 17:50, Nikolay Izhikov <[email protected]>: >> >>> 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, Максим Степачёв <[email protected] >>> >: >>> > >>> > 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 <[email protected]>: >>> > >>> > > 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, Максим Степачёв < >>> [email protected] >>> >: >>> > > >>> > > > 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 <[email protected]>: >>> > > > >>> > > >> 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, Максим Степачёв < >>> > > [email protected] >>> > > >> >: >>> > > >> >>> > > >> > 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. >>> > > >> > >>> > > >> >>> > > > >>> > > >>> >>
