ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nikolay Izhikov <nizhi...@apache.org>
Subject Re: Does KeystoreEncryptionSpi have problem with size calculation?
Date Fri, 01 Feb 2019 11:04:48 GMT
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, Максим Степачёв <maksim.stepachev@gmail.com>:

> 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.stepachev@gmail.com>:
>
>> Nikolay,
>> It's my mistake. You're right.
>> Thanks for answering.
>>
>> чт, 31 янв. 2019 г. в 17:50, Nikolay Izhikov <nizhikov@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.stepachev@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 <nizhikov@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.stepachev@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 <dpavlov@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.stepachev@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.
>>> > > >> >
>>> > > >>
>>> > > >
>>> > >
>>>
>>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message